What Is a Verification and Validation Plan (V&V Plan)?
A Verification and Validation plan—V&V plan—is the document that commits a program to answering two fundamental questions about the system it is building: did we build the system right, and did we build the right system? Those two questions sound similar but demand completely different technical activities, different stakeholders, different acceptance criteria, and often different timelines.
In aerospace, defense, and medical device development, a V&V plan is not optional documentation produced to satisfy a program manager’s checklist. It is a contractual and regulatory instrument. For defense programs, DO-178C, MIL-STD-882, and MIL-STD-1521 all reference V&V obligations either explicitly or through derived requirements. For medical devices, FDA’s 21 CFR Part 820 and ISO 13485 require documented V&V processes with auditable evidence. For civil aviation software and airborne systems, DO-254 and the broader ARP 4754A guidance place V&V activities at the center of development assurance. Getting the plan right early is not bureaucratic overhead. It is the foundation on which all evidence of correctness rests.
Verification vs. Validation: The Distinction That Matters
The confusion between these two terms is common enough to cause real program damage, so it is worth being precise.
Verification confirms that a system, subsystem, or component satisfies its stated requirements—the specifications, design documents, and interface definitions the team wrote. It is an internally referenced activity. You are checking work against your own declared intent. The methods are inspection, analysis, demonstration, and test. A structural analysis confirming that a bracket meets its load requirement is verification. A software review confirming that a function implements its specification is verification.
Validation confirms that the system satisfies the actual need of the end user or operator in the intended environment—regardless of what any specification says. It is externally referenced. You are checking the system against reality, not against your own documents. An operational evaluation where a pilot flies a representative mission and confirms the system behaves correctly is validation. A clinical trial where patients use a device and outcomes are measured is validation.
The key implication: a system can pass all verification activities and still fail validation. Every requirement could be met as written, and the system could still be wrong—because the requirements were wrong. This is why both activities are mandatory, not interchangeable.
In practice, verification runs throughout development, typically at the unit, subsystem, and system levels. Validation runs primarily at the end, once an integrated system exists that can be put in front of actual users or realistic operating conditions. Both require a plan.
The Five Core Elements of a V&V Plan
A V&V plan that meets the expectations of aerospace primes, defense program offices, and FDA reviewers will contain at minimum five structured elements. Programs that omit or compress any of these tend to find the gap during an audit or a CDR/PDR review, not at a time of their choosing.
1. Scope and Applicability
The plan opens by defining precisely what is covered. This includes the system configuration, the applicable standards and specifications, the contract or regulatory drivers, and what is explicitly out of scope. Out-of-scope declarations are as important as in-scope ones—they prevent scope creep in evidence packages and clarify responsibility boundaries when subsystems are supplied by external vendors.
Scope also includes the applicable life cycle phase. Some programs produce a single V&V plan spanning the full program. Others produce phase-specific plans for SRR, PDR, CDR, and qualification. Either approach is defensible. What is not defensible is a plan that does not state which phase and configuration it addresses.
2. Requirements Mapping and Coverage
Every requirement that the program is obligated to verify or validate must appear in the plan—or be explicitly deferred to a subordinate plan with a documented rationale for the deferral. This mapping is frequently called a Verification Requirements Matrix (VRM) or a test coverage matrix, and it becomes one of the primary audit artifacts when a customer or regulator wants to know that nothing was forgotten.
The matrix links each requirement to at least one V&V method, at least one responsible party, and at least one acceptance criterion. Requirements that are not mapped are requirements that are not controlled. This is where most immature programs have gaps.
3. Methods Selection and Rationale
The plan specifies which verification or validation method applies to each requirement, and in many regulatory and contractual contexts, explains why. The four standard verification methods are:
- Inspection: Examination of the item against the requirement without activating the system. Used for physical attributes, labeling, materials, and documentation.
- Analysis: Mathematical, computational, or logical evaluation. Used when physical testing is impractical or when the requirement concerns a modeled behavior.
- Demonstration: Operating the system and observing that it performs a function, without detailed measurement. Used for functional requirements where pass/fail is qualitative.
- Test: Exercising the system under defined conditions and measuring quantified outputs against stated acceptance criteria. Used where requirements specify measurable performance thresholds.
Validation methods map roughly onto the same categories but are evaluated against user need rather than specification. Operational testing, user acceptance testing, clinical evaluation, and simulation-based validation all appear in this section.
Method selection is not arbitrary. Choosing analysis over test for a safety-critical requirement requires justification. Choosing demonstration over test for a requirement with a numeric threshold is usually wrong and will be flagged.
4. Test Environments and Configurations
For each test or demonstration activity, the plan identifies the environment in which it will be conducted: laboratory, hardware-in-the-loop (HIL), software-in-the-loop (SIL), environmental chamber, flight test, human-factors lab, or production representative facility.
Environmental requirements—temperature, humidity, vibration profiles, electromagnetic environment, altitude simulation—are specified here. The plan also identifies the configuration under test: which hardware revision, which software build, which firmware version. This is critical for traceability. An anomaly discovered during test needs to be tied to a specific configuration so the finding can be correctly dispositioned and, if necessary, retested after a fix.
This section also identifies any special equipment, calibrated instrumentation, or certified facilities required. Tooling lead times for environmental test facilities are long. Programs that document this late discover schedule problems late.
5. Success Criteria and Closure Requirements
Every V&V activity in the plan must have explicit success criteria—the conditions under which the activity is considered complete and passing. “The system shall work correctly” is not a success criterion. “The system shall complete target acquisition within 450 milliseconds in 95% of 100 consecutive trials under the conditions defined in Test Procedure TP-021” is a success criterion.
The plan also states what constitutes closure: what documentation must exist, who signs off, and what happens to open anomalies at the time of closure. Programs with weak closure definitions find themselves in disputes at qualification review about whether testing is complete.
Why Static V&V Plans Fail
The plan described above, properly written, represents the state of program requirements at a single point in time. Requirements change. Interface definitions evolve. Customer priorities shift. Risk trades move performance margins. Every one of these changes potentially affects which requirements exist, what they specify, and therefore what V&V activities are required to close them.
A V&V plan maintained as a Word document or a PDF in a document management system has no awareness of upstream changes. When a requirement is revised, someone must manually identify the affected test cases, update the matrix, update the procedures, and re-obtain approvals. In practice, this manual synchronization fails. By the time a program reaches qualification, the V&V plan frequently does not reflect the current requirements baseline, and the coverage matrix has gaps that were created by requirement changes that were never propagated downstream.
This is not a theoretical risk. It is a documented failure mode in defense acquisition programs. The Government Accountability Office has cited requirements instability as a persistent cause of test failures and cost growth across major defense programs. Medical device recalls have been traced to validation plans that did not cover design changes made after the original plan was approved.
How Modern Tooling Addresses the Liveness Problem
The underlying issue is that a V&V plan is inherently a dependency graph. Requirements connect to methods. Methods connect to test cases. Test cases connect to environments and procedures. Results connect to closure status. When any node in that graph changes, the downstream nodes are affected. Document-based systems cannot represent that graph or propagate changes through it. Graph-based requirements platforms can.
Flow Engineering is built around exactly this model. Requirements are nodes in a connected graph, not rows in a spreadsheet or paragraphs in a document. V&V coverage is a relationship type in the graph: a requirement can be linked to the verification method assigned to it, the test case that exercises it, and the result that closes it. When an engineer revises a requirement, the graph immediately surfaces which test cases are affected—because those test cases are connected to the original requirement node.
This means a V&V plan managed in Flow Engineering is not a static artifact. It is a live view into the current state of coverage across the requirements baseline. A project lead can query the graph to see all requirements without an assigned verification method, all test cases linked to requirements that have changed since the test was last run, or all validation activities without a documented success criterion. These queries return current answers, not answers that were accurate when the document was last revised.
Flow Engineering also supports the traceability structure that aerospace and defense customers require at CDR and qualification reviews. Bidirectional traceability—from system requirement down to unit test and back up—is navigable in the tool rather than reconstructed manually for each review. For programs working to DO-178C, DO-254, or FDA submission standards, this significantly reduces the labor cost of producing compliance evidence packages.
One honest point about scope: Flow Engineering is purpose-built for requirements and V&V traceability. It does not replace test execution management platforms or configuration management systems. Teams running high-volume automated test suites need those systems in addition. What Flow Engineering eliminates is the disconnection between the requirements layer and the test coverage layer—the gap where most compliance risk lives.
Practical Starting Points
For programs building a V&V plan for the first time or restructuring an existing one, the order of operations matters.
Start with requirements—not test cases. A V&V plan that begins from test procedures tends to miss requirements that do not have obvious corresponding tests. Beginning from requirements and asking “how will we close this?” for every single one forces coverage to be complete.
Establish the coverage matrix before methods are selected. Knowing what must be covered prevents methods from being chosen for convenience rather than rigor. Inspection is faster than test. If inspection is selected for a performance requirement to save schedule, that choice should survive scrutiny—and it usually does not.
Review the environmental requirements section against actual program schedule and budget before the plan is approved. Discovering that a required environmental chamber is unavailable during the test window at CDR is expensive. Discovering it at plan approval is not.
Finally, treat the V&V plan as a configuration-controlled document with the same change control discipline applied to requirements. Every time a requirement changes, the coverage matrix entry for that requirement is reviewed. This discipline is difficult to maintain manually. It is the primary operational reason to move V&V planning into a connected requirements platform rather than managing it as a standalone document.
A V&V plan that is accurate, complete, and current at the time of qualification review is the product of continuous maintenance, not a pre-test documentation sprint. Building the tooling and process discipline to support that maintenance is an investment that pays out when it matters most—when the program is under audit and the evidence needs to speak for itself.