Sources of Requirements
From Requirements Management School
You cannot identify all the requirements for a project without first identifying the stakeholders. Once all the stakeholders have been identified, you have to start eliciting their requirements.
For most projects, stakeholders are diverse. They have diverse perspectives. They may think that they know what they want but that does not always translate to what is actually needed. This means that you have to use as many sources as possible to ensure that as many gaps as possible are plugged.
"Sources of Requirements" refers to all the stakeholders that you need to interact with at the elicitation stage. The quality of the data gathered at this stage will enable you to analyze the full picture. This will then allow you to put together a comprehensive and coherent set of requirements, test cases and system models for validation. Too little research done from too few sources will produce an inadequate set of requirements.
It is always important to remember that it is the stakeholders that are the ultimate source of requirements. Bearing this in mind you can classify the sources of requirements into the following categories:
- Discussions with all classes of stakeholders in order to elicit their requirements based on their individual perspectives of the process. This should include their views, issues with the current system as well as their vision for the new one. A specification for the new system should also be made available if it exists.
- Competitive analysis of any competing systems already in the marketplace.
- Policy and Procedure Manuals for the business and process at hand so that all system interactions, regulatory constraints and so on can be identified.
- Perhaps the most important category is to observe the users at work, their interpretation of how the policies and procedures are converted into workflow using the current system. Any workarounds that they use are telling as are the gaps that they perceive in the process which may only become apparent as you watch the process whilst they actually carry out the tasks. This process is vital in order to generate task lists and scenarios. These lead to the identification of required functionality, test cases and scenarios.
- The marketing and customer care departments should not be overlooked. It is likely that they have data that can be extracted from customer surveys and questionnaires. If they do not have the required data a discussion over gathering this data should be initiated with a view to getting a survey initiated.
- For legacy systems, the following should also be considered: System Manuals, Specifications, Issue Logs, and Enhancement Requests.
Make sure that all of this quality data is gathered and questioned at the time of elicitation. Then at the analysis stage, you should have all of the data that you need in order to interpret a good set of requirements. The quality of data that you collect is key; the right questions have to be posed. All the stakeholders have to be involved. If this is not the case then a good set of requirements is not feasible.
