Boehm described a V-shaped software process in 1979, which makes it the earliest documented one (Kneuper, IU International University of Applied Sciences, 2018). Paul Rook’s 1986 paper gets cited as the origin more often, but it came seven years later.
Sommerville’s Software Engineering materials place the V-model in tightly controlled development processes, the kind used for safety-critical systems. It gets drawn as a V because every design phase on the left has a test level waiting on the right. Requirements analysis pairs with acceptance testing, system design with system testing, architecture design with integration testing, and module design with unit testing.
What Is the V-Model?
Every development phase gets a matching test phase, and that pairing is the whole idea. The left arm of the V holds specification and design. The right arm holds the test levels that check that work.
It stretches the waterfall approach by one change. Test planning moves forward, so each test gets designed when its specification is written, not after the code exists.
Each phase ends with a specification or design document and a test plan written against it. A review then closes the phase before the next one opens.
You’ll also see it called the Verification and Validation model.
ISTQB files it with waterfall under sequential life cycle models, as opposed to iterative and incremental ones (Foundation Level Syllabus v4.0.1, 2024).
Don’t confuse it with V-Modell XT. A German government standard shares the name but is a separate, much broader process standard, and it gets its own section further down.
V-Model Phases From Requirements Analysis to Coding
Requirements analysis opens the V. System design follows, then architecture design and module design, with coding at the bottom. That makes five phases, though sources label two of them differently. Architecture design also appears as high-level design, and module design as low-level design.
Development arm
Requirements analysis gathers business and system needs into a requirements document. System design then defines how the system as a whole meets those requirements. Architecture design splits the system into modules and sets how they interact, and module design specifies the internal logic of each one.
The first phase ends in a requirements document. Most teams call it a software requirement specification, with business and system variants (BRS and SRS).
Coding at the vertex
Coding sits at the bottom of the V and has no paired test level of its own.
Programmers implement against the design documents produced in module design. The first test waits one step up the right arm.
Test arm
The right arm climbs from small scope to large. Tests run against single modules first, then assembled modules, then the full system, and last of all against stakeholder needs.
Executable code does not exist before the vertex, so dynamic testing typically cannot start earlier in a sequential model (ISTQB Foundation Level Syllabus v4.0.1, 2024). Testers still work on the left arm, reviewing requirements and designing tests.
Which means the first working software appears only after the whole left arm is complete.
How Each Design Phase Maps to a Test Level
Each level draws its test cases from the work product of its paired phase, which ISTQB calls the test basis. A unit test with no link to a module design has nothing to be wrong against.
| Design phase | Test level | What it checks | Typically run by |
|---|---|---|---|
| Requirements analysis | Acceptance testing | Fit with business needs | Business representatives, intended users |
| System design | System testing | End-to-end behavior against the system specification | Independent test team |
| Architecture design | Integration testing | Interfaces between modules | Developers |
| Module design | Unit testing | Each module in isolation | Developers |
The role column follows the independence example in the ISTQB Foundation Level Syllabus v4.0.1 (2024).
Developers handle unit testing in their own environments, usually with a test harness or a unit test framework. ISTQB calls this level component testing.
Integration tests check module interfaces against the architecture design. Assembly order (bottom-up, top-down, or big-bang) depends on the integration strategy.
ISTQB v4.0.1 lists five test levels: component, component integration, system, system integration, and acceptance. The classic V has no partner for system integration, which tests links to external systems and services.
Tutorials disagree on timing. Some say testing starts once development ends, while others say acceptance test cases get written during requirements analysis. Both hold, for different activities. ISTQB says test analysis and design for a level begins during the matching development phase, while test execution in a sequential model waits for executable code.
The weak spot is easy to see. A wrong requirement passes every left-arm review and surfaces only when acceptance testing runs, at the very end.
Verification vs Validation in the V-Model
Verification asks whether a work product matches the specification it came from. Validation is about the finished product and whether it gives stakeholders what they need.
The NASA Systems Engineering Handbook (SP-2016-6105 Rev 2) draws the same line, with compliance to requirements on one side and accomplishing the intended purpose in the intended environment on the other.
What verification checks
NASA ties verification to the approved requirement set. The product has to meet each “shall” statement, shown by test, analysis, inspection, or demonstration.
At every phase gate, the team is verifying the software work products, with each output reviewed against the one before it.
Static reviews are cheap at this stage. ISTQB lists requirement defects such as ambiguities, contradictions, and omissions among the defects that static testing finds more easily than dynamic testing.
What validation checks
Validation looks outward, not back at a document.
NASA ties it to the concept of operations rather than the requirement set. ISTQB gives acceptance testing the validation role, confirming that the system fulfills the user’s business needs.
Skipping it is a known trap. ISTQB’s seventh testing principle, the absence-of-defects fallacy, says a system can satisfy every specified requirement and still miss user needs, so validating the software is a separate job from verifying it.
Requirements traceability
A requirements traceability matrix links requirements to design elements and test cases, and test cases to results and defects.
Traceable test cases show whether requirements are covered, per ISTQB (Foundation Level Syllabus v4.0.1, 2024). The same links reveal the impact of a change and give auditors a trail.
The matrix only helps while it is current. After a change request, every link the change touched needs an update, or the matrix reports coverage that no longer exists.
V-Model vs Waterfall and Agile
Next to waterfall, the V-Model differs mainly in when tests get designed. Agile is a bigger gap, since it revises scope every iteration and the V fixes it up front.
| Model | Test planning | Change tolerance | Working software |
|---|---|---|---|
| V-Model | During each specification phase | Low, a change reopens paired tests | After the left arm is complete |
| Waterfall | Often deferred to a testing phase | Low | Near the end |
| Agile | Every iteration | High | Every iteration |
The principles behind agile methodology, published in the Agile Manifesto (2001), welcome changing requirements late in development and ask for working software on a cycle of a couple of weeks to a couple of months, shorter preferred.
Waterfall and the V-Model share one weakness. Users see running software late in both, because the V adds earlier checks, not earlier use.
Everything the wider agile versus waterfall debate says about the cost of late change applies to the V-Model too.
The V-Model suits projects where requirements are fixed and signed off before design starts, where an auditor or regulator reads the test evidence, or where a high degree of tester independence is needed, which ISTQB says safety-critical work can call for. Agile suits projects where requirements are still being discovered and users can review increments.
Pick on requirement stability first. Everything else is secondary.
Advantages and Disadvantages of the V-Model
The V-Model gives you control and traceability. You pay in documentation and budget, and flexibility goes too.
Advantages
Every phase has defined deliverables and a review, so progress is easy to measure. Discrete phases also make schedule and cost milestones simple to set, and the audit trail from requirement to test result comes built in.
Disadvantages
- Heavy documentation for every phase
- Higher budget and resource use, because testers work in parallel with developers (Vskills)
- No early prototype for users to react to
- No risk analysis step (Codecademy)
- Requirement changes are hard to absorb
The documentation load is the cost teams feel first. Each phase produces a reviewable set of software documentation plus a matching test plan, and that price only pays off when someone outside the team reads it.
Nothing in the sequence leaves room for software prototyping, so the first thing users can react to is finished software.
The paperwork pays off for fixed scope and regulated review. Elsewhere it mostly doesn’t.
When Does the V-Model Make Sense?
It makes sense when requirements stay fixed and someone outside the team needs evidence that each requirement was tested.
Fit conditions
Project size is the wrong test.
Tutorials recommend the V-Model for small to medium projects with clear requirements. Sommerville’s Software Engineering materials tie it instead to tightly controlled development, such as safety-critical systems, and the DO-178C objective counts below scale with criticality, not headcount.
Read together, the two point at the same variables, requirement stability and compliance burden. Scope should be signed off before design starts, and a standard or customer should demand evidence per requirement. A test team also has to be free to work alongside developers.
Industries and standards
| Standard | Sector | Date | Scope |
|---|---|---|---|
| ISO 26262-6:2018 | Road vehicles | December 2018 | Product development at the software level, from software safety requirements through embedded software testing |
| IEC 62304 | Medical device software | 2006, Amendment 1 June 2015 | Software life cycle processes |
| DO-178C | Airborne systems | December 2011 | Objectives by software level, covering development and verification |
DO-178C ties effort to software level: 71 objectives at Level A, 69 at B, 62 at C, and 26 at D (arXiv paper on Scrum-based aerospace development under DO-178C, 2025).
Meeting software compliance obligations in these sectors comes down to evidence per requirement. ISO 26262-6 lists its software requirements in a design-then-verification order (architectural design, unit design and implementation, unit verification, integration and verification, embedded software testing), which is the bottom-up shape the V-Model draws.
DO-178C is objectives-based, and the same 2025 paper documents a Scrum-based adaptation under its constraints. A V-shaped plan is a choice there, not a requirement.
Wrong-fit cases
Skip it if requirements will change after sign-off, or if users need running software early. Exploratory projects with no stable specification to test against are a poor match too, and so is any project where no auditor or regulator will read the evidence.
Each change reopens a specification and every test paired with it. A team facing frequent change requests ends up spending schedule on change request management instead of building.
If the specification will not hold still and nobody audits the result, the paperwork buys nothing.
Where the V-Model Came From and How It Changed
No single person owns the V-Model. Three separate lines of work, plus a German government standard, all carry the name.
Origin and the credit dispute
- 1979: Boehm introduces a V-shaped sequential process model that stresses verifying and validating results (Kneuper, IU Discussion Papers, 2018)
- 1986: Paul Rook publishes “Controlling software projects” in Software Engineering Journal, volume 1, issue 1
- 1991: Forsberg and Mooz present the systems engineering Vee at a joint INCOSE and ASEM conference (SEBoK)
- 1992: the German Armed Forces publish V-Modell 92 (t2informatik)
- 2005: V-Modell XT replaces V-Modell 97 (Kneuper)
The dates disagree because the sources date different things. Boehm’s is a software process model, Rook’s is a paper often cited for the V-model’s origin, and Forsberg and Mooz describe the systems engineering Vee.
Rook’s credit rests on later citations, such as a CEUR-WS paper that dates the origin of the V-model to the mid-1980s and names Rook and Wingrove, who both published in that first issue.
Kneuper adds a naming wrinkle. He reserves “V-Modell” for the German federal standard and calls Boehm-style models “V-shaped”, and the German name was filed as a trademark owned by the Federal Republic of Germany.
Treat 1979 as the earliest documented V-shaped software model, and skip the single-inventor story.
V-Modell XT
The German standard for planning and running system development projects goes by V-Modell XT, and it’s a separate, larger thing than the generic V.
It grew out of V-Modell 92, which IABG first built for the Bundeswehr and the defense ministry, then V-Modell 97, then the 2005 XT release (“extreme tailoring”).
Authorities, the military and companies all use it, for customers and contractors alike (t2informatik). Weit e.V. coordinates it, with t2informatik listing version 2.3 as current. The model is organized around the products each activity produces (FU Berlin lecture notes), which is why it gets called product-centered.
Tailoring is the point of the XT. It defines project execution strategies for incremental software development, component-based development and agile system development, so it is not one rigid V.
V-Modell XT Bund adapts it for federal authorities as a recommendation, not a mandate, and it leaves hardware development out (t2informatik).
W-model
Spillner’s 2002 paper in the Software Management 2002 proceedings (GI) puts testing at 30 to 40 percent of all software activities, which is his case for starting test work at the beginning of a project.
That is the W-model, which Kneuper describes as two overlapping Vs. It maps testing tasks onto development tasks from the first phase, and Kneuper lists one variant after Herzlich and one after Spillner.
Testing starts earlier than in the plain V, though two parallel streams take more coordination to track.
V-Model FAQ
Does the V-Model include a maintenance phase?
Usually not. Most sources list five phases that end at acceptance testing, though some course notes add production, operation and maintenance above the right arm.
ISTQB handles it separately as maintenance testing, triggered by modifications, migrations, or the retirement of a system.
What are entry and exit criteria in the V-Model?
Entry criteria decide when a phase or test level may start, and exit criteria decide when it counts as finished. In sequential models, ISTQB notes, the exit criteria of one test level often form part of the entry criteria for the next.
Can the V-Model work with agile practices?
Yes, as a hybrid, though the result stops being a pure V-Model because the original does not support iteration of phases.
ISTQB notes that iterative and incremental models run static and dynamic testing at all test levels in each iteration, so each increment can repeat the specification-to-test pairing.
Does the V-Model apply to hardware and systems engineering?
Yes. The systems engineering Vee, presented by Forsberg and Mooz in 1991, spans a whole system from user needs to a user-validated system (SEBoK).
NASA’s Systems Engineering Handbook applies the same verification and validation split to entire products, hardware included.
Which tools manage requirements traceability in a V-shaped project?
Any of the requirements management tools that link requirement, design and test will do. Jama Software and SPEC Innovations (Innoslate) both publish ISO 26262 material built around V-shaped traceability.
Both are vendor sources, so read them as examples, not a ranking.
Setting Up a V-Model Project on Day One
Before design starts, each specification needs its own test plan. Traceability links and sign-off gates between phases have to exist by then too.
Start with the acceptance test plan, written from the requirements specification. Then link requirement IDs to designs and tests, and put sign-off gates between the phases.
Acceptance testing goes first because requirement defects are discovered last, so the gap between introduction and discovery is widest there.
The cost is effort up front. ISTQB’s syllabus (v4.0.1, 2024) accepts extra effort early in exchange for expected savings later.
Regulated teams should recheck the plan when ISO 26262-6 changes. ISO now lists the next edition (Edition 3) as ISO/DIS 26262-6, a draft international standard registered on 4 August 2026 and in the enquiry phase, from a project DIN dates to 21 October 2024 (status checked 9 October 2026). ISO 26262-6:2018 remains the current edition until it is replaced.
Writing the plan itself is the next step, and a guide to the software test plan walks through it.
- 10 Ways Shor’s Algorithm Could Impact Data Security in the Quantum Era - October 14, 2026
- VS Code Extensions That Are Actually Worth Installing - October 13, 2026
- Google Play App Signing Explained - October 11, 2026
