- Requirements validation is an iterative process which takes place throughout the lifecycle of the project.
- During elicitation, analysis and specification you should constantly be questioning and clarifying the data given to you in order to check its validity.
- This will ensure that the SRS that you produce is complete, consistent and ready for the formal validation process.
- During the formal requirements validation process you are aiming to ensure that the SRS is complete, consistent, modifiable and traceable.
- You are also testing to makes sure that the requirements statements themselves are complete, correct, feasible, necessary, prioritized, unambiguous and verifiable.
- This may seem like a lofty task but it is essential to pick up any gaps or errors at this stage in order to minimize defects later.
- The costs associated with rectifying defects later in the process are exorbitant. Ironing out as much possible at this stage should be your priority.
- There are many techniques available to help you with the process.
- Most the techniques involve all the stakeholder representatives reading the requirements; carrying out problem analysis; meeting; discussing, resolving issues and collaboration that will result in consensus and the requirements baseline being set.
There are a host of techniques out there to help make this stage easier to manage. Here are some of the most popular ones:
Review and Inspection – Review and inspection is the most rigorous process. It can also be the most time consuming as it generally involves all the stakeholder representatives. The SRS is reviewed collaboratively. Any issue arising are captured in an issues log. Some will be resolved on the spot others will need to be referred to specialists for clarification. This means that this process is iterative and may go through a few iterations before all the issues are resolved.
Prototyping – One of the most effective ways to ensure that the developers are on the same page as the users. Prototyping is generally used to test validity and completeness of the requirements. A prototype brings the SRS to life by providing the users with a visual model. The developers will choose the most appropriate approach to prototyping depending on the situation.
Traceability – This should be carried out for every single project, unless the project is very small. Completing a traceability matrix will ensure that the SRS is complete, that nothing has fallen through the gaps. It will also ensure that all the requirements elicited can be traced back and justified to business requirements as well as functional requirements. This matrix lays the foundation for checking bidirectional traceability between the requirements, test cases, source code and design.
Testing – All requirements must be testable /verifiable so putting together the test scripts for the project as early as possible will highlight missing information or information that is ambiguous. If you are using use cases this is not an onerous task. This is an ideal method for testing functional requirements but can be tricky to adopt for non-functional requirements.