V-Model
Concept
Topic overview
Quick facts
The V-Model arranges the lifecycle as a V: down the left side, stakeholder and safety requirements are decomposed into system design, architecture, and detailed module design; across the bottom, implementation happens; and up the right side, the work is reassembled and checked, unit tests against module design, integration tests against architecture, system verification against system requirements, and validation against the original intent and hazard analysis.
The defining feature is the horizontal correspondence: every left-side artifact has a right-side counterpart that proves it, and the test cases for each right-side stage are written from the left-side artifact at the same level, ideally at the time that artifact is written, not reverse-engineered from the code later.
Safety standards are built on this shape. structures its software requirements around a V lifecycle, presents railway software development explicitly as a V with mandated documents at each stage, and organizes its product development parts as nested Vs at the system, hardware, and software levels.
The standards do not mandate a literal waterfall schedule: iterative and agile execution is acceptable, and increasingly common, provided each increment still produces the paired specification and verification evidence the V demands.
What is not negotiable is the traceability spine: requirements trace down through design to implementation and across to the tests that verify them.
Model-based systems engineering (MBSE) is the modern complement rather than a replacement: executable models make left-side artifacts precise enough to simulate, which pulls verification earlier (finding integration errors at design time), and enables techniques such as back-to-back testing between model and generated code.
Regulators and assessors expect V-Model framing because it makes an audit tractable: they can pick any safety requirement and walk it down to design and across to test evidence, and any gap in that walk is a finding.
Why V-Model matters to your program
For a product leader the V-Model is the map on which safety schedule and cost are negotiated: assessors, notified bodies, and customer safety teams all navigate your program by it, so evidence organized any other way must be translated before it can be reviewed, at your expense.
It also explains a fact of safety economics that surprises teams from the commercial software world: the right side of the V is roughly half the program, and it cannot start in earnest until the left side stabilizes, which is why late requirements churn is so much more expensive in safety-rated development.
Working with V-Model
V-model stages (left to right)
The functional safety plan maps the chosen standard's lifecycle phases onto the project's actual milestones, naming the work products of each left-side stage and the verification activities and coverage criteria of each right-side stage, along with who performs them and with what independence.
Teams working iteratively keep the V per increment: each sprint or release slice updates the affected specifications, re-runs the paired verification, and maintains the traceability links, usually in a requirements management tool.
Assessors walk the V in samples: pick a hazard, follow it to a safety requirement, down through architecture to implementation, and across to the test that verified it at each level, checking the artifact dates show specification preceded test design and that the verified configuration matches the release.
Common V-Model mistakes
Standards related to V-Model
V-Model is defined and governed by IEC 61508 - the umbrella functional safety standard defining the safety lifecycle, sil levels, and requirements for electrical, electronic, and programmable systems.
ISO 26262 sets the requirements that V-Model work has to satisfy: automotive functional safety standard defining asil levels and the automotive safety lifecycle.
EN 50128 sets the requirements that V-Model work has to satisfy: software for railway control and protection systems, defining software sil requirements and lifecycle.
Left-right pairings
| Specification (left) | Verification (right) |
|---|---|
| User / system requirements | System validation |
| System architecture | System integration tests |
| Software/hardware design | Integration tests |
| Module design | Unit tests |
V-Model by industry
In rail & transit, V-Model comes up in nearly every certification conversation: freight and passenger rail signaling, train control, and transit systems.
Industrial Machinery programs lean on V-Model because the sector covers fixed and mobile machinery, packaging lines, and manufacturing equipment.
Ask our team about V-Model
Ben TwomblyFounder & CEOLeads CSA's functional-safety, certification, and engineering programs for safety-critical products and organizations. His assessor-side background informs practical programs that connect standards, engineering work, and credible evidence.
Jeff Twombly, PEExecutive, Rail SafetyProvides executive and technical leadership for rail-safety programs, assessments, and complex transit-system work. His experience spans safety assurance, transportation-safety leadership, signaling, and independent review.
Tom CyrPrincipal Safety Engineer, IFSPSupports industrial and rail functional-safety programs with safety analysis, requirements, lifecycle planning, and certification-readiness guidance.V-Model: related terms
How each connects to V-Model:
Programs that deal with V-Model almost always involve Verification and Validation in the same phase.
Functional Safety Plan appears in the same lifecycle work as V-Model and is usually produced or reviewed alongside it.
Functional Safety Requirements appears in the same lifecycle work as V-Model and is usually produced or reviewed alongside it.
Both V-Model and Functional Safety sit under IEC 61508, so evidence for one usually references the other.
IEC 61508 connects the two: V-Model and SIL are assessed against the same lifecycle.
IEC 61508 connects the two: V-Model and Safety Function are assessed against the same lifecycle.
Both V-Model and Safe Torque Off sit under IEC 61508, so evidence for one usually references the other.
Both V-Model and FMEA sit under IEC 61508, so evidence for one usually references the other.
IEC 61508 connects the two: V-Model and FMEDA are assessed against the same lifecycle.