Verification and validation are related, but they answer different questions:
- Verification: Did we build the system according to its specified requirements?
- Validation: Does the system meet the needs of its intended users and use?
A project can pass one and still fail the other. A system may match its design specification precisely but be difficult to operate in the real environment. Or it may appear to meet a user need while missing a critical requirement.
UK Government digital guidance describes verification as checking that a solution is complete, accurate, reliable and matches its design specification, and validation as checking that it meets business needs.1
Verification checks the defined solution
Verification asks whether the deliverable conforms to its requirements and design. Depending on the project, it may include:
- Reviewing requirements and design documents.
- Inspecting installation or configuration.
- Checking calculations or analysis.
- Testing components and interfaces.
- Confirming that test results meet stated acceptance criteria.
- Reviewing that required documentation is complete and consistent.
A useful verification activity has a clear requirement, method, acceptance criterion and recorded result. If the requirement cannot be tested or otherwise assessed, it may need clarification.
Validation checks the intended use
Validation asks whether the solution works for the people and operational context it is meant to serve. It may involve:
- Demonstrating an operational scenario.
- Confirming that users can complete a task.
- Reviewing the system in its intended environment.
- Checking that the delivered capability supports the agreed outcome.
- Gathering operational feedback after transition.
Validation is not simply another name for final testing. It tests whether the project has defined and delivered the right outcome.
A practical example
Suppose a project delivers a monitoring and alarm system.
- A verification test could confirm that each configured alarm matches the approved setpoint and is displayed as specified.
- A validation exercise could confirm that operators can recognise the alarm, understand the required response and use the system effectively during the intended operating scenario.
The example is illustrative. Actual requirements and test methods must come from the project’s approved design, safety and operational documentation.
Plan both early
Verification and validation should be planned while requirements and system boundaries are being defined. For each important requirement or outcome, ask:
- How will we demonstrate conformance?
- Who needs to review or witness it?
- What evidence will be retained?
- What conditions must be in place?
- How will issues and retests be controlled?
Keep traceability between needs, requirements, design decisions, test activities and results. This helps teams understand what has been demonstrated and what remains open.
Record the outcome, not just the activity
A test record should show what was tested, against which requirement or acceptance criterion, under what conditions, by whom, and with what result. “Test completed” is not enough if the evidence cannot show what the test established.
If a result does not meet the criterion, record the issue, assess its impact and agree corrective action. A retest should confirm the relevant behaviour after the change.
Why both matter
Verification provides evidence that the solution conforms to its defined requirements. Validation provides evidence that the solution is suitable for its intended use. Together, they give project teams and stakeholders a clearer basis for acceptance and transition.
EJH Engineering Consultants helps teams define requirements, plan assurance activities and coordinate technical deliverables across the system lifecycle.
Discuss your project with EJH Engineering Consultants.