systems engineering//V-model

2026-01-21

The V-model is a development lifecycle drawn as a V, in which a system is specified and decomposed down the left side (requirements, architecture, detailed design, implementation) and built back up the right side, where each level is verified against its mirror on the left: unit tests against the design, integration tests against the architecture, system tests against the requirements, and acceptance against the user's need. It is used in automotive, aerospace, rail and industrial safety work, where standards demand evidence that every requirement was implemented and tested, and it gives a project manager a map of which test answers which document.

What sews the two sides together is traceability: every requirement knows which design element and which code implement it and which test verifies it, and every line of code traces back to a requirement. In a drone's flight software the requirement hold horizontal position within 0.5 m in 8 m/s wind traces down to an estimator latency budget, a controller bandwidth and specific modules, and up to a simulation scenario, a hardware-in-the-loop run and a flight test that each check part of it.

The V pays for itself in where errors are found. A requirement error caught on the left costs an edit; the same error caught at system test costs a redesign, and in the field a recall. Each level of the right side exists to catch what the level below it cannot see: a unit test cannot find an interface misunderstanding, an integration test cannot find a wrong requirement.

On the right side the verification climbs the X-in-the-loop testing pyramid: model, software and processor in the loop near the bottom, hardware-in-the-loop at integration, bench and field at the top. Simulation lets much of the right side start before hardware exists, so the V is in practice run many times in small loops.

The V is the lifecycle that functional safety standards assume. DO-178C demands requirement-to-code-to-test traceability and structural coverage; IEC 61508 wraps a safety lifecycle of the same shape around the hazard analysis.

Its weakness is that it assumes behaviour can be specified, decomposed and traced. A learned component breaks that assumption: no requirement says what neuron 3,412 implements, which is why learned parts are usually certified indirectly, inside an architecture where a simple verified monitor guards them (Simplex architecture).

Read as a strict sequence, the V is slow and fragile to changing requirements; agile teams in regulated industries keep its traceability and its levels of verification while iterating, which is what auditors actually check.

The V is the skeleton of systems engineering; its inputs are requirements and its right side is verification.