There seems to be much confusion over the terms verification and validation. Many people and even QA analysts talk about and even perform V&V as though they are one and the same. However, these activities are not the same. In this blog post, we are going to explore the differences between verification and validation. Quality Assurance will be the focus of a future blog article.
Validation is the process of confirming the completeness and correctness of requirements. Validation also ensures that the requirements: 1) achieve stated business objectives, 2) meet the needs of stakeholders, and 3) are clear and understood by the developers. Validation is essential to identification of missing requirements and to ensure that the requirements meet certain quality characteristics. Validation addresses each individual requirement to ensure that it is:
- Correct – accurately states a customer or external need
- Clear – has only one possible meaning
- Feasible – can be implemented within known constraints
- Modifiable – can be easily changed, with history, when necessary
- Necessary – documents something customers really need
- Prioritized – ranked as to importance of inclusion in product
- Traceable – can be linked to system requirements, and to designs, code, and tests
- Verifiable – correct implementation can be determined by testing, inspection, analysis, or demonstration
Verification is the process of confirming that the designed and built product fully addresses documented requirements. Verification consists of performing various inspections, tests, and analyses throughout the product lifecycle to ensure that the design, iterations, and the finished product fully addresses the requirements.
To prevent rework, requirements should be validated and approved before design. If the requirements are not validated, then requirement validation and product verification will inevitably be done together during product design and development activities. Because verification is guided by requirements, there is high likelihood that missing or invalid requirements will not be discovered. Missing and invalid requirements causes rework and significant cost overruns.
Note that the last quality characteristic listed above is “Verifiable.” Assessing verification as you develop your requirements and validating that the requirements are verifiable significantly improves requirement quality.
Validating that your requirements support verification provides a basis for estimating verification costs and schedule and reduces verification costs. An unverifiable requirement is a bad or unnecessary requirement; if you can not verify it, then you can not design it or build it. For example, take the requirement “The product must be reliable.” What is reliable? If you can’t define what reliable is, how will designers know what reliable is? If you can’t verify a requirement you may not be able to convince your customer that your product is reliable.
Risk management is one of the key responsibilities of the project manager. Ensuring that development begins with verifiable requirements is key to reducing risk. Carefully reviewing each requirement to ensure that it is verifiable and either eliminating or requesting rewrites of requirements that are not verifiable is an important activity in the requirements development process. The Enfocus Solutions Requirement Suite™ provides tools and underlying support to ensure effective documentation, verification and validation of requirements.