Engineering verification and validation services answer two different questions. Verification asks whether the system meets its defined specifications. Validation asks whether it actually achieves the intended use for real people in the expected environment. A product can pass every supplier test yet fail the customer’s purpose when an important requirement was never captured.
This guide explains requirement quality, V&V plans, testing versus analysis, integration, realistic user evaluation, independent challenge, qualified evidence and lifecycle changes. It distinguishes engineering V&V from certification and explains why a pass sheet alone does not establish readiness.
It complements Engineering Quality Assurance Services, Engineering Commissioning Services, Systems Engineering and the Gold Standard Engineering hub.
Verification versus validation in plain English
- Verification: did we realise the specified product correctly?
- Validation: does it fulfil the stakeholder’s actual purpose in its intended use?
- Both need an agreed scope, representative evidence and controlled configuration.
- A passing component test does not necessarily prove integrated service.
- Unresolved needs, deviations and changes must reach authorised engineering decisions.
Follow the evidence from expectation to real use
1. Passing the specification can still leave the customer stranded
A public park installs an interactive wayfinding station. The screen switches languages, displays the correct map files and responds within its performance target. It passes its supplier acceptance tests. On a busy evening, however, a visitor using a wheelchair follows the suggested accessible route and finds that a service gate closes before the park’s public activity ends. The display did what it was specified to do, but the complete wayfinding service failed its actual user.
Engineering verification and validation services distinguish two connected forms of confidence. Verification asks whether a realised product or system conforms to its specified requirements. Validation asks whether that product fulfils the intended purpose for the intended stakeholders in its relevant environment. Both can use tests, analysis, inspections and demonstrations, but their acceptance questions differ.
The gold standard is not a report with every line ticked. It is a transparent chain from real stakeholder expectations to well-defined requirements, suitable evidence, representative use, competent conclusions and changes that fix genuine problems. A technically perfect implementation of an incomplete requirement is still an incomplete engineering outcome.
2. Name the system of interest before deciding how to test it
An engineering product can be a component, assembled machine, building subsystem, software service or integrated public facility. Verification and validation at each level involve different interfaces and evidence. A sensor may be correct, the controller may behave as designed, and the complete service may still fail because users cannot act on the information.
Define the system boundary, required environment, relevant external dependencies and stakeholder roles. Is the scope one supplier’s kiosk, the park’s accessible wayfinding network or the complete visitor journey? The answer determines which tests and acceptance statements are meaningful. A limited assessment can be useful when its limitations are clear.
ISO/IEC/IEEE 15288:2023 provides a life-cycle process framework for engineered systems and systems of systems, from concept through retirement. It does not prescribe one universal development model or technical test that automatically proves every design.
3. Verification answers whether the realised product met the specification
A verification programme starts with the approved requirements and asks for evidence that the product complies. A kiosk might be required to render a particular map layer, respond within a specified time, support listed languages and display accessible-route information. These are technically examinable claims when requirements and conditions are stated clearly.
NASA’s Product Verification guidance distinguishes formal verification through tests, analysis, inspections or demonstrations against the requirements baseline. Its aerospace context is specialised, but the key distinction is general: verification evaluates conformance to the product’s stated engineering obligations.
The verification report must identify the tested version and configuration, the requirement, method, evidence and any unresolved discrepancy. A claim that ‘software passed’ without its version or test conditions has limited value after changes.
4. Validation answers whether the result meets the intended use
Validation follows the stakeholder’s reason for acquiring the system. Visitors want to reach their destination; park staff want understandable information that works when gates, entrances and accessibility arrangements change. Those outcomes are not automatically proved when every screen control passes its component test.
NASA’s Product Validation guidance focuses on whether a realised product meets stakeholder expectations in its intended operational environment. Validation may use actual or appropriately representative conditions and expected users. It is not just informal approval from a manager who likes the product’s appearance.
A useful validation plan examines realistic tasks and consequences, including less convenient scenarios. In the park example, the relevant user journey needs route availability during stated opening hours. A visitor unable to reach a destination has revealed a validation concern even if the map rendering is technically correct.
5. Requirements have to be good enough to verify
A vague requirement such as ‘the kiosk shall be easy to use’ does not state how success can be judged. A poorly defined requirement can produce arguments after delivery because different parties assumed different meanings. The engineering team needs clear, consistent, necessary and appropriately verifiable statements tied to the user’s need.
ISO/IEC/IEEE 29148:2018 provides requirements-engineering processes and guidance, and remains the published edition as of October 2026 following confirmation in 2024. A replacement DIS is under development; it is not yet an adopted revision. The publication emphasises requirements information that can support life-cycle engineering decisions.
Good requirements avoid prescribing a technology unnecessarily when the intended function can be stated more clearly. They also identify operating conditions and exceptions. A perfect implementation of an unrealistic assumption is not a successful requirements process.
6. Traceability connects a user expectation to objective proof
A traceability matrix can link stakeholder need, system requirement, component obligation, verification method and eventual validation evidence. The matrix is useful because it makes missing links visible, not because the spreadsheet itself provides physical assurance. A requirement marked complete should point to a meaningful record describing what was done.
Bidirectional traceability also helps when change occurs. If a public gate schedule changes, which route requirements, map data, kiosk tests and visitor validation scenarios are affected? Conversely, if a test has no linked requirement or credible user outcome, the project should question its purpose.
Strong V&V services maintain identifiers, versions and decision ownership, and do not permit a later approved change to become invisible in the evidence chain. A clean dashboard is not proof that every link remains valid.
7. Select a verification method suited to the claim
Testing uses the product under controlled conditions to obtain evidence about performance. Analysis uses justified models or calculations. Inspection examines observable characteristics, and demonstration may show a specified function. None is inherently superior for every requirement. A dimension may be suitably inspected; a rare environmental condition may require accepted analysis; a user interaction may need an observed demonstration or test.
Methods should be agreed in advance, with acceptance criteria and relevant quality requirements. A test cannot establish a property it does not measure. A model can be useful but depends on its assumptions, while a demonstration can look convincing without capturing important performance data.
NASA’s Product Verification chapter distinguishes these methods and emphasises the configuration, measurement and evidence relevant to each. The engineering team should explain why the selected method is sufficient for the specific claim, including any applicable sector requirements.
8. Component tests and system tests prove different boundaries
A touchscreen can pass a durability check while the route data it displays are stale. A network service can pass its interface tests while users still encounter a locked destination. The owner must know which component functions contribute to the complete experience and how the interfaces are validated.
Integration assessment should follow the service from input through hardware, software, data, utilities, external arrangements and human action. If the kiosk uses a map produced by one contractor and gate schedules maintained by another, the owners must establish how changes are shared and which acceptance tests cover the dependency.
A good programme identifies where component evidence can be reused and where only end-to-end evaluation can support the claim. A supplier’s certificate should not be stretched beyond the object and conditions it actually covered.
9. A realistic user environment cannot be simulated away without explanation
Laboratory tests reduce variation, which is useful for repeatability. They can also exclude the environmental features most important to the customer. A kiosk tested in a quiet office may perform differently in rain, glare, crowds or when the route database changes. The project needs to justify which test conditions represent actual use.
Validation should include relevant users with the capabilities and limitations of the target population where appropriate. For an accessible service, that may include people using mobility devices and people unfamiliar with the area. Staff who designed the interface are often too familiar with it to represent everyone who will depend on it.
Where realistic testing is not possible or safe, use suitable simulations, analysis or staged demonstrations with documented limitations. The correct decision is not always to run the most dramatic trial; it is to gather sufficient defensible evidence without creating uncontrolled hazards.
10. Qualification, verification, validation and certification are not interchangeable
A product may be qualified for a defined environment, verified against specifications, validated for an intended use and subject to a separate statutory certification. These terms serve distinct purposes, and their order or meaning can depend on the sector. A product’s compliance with one commercial standard is not automatic permission to operate a regulated system.
NASA’s verification guidance explicitly distinguishes verification, qualification, acceptance and certification. In public engineering services, contracts and local laws determine which decisions are reserved for registered professionals, authorities or recognised bodies. Calling a project ‘fully validated’ should not imply those other obligations have disappeared.
ISO/IEC 17029:2019 concerns impartial bodies validating and verifying claims within conformity assessment schemes. That scope is different from the engineering V&V processes used to realise an integrated product. The similar words should not lead buyers to assume that accreditation under one scheme certifies every system acceptance.
11. Test articles and configurations must match the delivered asset
A technical test may be valid but refer to an earlier software version, a prototype enclosure or a factory arrangement that differs from the installation. The claim must be tied to the configuration tested. Significant changes to material, geometry, software, interfaces or operating conditions can affect which prior evidence remains relevant.
Configuration records should identify product revisions, relevant supplier versions, instrumentation, data and test environment. If different teams test different combinations, the integration lead needs a defensible way to reconcile them. A product name printed at the top of reports does not prove all reports describe the same object.
V&V services should maintain a change-impact route. The correct response to an alteration is not necessarily repeating every test, but a technically justified assessment of what needs renewed verification or validation.
12. Measurement evidence needs its own quality controls
A testing programme can be undermined by mislabelled channels, unsuitable instruments, uncalibrated references or a data-processing error. A clear result depends on the meaning, location, units and quality of observations, not simply their storage in a formal report.
Tests should define measured quantities and acceptance conditions before execution. The ISO 10012:2026 measurement-management standard provides a framework for reliable measurement processes, while testing and calibration laboratories may operate under ISO/IEC 17025:2017 within their relevant scopes.
The Instrumentation Engineering article develops the physical measurement chain. For V&V, the practical test is whether measurement evidence can support the exact product requirement or stakeholder decision being claimed.
13. Independence should follow consequence and authority
Developers need to examine their own work continually, but some important claims benefit from review by people not responsible for the original design. Independent challenge may reveal assumptions that a team has learned to take for granted. The required level of independence depends on project risk, relevant standards, contracts and regulations.
An independent V&V service can evaluate the test plan, evidence quality, traceability and unresolved deficiencies. It should not claim authority beyond its engagement or professional status. An external observer does not automatically possess the power to approve safety-critical operation simply because their report uses the phrase ‘independent verification’.
Good governance distinguishes a technical finding, an accepted recommendation and a legally authorised approval. The Engineering Design Review Services guide explains how challenge can improve decisions while preserving responsibility with qualified design authorities.
14. Discrepancies are valuable because they reveal the real product
Tests sometimes show that a specified requirement was not met, or that the test setup was unsuitable for a valid conclusion. Both are meaningful results, but the response differs. The team should determine whether the issue is with the product, the requirement, method, measurement or conditions before declaring a corrective action.
Reports need a clear route for recording the result, evaluating significance, assigning a technical owner and verifying resolution. A formal waiver or accepted deviation must be made through the authorised process where permitted; a supplier must not quietly weaken the acceptance criterion after an unfavourable test.
A project with many closed issues is not necessarily better than one where remaining uncertainty is described accurately. The goal is reliable acceptance based on real evidence, not an apparently spotless register obtained by hiding inconvenient observations.
15. A failure of validation may reveal a failure of requirements
Suppose the accessible route in the public park is routinely unavailable after a certain hour. The supplier may have implemented every map requirement correctly, while the customer has discovered a missing operating assumption: route availability during real public use. Simply adding another technical test of the touchscreen will not fix the root problem.
The project may need to revise the stakeholder needs, redesign how route status is represented and establish which organisation maintains the gate and map data. It should evaluate changes across requirements, software, signage, operation and the user’s journey. The result should be revalidated with suitable real-world evidence.
This is why validation is valuable early in a project. Prototype journeys and stakeholder evaluation can reveal wrong assumptions before substantial money is spent on finished hardware. Validation is not only the final celebration after verification has finished.
16. A signed handover is not evidence that users can complete the mission
Engineering projects may reach a contractual milestone with completed test books while users still cannot do the thing the system was commissioned to provide. Some remaining conditions may be acceptable under properly documented limitations; others may require correction before use. The relevant professional or regulatory authority determines what is permitted.
V&V reports should summarise evidence against each relevant requirement and stakeholder expectation, along with the tested configuration, unresolved discrepancies and the basis for acceptance. Operational staff need instructions, current data and responsibilities for keeping the service valid as conditions change.
The Engineering Commissioning Services guide focuses on installed-system readiness. V&V defines the deeper logic of what needs to be verified and validated and how the evidence supports the customer decision.
17. Validation must continue when the system and its users change
Systems do not remain identical after delivery. Software is updated, facilities change, users have new needs and environmental conditions vary. A previous validation may no longer describe the service when an important interface has been modified. A changed opening schedule, for example, can turn an accepted accessible route into an unavailable one.
Owners should know what conditions made the original validation meaningful and which changes would trigger review. The evidence should be preserved in a form that future engineers and operators can understand. A test result detached from its assumptions is weak support for later decisions.
Continuing review need not mean repeating the entire original programme after every trivial change. It means proportionate assessment, controlled updates and renewed evidence where a decision relies on assumptions that may no longer hold.
18. The V&V gold standard is the right system proved in the right setting
Engineering verification and validation services are most useful when they reveal two kinds of problems: failures to build what was specified and failures to specify what users actually need. Neither issue can be solved by counting tests or by obtaining another generic certificate.
Review the complete chain from stakeholder purpose through current requirements, design, component evidence, integrated function, realistic user validation, qualified acceptance and lifecycle change. Can the organisation explain what it verified and what it validated without confusing the two? Can its findings be reproduced and acted upon?
The gold standard is objective evidence in service of a meaningful outcome: a system correctly realised, fit for its intended users and environment, and managed so that future changes do not quietly break the trust established at handover.
Practical case: the accessible route that the kiosk could not deliver
This fictional example illustrates acceptance logic, not a real incident. A public park wayfinding kiosk correctly loads maps, changes language and highlights a route labelled accessible. During an evening user trial, the route leads to a gate that is closed while other park facilities remain open. Technical verification may succeed within its scope, but validation identifies an unmet promise to the visitor.
| Question | Verification evidence | Validation evidence |
|---|---|---|
| Does the map display correctly? | Correct file, interface and defined display result | Does the information help the intended visitor reach the destination? |
| Does the language switch work? | Specified text and screen updates pass | Can representative users understand and complete the task? |
| Is the route identified? | Route dataset and algorithm match the specification | Is the actual route accessible and open when needed? |
| Do all subsystems respond? | Component and interface tests pass their defined limits | Does the end-to-end journey work in normal real use? |
| Has a discrepancy been fixed? | Relevant changed requirements and retests documented | Users can now complete the intended journey under representative conditions |
| Can it remain valid? | Version and maintenance controls exist | Changes in gate schedules and routes trigger a reliable update |
Questions to ask V&V engineering service providers
- Which real stakeholder expectations form the validation basis?
- Are the system boundary and requirements sufficiently specific and traceable?
- What verification method establishes each meaningful technical obligation?
- Do the tested versions and interfaces match the actual delivered configuration?
- Will validation include suitable users and their expected environments?
- Is independence proportionate to the potential consequences and statutory context?
- How will failures, waivers and requirement changes be documented and reassessed?
- Can the final owner explain the evidence and preserve it as the system changes?
Official V&V standards and eduKate crosslinks
- NASA — Product Verification, Methods and Evidence (Systems Engineering Handbook)
- NASA — Product Validation in the Intended Environment
- ISO/IEC/IEEE 15288:2023 — System Life Cycle Processes
- ISO/IEC/IEEE 29148:2018 — Requirements Engineering (current published edition; revision under development)
- ISO/IEC 17029:2019 — Validation/Verification Bodies for Claims, a Distinct Conformity-Assessment Scope
- eduKate — Engineering Design Review Services
- eduKate — Human Factors Engineering
- eduKate — Testing and Inspection Services
- eduKate — Sectors and Services Directory
Engineering V&V evidence must be interpreted within the relevant product, industry, legal and professional framework. A consultant’s V&V report is not automatically a regulated product certificate or permission to operate. This article explains methods and decisions without prescribing safety-critical tests or compliance acceptance. Return to the Gold Standard master hub.