This is the first in a series of posts on commonly confused terms for PMP exam.
PMBOK Guide 5th Edition defines:
Verification: The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process.
Validation: The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers.
More commonly used definitions for Validation and Verification used in software engineering systems are:
Validation: Are we building the right system?
Verification: Are we building the system right?[1]
Verified deliverables are outputs of the Control Quality process and tests for correctness of the deliverables. Correctness relates to specified product/service/result requirements and design specifications. While doing Verification we are concerned with whether the deliverable meets exact requirements specifications.
Consider an example, you are in the process of developing a calculator mobile application for a mortgage broker for calculating monthly mortgage payments by their clients. The inputs in the calculator are cost of the property, down payment, interest rate, and amortization period. While verifying the deliverable, you will typically test whether the application works as desired, the algorithm for calculating monthly payments gives the right results under different conditions, the flow of the application is easy to use, the branding for the broker is as per the approved design (through a previous Validation process!).
Validate Scope is a process of Project Scope Management knowledge area of the PMBOK 5th edition. The verified deliverables from Control Quality are reviewed with the customer or sponsor to ensure they have been completed satisfactorily and to receive formal acceptance. Validation is concerned with the acceptance of the deliverables.
How will a customer give formal acceptance of the deliverables? The client or sponsor will typically test the product/service/result against the requirements document (most importantly business requirements) and requirements traceability matrix. Most often than not, the client is much more concerned if the deliverable meets the stated need of the product/service/result than a list by list technical requirements. In the above example, while validating the mobile calculator application, the client will typically check for the correctness of results under different scenarios, branding, and most importantly whether the application actually serves the real need. The client may realize that in order for the application to be universal, instead of just having a fixed interest rate input, they want to include an option of entering variable interest rates (calculated by automatically downloading the latest prime rate from Bank of Canada).
Following Validation, the client may accept or request for a change (through Integrated Change Control) as a corrective action or defect repair.
Its common sense that Verification should be done before Validation, you won’t take an untested product to a client and bear the embarrassment if the product fails to function as expected; even though this happens all the time. Do remember that both Verification and Validation can also be performed in parallel. I’ll leave it to you imagination on how to accomplish this.
A good discussion of how NASA’s Independent Verification and Validation (IV&V) program defines Validation and Verification can be found here – http://www.easterbrook.ca/steve/2010/11/the-difference-between-verification-and-validation/