V-Model
The V-model is a development model for systems and software engineering: the left branch refines requirements step by step down to implementation, the right branch verifies each level against its specification. Each development level thus faces its own test level — this distinguishes the V-model from the simple waterfall, in which testing only appears as one phase at the end.
Structure: left and right branch
The core idea of the V is the assignment of specification and verification at each level. A typical form for embedded systems:
| Left branch (specification) | Right branch (verification) |
|---|---|
| Stakeholder and system requirements | Validation / system test |
| System architecture | System integration test |
| Software requirements | Software test |
| Software architecture | Software integration test |
| Detailed design and implementation | Unit/module test |
The tip of the V is the implementation. The horizontal relationship is decisive: the system integration test is planned against the system architecture, the unit test against the detailed design — each test level answers the question of whether the corresponding specification level has been implemented correctly. Test cases can thus already be created while the respective level is being specified, not only after implementation.
Role in ISO 26262 and Automotive SPICE
Safety standards and process quality models presuppose the V structure as a frame of reference. ISO 26262 organises product development along the V — at system level as well as in dedicated branches for hardware and software development, each with specification phases on the left and integration and verification phases on the right. Automotive SPICE likewise arranges its engineering processes (system and software engineering from requirements analysis to system test) in a V representation and demands bidirectional traceability between the corresponding levels as a base practice. Anyone working in these contexts cannot avoid the V-model as an organising framework — regardless of how iteratively the actual development proceeds.
V-model does not mean waterfall
A widespread misconception reads the V as a rigid, single pass. The V, however, describes a logical structure, not a calendar: it defines which verification belongs to which specification — not that all requirements must be final before the first line of code is written. In practice, the V is run through per iteration, release or change; especially with short cycles and over-the-air updates, this results in a sequence of small Vs. To be distinguished from this is the V-Modell XT, a concrete process standard for public-sector projects in Germany.
The V-model in practice: the V is only as good as its cross-links
The real value of the V-model lies in the horizontal relationships — and that is exactly where it fails most often in practice. Requirements live in the requirements management tool, architecture models in the MBSE tool, code and unit tests in the repository, system tests in test management: tool boundaries run between the left and right branch. Without end-to-end trace links from the requirement to the corresponding test case, the V remains a diagram — coverage can then only be demonstrated through manual reconstruction. Only with maintained traceability between the branches can an impact analysis show which test cases are affected by each change, and the proof of coverage becomes possible at the push of a button instead of weeks of audit preparation.