In my last post, I explained the difference between validation and verification. In this post, I’ll further explain validation and provide some best practices.

To ensure that software requirements validation goes smoothly, the following questions should be posed:

• Are all requirements necessary and sufficient?
• Do lower level detailed software requirements meet the objectives of higher level software requirements and needs?
• Do the software requirements meet stakeholder needs and constraints?
• Are all requirements complete, feasible, and verifiable?
• Which requirements have a large impact on cost, schedule, risk, and/or performance?
• Are all non-functional requirements captured, particularly those that will be important to end users (e.g. performance considerations)?

Validation should be an iterative process – as more detailed requirements are discovered and documented, the questions above should be repeated. As the technical design team gets involved and provides input on the requirements and begins to formulate the technical design, validation should continue to occur (it should be pointed out that technical design also needs to go through a validation process as well).

Consider these best practices when developing requirements:

• Make sure that you have properly identified all stakeholders and their needs
• Ensure that you have properly documented business objectives and required features
• Map each requirement to a business objective/need
• Make sure that you spend sufficient time in eliciting and analyzing non-functional requirements – this should not be left as an afterthought
• Utilize peer reviews to improve the overall quality of your documented requirements

Hopefully this will give you some food for thought to make sure your project “builds the right thing”.