This is a post here in the Requirements Network that I thought need more thought

 I like your processes. I am currently working with a Requirements Engineering methodology call Behavior Engineering (bE) (yes Behavior not Behaviour) to conduct Requirements Gathering and Analysis. There some ideas that have come out from conducting the methodology. The methodolgy was created by Geoff Dromey from Griffith University in Brisbane Australia over seven years ago. You can find more information from the following website http://www.behaviorengineering.org/ 

1) Identify Stakeholders and conduct a Stakeholders Analysis. A Stakeholder Analysis is greater than the users, champions, and external entities. One great site that explains this process in more detailed is Ian Alexander's paper A Better Fit – Characterising the Stakeholders you can find the paper at the following website http://easyweb.easynet.co.uk/~iany/consultancy/papers.htm
.

2) I would agree with Terry in addition to identifing the requirements from SMEs the BA should use the current business processes (As Is Processes) to create requirements. In addition, the BA should identify the new processes. I look at it this way no new system be it hardware or software is created in a vacuum. Systems are not created for a brand new universe they are created to solve problems in a world that already has processes, cultures, beliefs, values. Therefore we have to start with what is known about the current system.

3) Identify, if possible, the new processes (To be processes) and identify the gaps between the current process against the new processes (gap analysis). The difference will give you the requirements required to meet the new processes.

4) Identify all of the goals that the new system is required to achieve these are high level concepts usually written down in an Operational Concept Document (OCD).

Combining the results of the stakeholder analysis, gap analysis, and goal identification the requirements engineering should be able to identify all functional requirements.

 Using the Behavior Engineering (bE) Methodolgy the BA should be able to identify Non-Functional Requirements because during the bE process the Analyst is required to look for the who, what, where, when, how and why for the requirement; therefore identifying performance and contextual requirements.

5) Finally, since requirements are the most difficult area in developing software and systems as noted in the US Goverment Auditing Office 2008 report "Defense Acquisitions: Assessments of Selected Weapon Programs" on 72 defence projects found that "63 percent of the programs had change requirements once system development began, and also experience significant program cost increases". The total over current over budget estimate as of 2007 was $285 Billion (USD). I think that as apart of the BA/RE process there needs to be more accountability. Therefore I would also like to see a BA/RE Report that would consist of the following

1) What Requirements Elicitation techniques were used. Mis Use Cases, soft system methodolgy SSM, bE a good website is https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements/533-BSI.html 

2) What Repuirements Management tools were used in conducting the Requirements Elicitation and Analysis i.e. spreadsheet, Word, Mindmanager, RequisitePro, Doors, Core, Rose, BESE

3) What methodolgies were used to model the requirements - Behavior Engineering (bE), Use Cases, Scenarios, UML, SysML

4) What Metrics were used to mange the volitility and growth of the requirements

As an Annex to the report the evidence would be provide such as inteview summaries with links to full interviews, Graphs/Charts of Metrics during the period of Requirements Elicitation