At the start of any project, whether it is a new implementation, feature upgrade or error correction, the overall scope of the activity must be first defined. (See our Defining the Scope article for more on the process for doing that.) After the Scope has been defined, the specifics need to be determined. These specifics are known as Requirements. For specifics on what a requirement is and how it is created see our previous Article, Requirements Definition. Before the identification and decomposition of requirements can be done, they must first be gathered from the Stakeholders defined in the scope.
The process of gathering requirements is known as Requirements Elicitation. There are a number of different ways to do this and this article will highlight just a few, such as Interviewing, Observation and Survey/Questionnaire. Each of these are fully defined in the Business Analyst Body of Knowledge and are useful in different phases of the requirements gathering process. The level of usefulness can also vary dependent on the scope of the project.
Interviewing
Interviewing, for example, is best used in the initial collection phase. This will allow the Business Analyst or Requirements Engineer to sit down with the primary stakeholders and gather information about the business processes. By allowing the stakeholders to express their likes, dislikes, frustrations and desires about the processes defined in the Scope. These statements will provide the Business and Stakeholder requirements, also known as the User Needs statements.
Observation
Once the interviewing is completed and the Business Analyst has defined the User Needs statements, they are able to move on to gathering the Solution or System Functional requirements. This can be done either through another round of interviews or by observation. A second round of interviews may be the best approach when there is not an existing system. When there is an existing system, then observation about how it is currently used may be a better approach. The details of any system can be gleaned from watching what the users do and having them explain any gaps in understanding of the process. Depending on the Scope of the project, it is at this point that the Business Analyst is beginning to move from the what and why of the project to the how.
Survey / Questionnaire
After the gathering of the Business, Stakeholder and Solution requirements, there may be some remaining gaps. An analysis of the requirements specification documentation and the scope of the project will show these gaps. To cover these and any other details as may be missing, the use of a Survey or Questionnaire may be useful. This would allow the Business Analyst to ask specific questions and receive a variety of answers from the Survey recipients. Putting the results together will show how well the questions covered the gap area.
While the Business Analyst Body of Knowledge and the Systems Engineering Body of Knowledge both list additional techniques for Requirements Elicitation, they work well together in getting complete coverage for any project.