V-model: stages, strengths, and when agile fits better

The V-model is a sequential development lifecycle in which every specification stage on the way down is matched, on the way up, by the test level that verifies it. Drawn as a V, the descending branch defines what will be built and the ascending branch proves it was built correctly. It is a refinement of the waterfall model, not an alternative to it.

The descending branch

Requirements analysis, functional specification, architectural design, detailed design: each level narrows the previous one and produces a document that will serve as the reference for a test level. The discipline of the model lies here — you cannot specify a level without already knowing how it will be verified.

The ascending branch

Unit tests validate the detailed design, integration tests the architecture, system tests the functional specification, and acceptance tests the initial requirements. Each test answers a document written on the opposite side of the V, which is what makes the coverage traceable and auditable.

Strengths and limits

The V-model is strong where requirements are stable and where proof is required: regulated industries, embedded systems, safety-critical or contractual deliveries. Its limit is symmetrical — a change discovered on the ascending branch is expensive, because it invalidates documents produced months earlier. It assumes you can know what you want before you see it.

Choosing between V, waterfall and agile

The real criterion is not fashion but requirement volatility and the cost of a late change. Stable, contractual, certifiable requirements point to a V-model; exploratory products with a user who discovers their need as they use it point to iterative delivery. Most organizations end up running both, sometimes within a single programme — a validation phase in V, a product increment in sprints.

Managing both in the same portfolio

FoxPlan does not force a single method: a project can be planned as a Gantt schedule with phases, milestones and dependencies, or followed on a Kanban board, and both feed the same resource workload, the same budget and the same portfolio reporting. The method stays a project-level choice; the consolidation stays global.