Requirements Analysis Process

There is a lot of talk about how Requirements Analysis should be thorough, capture all the user requirements (including from ‘real’ users), and if possible, the requirements analysis process should ideally be part of an iterative loop so that there are no requirements that are missed out (given that in the normal waterfall model, there are chances of the initial requirements analysis step missing out some requirements due to the users not being able to convey all the requirements in such an early stage).

There never has been agreement on what the steps are for the process of generating requirements, but the following listing is a good first step:

1. Identify the requirements analyst: Defining who a good requirements analysis can be is a tough step, but typically it has normally been defined as a person familiar with the business practices, somebody who has actually worked in that area, and is comfortable in being able to work with the actual users. A requirements analyst also needs to be firm enough that he / she sticks to the task until the requirements analysis is complete. For large projects, this could be a team of people.

2. Identify customer people to talk to: Earlier this would have meant speaking to the business managers of the customer (whether this be an internal customer or an external customer), but now we refer to this being the step of making sure that the stakeholders are identified and talked to:
a) These include the actual users of the software. If the software is uncomfortable for the end users, it is doomed to be a failure
b) One should also talk to the managers and leaders of the software. They have a better perception of the needs that a software must meet. In many cases, a new software can lead to an improvement of the processes followed in an organization (for example, implementation of an Enterprise Resource Planning software typically leads to many world class processes getting used)

3. Actual information gathering: This includes a combination of tools used and people met in different settings (questionnaires, personal interviews, group sessions, demonstrations, etc)
Traditional methods of Requirements Elicitation included stakeholder interviews and focus group studies. Other methods like flowcharting of business processes and the use of existing documentation like user manuals, organizational charts, process models and systems or process specifications, on-site analysis, interviews with end-users, market research and competitor analysis were also used extensively in Requirements Elicitation.
Some of the current Requirements Elicitation tools in use are:
* Prototypes
* Use cases
* Data flow diagrams
* Transition process diagrams
* User interfaces

4. Structuring the proceeds of the previous step: Once all stakeholder requirements have been gathered, a structured analysis of these can be done after modeling the requirements. Some of the Software Requirements Analysis techniques used are requirements animation, automated reasoning, knowledge-based critiquing, consistency checking, analogical and case-based reasoning.

5. Documenting the requirements specification: This step is one of the most important components of the requirements analysis process. Unless requirements collected in previous steps are not properly documented, they cannot be verified. In addition, they cannot be used for further design, prototyping, and for generation of test plans and cases.
Requirements, once elicited, modeled and analyzed should be documented in clear, unambiguous terms so that they form the basis for:
* Base for validating the stated requirements and resolving stakeholder conflicts, if any
* Contract between the client and development team
* Basis for systems design for the development team
* Bench-mark for project managers for planning project development lifecycle and goals
* Source for formulating test plans for QA and testing teams
* Resource for requirements management and requirements tracing
* Basis for evolving requirements over the project life span

6. Requirements Management
This step includes all aspects of software requirements analysis and additionally ensures verification, validation and traceability of requirements. Effective requirements management practices guarantee that all system requirements are stated unambiguously, that omissions and errors are corrected and that evolving specifications can be incorporated later in the project life-cycle.