V-Model: The Verification and Validation Lifecycle Explained

By Tara Minh · Updated Oct 10, 2026

The V-model is a sequential project lifecycle that pairs every development phase on the way down with a testing level on the way back up. Requirements are matched by acceptance testing, design by integration testing, and code by unit testing, so test planning starts the moment each phase is written, not after the build.

Key Facts

• Paul Rook described the V-model lifecycle in a 1986 paper, "Controlling Software Projects", in Software Engineering Journal (DOI 10.1049/sej.1986.0003).
• Germany's V-Modell XT has been publicly available since its release in February 2005 and was set as a binding development standard for federal IT projects (Computerwoche).
• NASA frames verification as "Was the end product realized right?" and validation as proving "the right product was done" (NASA Systems Engineering Handbook).
• The model has two halves: a left side of specification phases and a right side of matching test levels, joined at the point where code gets written.

What the V-model is and where it came from

Picture a lifecycle bent into the letter V. You move down the left arm through increasingly detailed specification: business needs, system requirements, architecture, detailed design. You hit the bottom when the work is actually built. Then you climb the right arm, testing at a level that matches each specification you wrote on the way down.

That pairing is the whole idea. Think of it as a waterfall that refuses to leave testing to the end. Where classic waterfall draws testing as a single late phase, the V-model draws it as a set of test levels, each one designed against a specific document.

Paul Rook is the name most often attached to the model. His 1986 paper, "Controlling Software Projects", appeared in Software Engineering Journal, and later research papers credit him with introducing the V-model lifecycle as a guideline for software development (Informatica, 2018). Its stated aims were better efficiency and more reliable software.

The other big thread is public-sector. Germany's V-Modell XT is described in a technical paper as the process model that a public client can make mandatory for a supplier, and it has been downloadable by anyone since February 2005 (TU Munich paper). A variant for federal agencies, V-Modell XT Bund 1.0, was published by the Bundesverwaltungsamt in March 2010 (Vergabeblog). That's one reason the V-model keeps showing up in government and defense contracts: a client can write it into the procurement.

Verification vs validation

The V-model lives or dies on two words that people mix up.

Verification asks whether you built the thing to its specification. NASA phrases it as "Was the end product realized right?" Verification checks work against the document that came before it: does the code match the design, does the design satisfy the requirements?

Validation asks whether you built the right thing. NASA's handbook puts it this way: verification proves whether the product was done right, while validation proves whether the right product was done (NASA SEH, product validation). Validation checks against what the user or customer actually needs.

You can pass every verification step and still fail validation. A billing module can match its spec to the decimal and still be useless because the spec misunderstood how finance closes the month. That's why the top of the V (acceptance testing against business needs) is the validation level, and the lower levels are mostly verification.

The left side and right side, paired

This table is the heart of the model. Each row on the left produces a document, and the matching row on the right tests against that exact document.

Two practical consequences follow. First, acceptance criteria get written during requirements, not after the build, because that's when acceptance tests are designed. Second, every test case traces back to a requirement, which is exactly what a requirements traceability matrix records.

V-model vs other lifecycles

The V-model sits at the disciplined end of the spectrum. Here's how it compares with its neighbors.

The W-model is often described as a V-model variant that makes verification activities, such as reviewing requirements documents, a parallel track in their own right. Treat that as a team convention rather than a formal standard; the label matters less than the habit of reviewing documents before building from them.

For the wider decision between sequential and iterative approaches, see Agile vs Waterfall. And if your project has a stable core and an uncertain edge, hybrid project management lets you run a V-style discipline on the part that can't change.

When the V-model fits, and when it doesn't

It fits when requirements are knowable up front, when a defect found late is expensive or dangerous, and when a client or regulator wants documented evidence that each requirement was tested. Typical examples are embedded control software, public-sector systems, and hardware-dependent products where you can't patch easily after release.

It struggles when you don't yet know what users want. Because the left side commits to detailed documents before anything runs, a wrong early assumption travels all the way down and gets caught only at the top right, which is the most expensive place to learn it. The cone of uncertainty explains why early estimates and specs are at their shakiest exactly when the V asks you to freeze them.

How to run a V-model project, step by step

1. Write requirements you can test. Every requirement needs a way to check it. If you can't imagine the test, rewrite the requirement. Give each one an ID.
2. Design acceptance tests now. While business requirements are fresh, draft the acceptance test conditions with the people who'll sign off. Don't wait for the build.
3. Specify the system and plan system tests. Turn needs into system requirements, and write the system test plan against that document at the same time.
4. Design the architecture and plan integration tests. Define components and interfaces, then define how you'll prove they connect correctly.
5. Detail each module and plan unit tests. Developers write module designs and the unit test cases that go with them.
6. Build. Implement against the designs. Run static reviews and code reviews here; they're verification too.
7. Climb the right side in order. Run unit tests, then integration, then system, then acceptance. Don't skip a level because the one above looks fine.
8. Trace and close. Link each requirement to its tests and results. Unresolved gaps go to a change control process, not into someone's inbox.
9. Hold an exit review per level. Treat each test level as a gate with entry and exit criteria, much like a stage-gate process.

V-model test planning template

Copy this table into your test plan and fill one row per requirement. It forces the pairing the model depends on.

Add columns for risk level and defect IDs if your team needs them. Keep the Req ID unique and stable so the trace never breaks.

Examples by function and industry

Software product. A payments team writes the acceptance conditions for refunds during requirements. Integration tests for the payment gateway interface are drafted when the architecture is approved. Unit tests accompany each module design.

Public-sector IT. An agency contracting a supplier can mandate a process model in the tender. The German federal government did this with V-Modell XT, and its Bund variant tailors the model for federal agencies (Vergabeblog).

Embedded and hardware-linked products. Firmware for a device is hard to patch after shipping, so teams invest in unit and integration testing before hardware-in-the-loop system tests. The V's ordering matches how the physical build progresses.

Regulated industries, such as medical devices or automotive. These sectors have their own safety and quality standards, and many teams draw their lifecycle as a V to show that every requirement has a matching verification and validation activity. If you work in one, map the V to the standard your auditor actually uses and take the required terminology and evidence from that document, not from a general article.

Operations and business change. Even a non-software rollout, such as a new order-to-cash process, can use the idea: define the business outcome, design process steps, then plan a pilot (validation) that checks the outcome and a walkthrough (verification) that checks each step. See the project life cycle for how phases map to non-software work.

Do's and don'ts

Do:

• Design each test level when its matching specification is written.
• Give every requirement a unique ID and at least one test.
• Review documents before building from them. A wrong requirement caught in review is cheap; the same one caught in acceptance is not.
• Keep acceptance tests owned by the business, not only by QA.
• Agree entry and exit criteria for each level before testing starts.
• Run a pre-mortem on the requirements phase to find the assumptions most likely to fail late.

Don't:

• Don't treat the V as a license for huge specification documents nobody reads.
• Don't skip levels under schedule pressure. Cutting integration testing is how interface bugs reach production.
• Don't write tests after the code and call it V-model; you've just relabeled waterfall.
• Don't freeze requirements you can't yet justify. If the unknowns are large, break the work into increments or move to an iterative approach.
• Don't confuse verification with validation in your reporting. A green unit-test run says nothing about whether users want the feature.

Common mistakes

The most frequent failure is a V in name only: the diagram is on the wall, but tests are still written after the code. Second is orphan requirements, where nothing traces to a test, so nobody notices a requirement was never checked. Third is treating acceptance as a ceremony; if the customer first sees the product at the top of the right arm, you've invited the expensive surprise the model was meant to prevent.

A quieter mistake is applying a V to work where learning is the point. Discovery projects, early product bets, and anything where you'd rather learn in two weeks than document for two months are better served by shorter loops. You can still borrow the V's best habit, which is writing the test before the thing it tests.

Where to go next

If the V-model suits your project, start with the pairing table: list your requirements, assign each a test level, and write the acceptance tests before anyone writes code. If it doesn't suit, Agile vs Waterfall will help you choose a better fit, and the definition of done gives iterative teams the same clarity the V gives sequential ones.