Verification vs. Validation in Systems Engineering: Why Teams Keep Getting It Wrong
Ask ten engineers to define “verification” and “validation” and you will get twelve answers. Ask those same engineers to point to the verification evidence for a specific requirement and at least three of them will hand you a document that is actually validation evidence. The confusion is not academic. Under ARP4754A and DO-178C, conflating the two is an auditable finding. On programs without regulatory oversight, it still causes late-cycle surprises when systems meet their specifications but fail in operation.
The definitions are not subtle. Verification asks: did we build the system right? — meaning, does the implementation conform to its specification? Validation asks: did we build the right system? — meaning, does the system satisfy the actual need it was built to address? One is inward-facing, comparing artifact to artifact. The other is outward-facing, comparing system to world.
Getting this wrong is pervasive because the mistake is easy to make and invisible until it costs you.
The Core Distinction, Made Operational
Verification is a closed comparison. You have a requirement. You have an implementation. Verification is the structured act of confirming the implementation satisfies the requirement. It is always traceable to a specific requirement statement, and every requirement should have exactly one assigned verification method.
The traditional framework for organizing verification methods is the TAID quadrant:
- Test — exercising the system with defined inputs and observing measured outputs against acceptance criteria. The most rigorous method, required for safety-critical functions in most aerospace standards.
- Analysis — mathematical, logical, or computational examination of the design without physically exercising it. Finite element analysis of a structural component, worst-case circuit analysis, and static code analysis all qualify.
- Inspection — examination of the artifact — hardware, code, document — to confirm it possesses a required property. Confirming a label is present, a connector is the correct gender, or a software module has no dynamic memory allocation.
- Demonstration — exercising the system and observing behavior without quantitative measurement. Confirming a user interface workflow completes without error, for example.
Each verification method produces objective evidence. That evidence is traceable to a requirement. If you cannot identify which requirement a piece of test data closes, it is not verification — it is testing in the informal sense, which has its place but does not satisfy a compliance record.
Validation, by contrast, is open-ended and customer-centric. There is no specification to close against — the specification is itself what you are questioning. Validation methods are scenario-based: operational simulations, field trials, human factors evaluations, customer acceptance testing, use-case walkthroughs with end users. The question being answered is whether the system, as defined and built, actually addresses what the stakeholder needed. Validation can reveal that the system passes all its requirements beautifully and still fails operationally — which is the most expensive kind of failure.
Where Each Fits in the V-Model
The V-model is not decorative. It is a structured map of when and at what level of abstraction each activity occurs.
The left side of the V is decomposition: stakeholder needs flow down into system requirements, then system architecture, then subsystem requirements, then component specifications. Each level of decomposition produces a specification.
The right side of the V is integration and verification: components are built and verified against their component specifications, integrated into subsystems and verified against subsystem requirements, integrated into the system and verified against system requirements.
Verification lives on the right-side ascent, paired level-by-level with the left-side decomposition. A component verification activity closes against its component specification. A system-level verification activity closes against system requirements. The pairing is not optional — a system-level test does not retroactively verify a subsystem requirement that was never tested at its own level.
Validation sits at the apex — the top right of the V. Once the system is integrated and verified, it is presented to stakeholders and operated in representative scenarios to confirm it satisfies the original need. In practice, validation activities also happen earlier, particularly when requirements are being written. Reviewing a concept of operations with customers before a single requirement is baselined is an early-lifecycle validation activity. The goal is to catch mismatches between what stakeholders need and what engineers are about to specify, before verification evidence has been generated for the wrong specification.
Understanding this placement matters because it tells you who owns each activity. Verification is largely an engineering and quality function — it compares internal artifacts. Validation involves the customer, the end user, the operator, or credible surrogates for those parties. Excluding operators from validation is one of the most reliable ways to build a system that passes review and fails in the field.
Why It Matters Under ARP4754A and DO-178C
ARP4754A (Guidelines for Development of Civil Aircraft and Systems) explicitly distinguishes between the Validation process and the Verification process as separate lifecycle activities with separate planning artifacts. The Development Assurance Plan must address both. Safety assessments depend on validated safety requirements — requirements that have been confirmed to be correct and complete, not just verifiable. A requirement that is verifiable but not valid contributes nothing to safety.
DO-178C (Software Considerations in Airborne Systems and Equipment Certification) requires that verification objectives be assigned to specific software requirements and that every requirement be verified by at least one method. It distinguishes between software verification and system validation, and the distinction is audited. An DER reviewing your software accomplishment summary will ask: which requirement does this test case verify? If the answer is “it validates overall system behavior,” the test case may be appropriate, but it does not close the software verification gap.
The practical compliance consequence: if your verification coverage matrix shows requirements with no assigned method, you have an open gap. If your validation evidence consists only of verification test reports, you have a different open gap. Auditors understand the difference. Programs that conflate the two often spend significant time at certification review reconstructing evidence and reclassifying activities — expensive, schedule-consuming work that is entirely avoidable.
The Common Mistakes, Named Specifically
1. Calling simulation verification when it should be validation.
Simulation is a legitimate analysis method under TAID — but only when the simulation is of the implementation itself, using model parameters derived from the actual design, producing outputs that close specific requirement acceptance criteria. When simulation is used to explore whether the system will behave correctly in operational scenarios, assess usability, or predict emergent behavior, it is a validation activity. The distinction matters because the evidence standard is different. A simulation that answers “does the system respond within 200ms per Requirement 4.3.1?” is verification analysis. A simulation that answers “can pilots manage the workload during a dual-engine failure in IMC?” is validation. Most programs run the second type and log it as the first.
2. Writing requirements that cannot be verified.
“The system shall be reliable” is not verifiable. “The system shall be maintainable” is not verifiable as written. “The system shall provide a good user experience” is not verifiable. These statements might be meaningful goals, but they are not requirements in the engineering sense because there is no defined condition of satisfaction. A verifiable requirement specifies a measurable outcome, a defined stimulus, and an acceptance threshold. If you cannot describe the TAID method that would close it, the requirement is incomplete. This is not a pedantic distinction — unverifiable requirements create scope ambiguity, contract disputes, and audit findings.
3. Treating customer acceptance testing as the only validation.
Customer acceptance testing is one validation activity, typically late-lifecycle. Treating it as the sole validation means that stakeholder misalignment — wrong operational concept, wrong use cases, wrong environmental assumptions — is not discovered until the system is complete. Early validation activities, including requirements reviews with operators, scenario walkthroughs, and prototype evaluations, exist precisely to move that discovery forward in the schedule where it is recoverable.
4. Using verification evidence to answer validation questions.
A system that meets all its specifications is verified. It is not thereby validated. This conflation produces the classic “the system does exactly what the spec says, but it doesn’t do what we need” program outcome. The verified-but-not-validated system is not rare — it is the normal outcome when validation is treated as a downstream phase rather than a lifecycle-spanning activity.
How Modern Tools Are Addressing This
The V&V gap is not just a process problem — it is a tooling problem. Most legacy requirements management tools — IBM DOORS, Polarion, Codebeamer — can store verification method assignments as attributes on requirements, but they do not actively enforce completeness. A requirement with no assigned verification method looks identical to one that does. The gap is invisible until someone runs a report, which happens when someone remembers to run a report.
This is where AI-native requirements tools are changing the operational reality. Flow Engineering automatically flags requirements that have no assigned verification method, surfacing the gap in real time as requirements are authored, not after a requirements review or a program audit. Rather than waiting for someone to notice a missing field, the tool makes the absence structurally visible — treating an unverified requirement the same way a compiler treats an uninitialized variable: as an error state that needs resolution before you proceed.
Flow Engineering’s graph-based model of requirements and their relationships also makes it easier to distinguish what is being verified at each level. Because traceability is first-class — requirements link to verification activities, which link to evidence — the question “does this simulation close a verification gap or a validation gap?” becomes answerable by examining the graph structure, not by re-reading documentation and making a judgment call.
For teams operating under ARP4754A or DO-178C, the practical consequence is that the coverage matrix is not a separate artifact assembled at review time — it is a live view of the current state of the program. Requirements without methods show up immediately. Evidence linked to the wrong level of the hierarchy is visible structurally.
Practical Starting Points
If your program is currently blurring verification and validation, the recovery path is straightforward even if it is not fast:
Audit your requirements for verifiability. For every requirement, identify the TAID method that would close it. If you cannot, the requirement needs to be rewritten before verification planning can proceed.
Audit your evidence for correct classification. For every piece of test or analysis evidence, confirm it is closing a specific requirement at the correct level of the hierarchy. Evidence that answers stakeholder-level or operational questions is validation evidence; log it accordingly.
Establish validation activities at multiple lifecycle points. Concept of operations reviews, prototype walkthroughs, and operational scenario evaluations belong in the early program schedule — not only in acceptance testing.
Assign verification methods at requirement authoring time, not at test planning time. The verification method is a property of the requirement, not of the test program. If a requirement is written without a method, the test team will assign one later under schedule pressure, which is how untestable requirements become silent scope gaps.
The distinction between verification and validation is one of the most consequential in systems engineering. It determines what evidence you need, who needs to be involved, when activities occur, and whether your compliance record is actually complete. Getting it right is not difficult — but it requires treating the two as genuinely distinct processes rather than interchangeable labels for “testing stuff.”