Verification vs validation
Verification asks did we build the product right. Validation asks did we build the right product. Here is the difference, the V-model that connects them, and why both must trace to requirements.
Two questions, not one
Verification confirms that a design output meets its design input: that the thing you built matches its requirements. Validation confirms that the finished product meets the user needs it was intended to satisfy, in its real environment. Put simply: verification is building the product right, validation is building the right product.
Where they sit in the V-model
In the classic V-model, requirements flow down the left side from user needs to detailed design, and testing flows up the right side. Each level of testing verifies the corresponding level of requirements, and validation at the top confirms the product against the original user needs. The two sides are held together by traceability.
An example
- Need: a clinician must be able to set an infusion rate safely.
- Requirement: the pump shall reject rate entries above the configured maximum.
- Verification: a test confirms entries above the maximum are rejected.
- Validation: clinicians using the device confirm the safeguard works in practice.
Why traceability is the point
A product can pass every verification test and still fail validation if the requirements missed the real need. That is why regulated processes require both, traced from need to requirement to verification. Keeping that trace live is exactly what a requirements traceability matrix is for. See how it applies to medical device teams.
Common questions
What is the difference between verification and validation?
Verification checks that you built the product right: that outputs meet their requirements. Validation checks that you built the right product: that it meets the user needs in its intended environment. Verification is against requirements; validation is against needs.
Which comes first, verification or validation?
Verification runs throughout development as each requirement is met. Validation typically comes later, confirming the finished product satisfies user needs. Both feed the traceability record.
Why do regulators care about both?
Because a product can pass verification (it meets its written requirements) and still fail validation (the requirements did not capture the real need). Regulated processes require evidence of both, traced end to end.
Trace verification and validation end to end
Link needs, requirements, and tests, and see coverage stay current.