V Model Software Development: Phases, Testing Levels and When to Use It in 2026

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Delivering plan-driven and hybrid programmes for regulated US and EU clients

V model software development is a sequential way to build software in which every development phase has a matching testing phase, and the test for each phase is planned at the same time as the phase itself. The model is drawn as a letter V: design work descends the left arm, coding sits at the bottom, and testing climbs the right arm. It sounds like a 1990s idea, and it is one. Yet in 2026 it still underpins audits in automotive, medical devices, avionics and government IT, because regulators in those fields want proof that every requirement was tested.

That proof is the reason the V survives. A modern team may ship in two-week sprints, but when an ISO 26262 assessor or an FDA reviewer arrives, they ask for a chain from each requirement to its design, code and test result. That chain is exactly what the V produces. It is also why most teams delivering enterprise software development for regulated industries still structure their test evidence around the V, even when day-to-day work runs in sprints.

This guide explains the V model of software development from first principles: what each side of the V does, a copyable text diagram, a worked requirements traceability example, an honest list of advantages and disadvantages, a comparison with waterfall, agile and the W-model, and a practical view of when the V is the right choice and when it is not.

What is V model software development?

V model software development is a plan-driven software development life cycle in which each development phase on the left side of the V is linked to a test level on the right side that will later check it. The left side is verification: are we building the product right? The right side is validation: are we building the right product? Coding sits at the vertex, where the two sides meet.

The model is generally described as an extension of the waterfall model. Waterfall runs phases one after another and puts testing near the end. The V keeps the same sequence for building, but bends the line upward after coding, so each test level faces the design phase it validates. Kevin Forsberg and Harold Mooz popularised the V shape for systems engineering in a 1991 paper. Since then it has been adopted by the medical device industry, used in US Federal Highway Administration systems engineering guidance, and formalised in Germany’s federal V-Modell XT standard for public-sector IT projects.

If you are placing the V among other approaches, it belongs to the plan-driven family of the software development life cycle, next to waterfall, and opposite the iterative family that includes Scrum and Kanban. Our overview of other software development methodologies maps all of them side by side.

Verification vs validation in the V model

Verification and validation answer two different questions, and the V model puts each on its own arm. The table below shows how the distinction works in practice.

V-model software development diagram: how the two sides connect

A v-model software development diagram shows development phases going down the left arm, coding at the bottom, and test levels coming up the right arm, with a horizontal link between each pair. The link is the important part. It means the test plan for the right-hand phase is written while the left-hand phase is being done, not after the code exists.

Read the diagram top-left, down to the vertex, then up the right. Phases 1 to 4 narrow the scope from business needs to individual modules. Phase 5 turns the module designs into code. Phases 6 to 9 widen the scope again, from single units to the whole system in the customer’s hands. Each horizontal pair shares a level of abstraction, so the test always checks the work done at the same level.

The same pairing as a reference table, with the artifact each phase produces and the usual sign-off owner:

The verification phases (left side of the V)

The verification phases on the left side of the V turn a business need into a design detailed enough to code, and each one also writes the test plan for its partner on the right. Verification here is mostly static: documents are reviewed, inspected and signed off before work moves down a level.

Business requirements analysis (+ acceptance test plan)

Business requirements analysis captures what the customer and users need the system to do, in their language. Analysts run workshops and interviews, then write a requirements specification with functional and non-functional requirements, each with a unique ID. At the same time, the team drafts the acceptance test plan: for every requirement, how will the customer later confirm it works? Writing that acceptance criterion now quickly exposes vague requirements such as “the system must be fast”.

System design (+ system test plan)

System design translates business requirements into system requirements and a description of the complete system: hardware and software boundaries, external interfaces, data flows and performance targets. In automotive or medical projects this is where software and hardware requirements split. The system test plan is written alongside it, defining the end-to-end scenarios, environments and data needed to test the integrated system against these system requirements.

Architectural design / HLD (+ integration test plan)

Architectural design, or high-level design (HLD), breaks the system into components and defines how they communicate: APIs, message formats, databases, third-party services and error handling between them. The integration test plan is created in parallel and targets exactly those seams. It specifies which interfaces are tested, in what order components are combined, and which stubs or simulators replace parts not yet built.

Module design / LLD (+ unit test plan)

Module design, or low-level design (LLD), describes the internal logic of each component: classes, functions, algorithms, data structures and boundary conditions. It is the last step before code. The unit test plan is written here, listing for each module the inputs, edge cases and expected outputs a unit test must cover. In safety-critical work this is also where structural coverage targets, such as statement or MC/DC coverage, are set.

Coding: the vertex of the V

Coding is the point of the V where design turns into software, and the right side begins. Developers implement each module to its low-level design, following coding standards (MISRA C in automotive, for example) and passing code review and static analysis before unit testing starts. Because the unit test plan already exists, developers know before they write a line exactly which behaviour will be checked.

The validation phases (right side of the V)

The validation phases on the right side of the V execute the test plans written earlier, moving from the smallest unit of code up to the complete system in the customer’s environment. In the software development v model, each level tests against the specification of its partner phase, not against the code alone. That is what makes a failed test easy to trace back to its cause.

Unit testing

Unit testing checks each module in isolation against its low-level design. Developers or dedicated testers run the unit test plan, usually through an automated framework, with dependencies replaced by mocks or stubs. A unit test failure points directly to a coding error or a flaw in the module design, which is the cheapest place to fix it on the right side of the V.

Integration testing

Integration testing checks that modules work together as the architecture says they should. Teams combine components step by step, using top-down, bottom-up or a mixed strategy, and exercise the interfaces defined in the HLD: data formats, timing, error propagation and transactions. Typical defects found here are mismatched assumptions between teams, such as units, null handling or retry behaviour.

System testing

System testing evaluates the complete, integrated system against the system requirements. It covers functional behaviour and non-functional qualities: performance, security, reliability, usability and, in embedded work, behaviour on target hardware or in a hardware-in-the-loop rig. An independent QA team usually runs it in an environment as close to production as possible.

Acceptance testing (UAT)

Acceptance testing confirms that the system meets the business requirements and is ready for real use. Customers or end users run the acceptance test plan written at the very start of the project, often as user acceptance testing (UAT), plus any contractual or regulatory acceptance steps. A pass here closes the V: the requirement captured in phase 1 has been shown to work in phase 9.

How does traceability work in the V model? A worked example

Traceability in the V model means every requirement can be followed down the left side to the code that implements it and up the right side to the tests that prove it, and back again. The tool for this is a requirements traceability matrix (RTM). Automotive SPICE 4.0, released by VDA QMC in November 2023, explicitly requires bidirectional traceability: from requirements to tests and from tests back to requirements, so that no test is orphaned and no requirement is untested.

Here is one requirement traced through the whole V. Take a payments terminal where the business requirement is REQ-017: “Payment approval must lock after three failed PIN attempts.”

1. Business requirement (phase 1). REQ-017 is written and signed off. Its acceptance criterion: “After three wrong PINs on a live card, the terminal declines further attempts and shows the lock message.”
2. System requirement (phase 2). SYS-042 specifies the lock must persist across terminal reboot and must be logged to the audit trail within one second.
3. Architecture (phase 3). ARC-09 assigns the counter to the authorisation service and the lock state to the secure storage component, with a defined interface between them.
4. Module design (phase 4). MOD-AUTH-3 defines the counter logic, including reset on successful PIN entry and boundary behaviour at exactly three attempts.
5. Code (phase 5). The PinAttemptCounter module implements MOD-AUTH-3.
6. Tests (phases 6 to 9). UT-311 checks the counter at 2, 3 and 4 attempts; IT-58 checks the lock reaches secure storage; ST-120 reboots the terminal mid-lock; AT-17 runs the customer scenario with a real card.

The resulting slice of the RTM looks like this:

Two things make the RTM useful rather than bureaucratic. First, a failed row tells you immediately which requirement is at risk and which design element to check: REQ-020 failed at system level, so the fix starts at SYS-050, not with a random code search. Second, a change request becomes an impact analysis. If the business changes REQ-017 to “lock after five attempts”, the matrix lists every design item and test that must change on both sides of the V.

Core principles of the V model

The V model rests on a small set of principles that separate it from a plain sequential process. They all come down to one idea: think about how you will test something at the moment you decide what it should be.

• Test planning in parallel with development. Each left-side phase delivers its matching test plan, so testing starts on day one, not after coding.
• Defect prevention over defect detection. Writing tests against a specification exposes ambiguity and gaps before they become code. Costs rise sharply the later a defect is found, so prevention pays.
• Clear, testable requirements. A requirement without an acceptance criterion is not finished. The V forces that discipline.
• Phase gates and formal sign-off. Each phase ends with a review and approval before the next one starts, which creates natural audit points.
• Static testing on the left, dynamic testing on the right. Reviews, inspections and static analysis verify documents and code; execution-based tests validate behaviour.
• One-to-one mapping between phases and tests. Every development level has exactly one test level that checks it, at the same level of abstraction.

Advantages and disadvantages of the V model

The V model trades flexibility for control. It produces excellent evidence and early test design, and it struggles when requirements move. Both lists below are worth reading before you pick it.

Advantages

• Early test design. Test plans exist before code, so testers find specification defects while they are still cheap to fix.
• Audit-ready evidence. Specifications, review records, test plans, results and the RTM are natural by-products, which is exactly what assessors ask for.
• Clear deliverables per phase. Everyone knows what each phase must produce and who approves it.
• Predictable gates and milestones. Progress is easy to report and to tie to payments or certification steps.
• Fewer late surprises. Defects found at each test level point back to a specific design phase, which shortens root-cause analysis.
• Good fit for fixed scope and contracts. Fixed-price and regulated contracts map naturally onto the V’s baselined phases.

Disadvantages

• Rigid when requirements change. A change at the top of the V ripples through design, code and four levels of test plans.
• Working software arrives late. Stakeholders do not see a running system until coding and early testing are done.
• Costly rework. A requirement error found in acceptance testing means revisiting every phase below it.
• Heavy documentation load. Specs, plans and matrices take real effort to write and keep current.
• Weak customer feedback loop. Users validate the product only at the end, unless the team adds prototypes or demos.
• Poor fit for discovery-stage products. If you do not yet know what to build, the V will freeze the wrong answer.

V model vs waterfall vs agile: what is the difference?

The V model differs from waterfall by pairing every design phase with its own test level and planning those tests early. It differs from agile by being sequential and specification-driven rather than iterative. The W-model is a further refinement of the V that adds a parallel test activity to every phase. The comparison below summarises the trade-offs.

In practice, the V and the waterfall model are close relatives: both are plan-driven, both use phase gates, and both suit stable requirements. The V’s advantage is structured, early testing and built-in traceability. Agile software development is the opposite philosophy, optimising for learning and change. The choice is usually not V or agile but how much of each, which the hybrid section below covers.

When is the V model for software development the right choice?

The V model for software development is the right choice when requirements are stable, failures are expensive or dangerous, and someone outside the team will demand proof of testing. If most of the checks below apply to your project, the V, or a hybrid built on it, is a strong fit:

• Requirements are well understood and unlikely to change much during the build.
• The system is safety-critical or mission-critical: a failure could injure people, stop operations or cause large financial loss.
• A regulator, notified body or certification authority will audit your development and test evidence.
• Software is co-developed with hardware, so interfaces and timing must be specified and tested level by level.
• The contract is fixed-price or fixed-scope, with acceptance tied to agreed criteria.
• Acceptance criteria can be written clearly at the start.
• Several suppliers build parts of the system and need defined integration points.

The V is a poor choice for an early-stage MVP, a consumer app whose features depend on market feedback, or any project whose scope is still unclear. In those cases, iterative delivery finds the right product faster, and you can add V-style traceability later if the product enters a regulated market.

How is the V model used in regulated industries?

Regulated industries use the V model because their standards are themselves structured around paired development and verification activities. Following the V makes compliance evidence a by-product of normal work rather than a separate documentation project at the end.

Automotive: ISO 26262 and Automotive SPICE 4.0

Automotive software is the clearest V-model use case today. ISO 26262 (second edition, 2018) organises functional safety work from concept through system design and implementation to verification and validation, a sequence that maps directly onto the V, as SPEC Innovations describes in its whitepaper on the topic. Automotive SPICE 4.0 defines process areas down the left side, from requirements and design to the software unit, and verification tests up the right side, from unit to system, with bidirectional traceability. Aptiv describes its own automotive V as system requirements, system design, software requirements, implementation, then software and system integration and qualification tests. See our guide to automotive software development for the wider picture.

Medical devices: IEC 62304 and FDA software validation

Medical device software follows IEC 62304 (with Amendment 1 from 2015), which requires software development planning, requirements, architecture, detailed design, unit verification, integration testing and system testing, scaled by software safety class. That list is the V in all but name. In the US, FDA software validation guidance expects documented evidence that the software meets user needs and intended uses, which is what the acceptance level of the V provides. More detail is in our guide to medical device software development.

Aerospace and defence: DO-178C

Airborne software is certified under DO-178C, published in 2011. It requires high-level and low-level requirements, traceability between requirements, code and tests, and structural coverage analysis whose rigour rises with the design assurance level, up to MC/DC coverage for the most critical software. The V’s pairing of module design with unit testing and its RTM give teams a natural way to show that evidence. Our article on aviation software covers the certification context.

Government and public sector: V-Modell XT and systems engineering

Germany’s federal V-Modell XT standard prescribes a tailorable V-shaped process for public-sector IT projects, defining roles, products and decision gates for both the client and the supplier. In the US, the Federal Highway Administration used the V in its systems engineering guidance for intelligent transportation projects, including the 2005 Clarus concept of operations. Public buyers favour the V because it ties each acceptance step to a contractual requirement.

Can the V model work with agile? Hybrid V, W-model and Agile V in 2026

Yes. In 2026 the V model is most often used as a governance and evidence frame around iterative delivery, not as a strict one-pass sequence. Teams keep the V’s levels, test plans and traceability, and run short iterations inside them. Three patterns are common.

Sprints inside the V. Requirements and architecture are baselined at the top of the V for a release or increment. Inside the implementation band, teams work in sprints: each sprint delivers designed, coded and unit- and integration-tested features, with the RTM updated as part of the definition of done. System and acceptance testing run at release level. This is the most common hybrid in automotive and medical programmes today.

The W-model. The W-model adds a test activity in parallel with every development phase: reviewing the requirements while they are written, testing the design while it is drawn, and so on. Drawn out, it looks like two overlapping Vs, which gives the model its name. It pushes shift-left testing further than the classic V.

Agile V with AI agents. A framework published on arXiv in February 2026 by Koch and Wellbrock, called Agile V, embeds independent verification and audit-artifact generation into every agile task cycle, using AI agents per stage with human approval gates. Their feasibility study on a hardware-in-the-loop system of about 500 lines of code, 8 requirements and 54 tests reported a 100% requirement-level pass rate and estimated a 10 to 50 times cost reduction against a COCOMO II baseline. That is a single small case study, not an industry benchmark, but it shows where the V is heading: automated evidence generation inside fast iterations.

Continuous integration pipelines are what make all three patterns workable. When unit and integration tests run on every commit and results are linked to requirement IDs, the right side of the V produces evidence continuously rather than in one late burst. The same idea underpins a secure software development lifecycle, and it is standard practice in embedded software development, where hardware-in-the-loop rigs run nightly.

How to implement the V model: 7 best practices

A V model project succeeds when the paperwork serves the engineering rather than the other way round. These seven practices keep the model useful and lean.

1. Tailor the V to project risk. A safety-critical braking function needs every level and independent review; an internal reporting tool may merge HLD and LLD. Standards like V-Modell XT and IEC 62304 explicitly allow tailoring. Use it.
2. Write test plans at each left-side gate. Do not let a phase close until its paired test plan exists and has been reviewed. This is the heart of the V; skip it and you are running waterfall.
3. Keep a living RTM in your ALM tool. Maintain traceability in an application lifecycle management tool or issue tracker (Jira, Polarion and codeBeamer are common choices) rather than a spreadsheet, so links update with every change.
4. Automate unit and integration tests in CI. Automated tests linked to requirement IDs turn the lower right side of the V into continuous evidence.
5. Run reviews and static analysis on the left. Inspect requirements and designs with checklists, and run static analysis on code before unit testing. This is where the V’s defect-prevention promise is delivered.
6. Apply change control with two-sided impact analysis. Every change request should list the affected design items and the affected tests. The RTM makes that a query, not a guess.
7. Use independent verification for safety-critical levels. For the highest integrity levels, have people who did not write the code or the design perform reviews and tests, as ISO 26262 and DO-178C expect.

These practices overlap heavily with general quality assurance discipline. The V simply gives each QA activity a fixed place and a partner phase.

FAQ

Last updated 2 October 2026. Sources: Wikipedia, V-model (software development); Aptiv, What Is the V-Model in Software Development?; VDA QMC, Automotive SPICE PAM v4.0 (2023); Koch & Wellbrock, Agile V, arXiv 2602.20684 (2026); SPEC Innovations, ISO 26262 and the Systems Engineering V-Model; Built In, What Is the V-Model in Software Development?. Standard references: ISO 26262:2018, IEC 62304 (Amd 1:2015), DO-178C (2011). The RTM example is illustrative.