In short
The V-model is a software development process model that sets a matching test phase against each design phase. On the left of the "V", the system is specified ever more finely, from the requirements down to the individual components; on the right, it is checked level by level against exactly these specifications.
In Germany it is known above all as the V-Modell XT, the development standard for IT projects of the federal government.
The V-model extends the idea of the waterfall model with a clear thought: tests are not planned only at the end but together with the specification against which they will later check. It is particularly suitable for projects with stable, fixed requirements, for example in regulated industries or for public-sector clients. For most custom software projects in mid-sized companies, it is more a frame of reference than a schedule.
The phases of the V-model
The phases on the left-hand side describe what is to be built. At the bottom of the V is the implementation. The phases on the right-hand side check the result, in each case against the phase opposite it on the left-hand side.
| Specification (left branch) | Result | Check (right branch) | Checks against |
|---|---|---|---|
| Requirements definition | Business requirements from the client's point of view | Acceptance test | Does the system meet the client's needs? |
| System specification (functional system design) | What the overall system must achieve, including interfaces | System test | Does the overall system meet its specification? |
| System architecture (technical system design) | Breakdown into subsystems and components | Integration test | Do the components work together as designed? |
| Component design (module specification) | Behaviour of each individual component | Component test (unit test) | Does each component do what its design requires? |
| Implementation (tip of the V): the components are programmed. | |||
The names vary depending on the source and version, but the structure remains the same. The requirements analysis supplies the content of the top left field, and the technical system design essentially corresponds to the software architecture.
Verification and validation
The V-model separates two questions coined by the software researcher Barry Boehm. Verification asks: are we building the product right, i.e. in accordance with the specification? This is done by the component, integration and system tests. Validation asks: are we building the right product, i.e. one that meets the actual need? This is done above all by the acceptance test with the client. Boehm was already using the V representation at the end of the 1970s.
The V-Modell XT
In Germany, the V-model was developed from the 1980s on behalf of the federal government as the standard for IT projects of the Bundeswehr and the federal administration. The V-Modell 97 was followed in 2005 by the V-Modell XT. "XT" stands for "extreme tailoring": the model is adapted to the specific project instead of being worked through in full. Today it is maintained on behalf of the federal government, and the documents are freely available.
- Process modules: modules made up of roles, activities and products (work results) that are combined depending on the project type.
- Decision gates: fixed quality gates at which the continuation of the project is decided.
- Project execution strategies: these define the order of the decision gates. The XT explicitly also allows incremental and agile strategies.
- Client and contractor: the XT describes both sides. The client draws up the requirements as a requirements specification (Lastenheft), and the contractor responds with the overall system specification, the functional specification (Pflichtenheft).
Example: the V-model for an interface to the ERP
A manufacturer has software built that passes production orders from the ERP to the machine control system and writes feedback back. The requirements are fixed because the machines and ERP are given. The V-model structures the project like this:
- Requirements definition: "Every released production order appears at the responsible machine; every completion confirmation is assigned to the order in the ERP." The acceptance test is already defined at this point: a real order in test operation, from the ERP to the feedback.
- System specification: data formats, error cases (machine offline, order cancelled) and logging are described. The system test checks each of these cases.
- Architecture: one service reads orders from the ERP, a second talks to the machines, and a queue decouples the two. The integration test checks the interplay, even if one part fails.
- Component design and implementation: each component is secured against its design with unit tests.
The advantage shows at acceptance: because the acceptance test has been fixed since the first phase, it is clear when the project is finished. The disadvantage shows when a requirement changes in the middle of the project. Then all affected levels on the left and right have to be adjusted.
The waterfall model: the predecessor
The waterfall model arranges the phases strictly one after the other: requirements, design, implementation, test, operation. Each phase only begins when the previous one has been completed, like water falling from step to step. Its origin is considered to be a 1970 paper by Winston W. Royce. In it, Royce described the sequential order but himself warned against applying it without feedback and recommended iterations. The term "waterfall" only came up later.
The V-model adopts the sequence of the waterfall but adds the fixed assignment of specification and test. In the pure waterfall, the test is a single block at the end; in the V-model, it is defined for each design level how it is checked.
Process models compared
Process models define the order in which the activities of a software project take place and what results are produced. The most important at a glance:
| Model | Process | Handling of changes | Fits well when |
|---|---|---|---|
| Waterfall model | Phases strictly one after the other | Expensive, because completed phases have to be reopened | Small projects with fully known requirements |
| V-model / V-Modell XT | Sequential, each design level with its own test level | Formally across all affected levels | Regulated environments, public-sector clients, high documentation requirements |
| Spiral model | Repeated cycles, each beginning with a risk analysis | Planned in, cycle by cycle | Large projects with high technical risks |
| Iterative-incremental | The system grows in expansion stages, each going through all activities | Easily possible between stages | Medium-sized projects in which a subsystem should be usable early |
| Agile (Scrum, Kanban) | Short cycles with a working result, ongoing prioritisation | At any time via the backlog | New products, uncertain requirements, close collaboration possible |
The spiral model also comes from Barry Boehm. In practice, the boundaries between the models are fluid: many teams work in an agile way and retain from the V-model the assignment of requirement and test, for example via acceptance criteria and automated tests at several levels. You can find more about the agile approach in the entry on agile software development.
FAQ on the V-model
What is the V-model in simple terms?
The V-model is a process model in which each planning level, from the requirements to the individual component, gets its own test level. On the left of the V you plan, at the bottom you program, and on the right you check, in each case against the planning opposite.
What is the difference between the waterfall model and the V-model?
Both work through phases one after the other. The waterfall model has a test block at the end, while the V-model assigns its own test phase to each design phase: acceptance test, system test, integration test and component test. This way, it is already defined during design how the result will be checked.
What does XT mean in V-Modell XT?
XT stands for "extreme tailoring". The V-Modell XT is adapted to the respective project: depending on the project type, only the appropriate process modules are used. Since 2005, it has been the development standard for IT projects of the German federal government.
Is the V-model agile?
The classic V-model is not agile because it works through the phases sequentially. The V-Modell XT, however, allows incremental and agile project execution strategies. In practice, many teams combine agile delivery with the basic idea of the V-model of linking each requirement with a matching test.
What process models are there in software development?
The best known are the waterfall model, the V-model, the spiral model, iterative-incremental models and agile approaches such as Scrum and Kanban. They differ above all in when requirements are defined and how the project deals with changes.
Are you facing a tender or do you need a reliable specification? We support you with your requirements specification and then accompany the project with requirements analysis and project management, classic, agile or as a hybrid.