Agile vs the V-Model: Where Requirements Live in Each
The most common misunderstanding in requirements engineering is that Agile means "no requirements". It does not. It means requirements live in a different place and are discovered on a different schedule.
The V-model puts them up front, written down before construction. Agile spreads them through the project as a rolling conversation. Neither is "more correct" — they are answers to different constraints, and most real projects blend them.
The V-model: requirements up front
The V-model is named for its shape: on the left, you descend from high-level requirements through design to code; on the right, you ascend through testing back up to acceptance. Each requirement on the left has a matching verification on the right, and the whole thing is traced.
Requirements are written, reviewed, and frozen before construction begins — the Lastenheft. This is the model of choice when the cost of getting it wrong is high and the requirements are knowable: regulated systems, safety-critical hardware, fixed-scope contracts.
Agile: requirements as a rolling conversation
Agile assumes requirements are not fully knowable up front, so it does not pretend to write them all down. Requirements live in the backlog as user stories, each with acceptance criteria, and are refined just in time for each sprint.
The spec is not a document — it is the continuously maintained set of stories and their criteria. Traceability still exists, but it runs from story to code to test within each increment rather than through one monolithic document.
When each wins
- V-model: regulated or safety-critical work, hardware that cannot be re-released cheaply, fixed-price contracts, or anything where "discover it later" is unacceptable.
- Agile: evolving products, uncertain or changing requirements, software that can ship and iterate, or a market that rewards speed over exhaustiveness.
The false choice
The practical answer for most systems is a blend, and it usually follows the stability of the artifact. What is stable — the architecture, the interfaces, the safety constraints — is specified up front, V-model style. What changes — the features, the user flows — is handled as a rolling backlog, Agile style.
A device that must be certified and integrated uses an up-front specification for its interface contracts and safety requirements, while the application around it evolves in sprints. The two are not in conflict; they operate at different levels of the same system.
The part that never changes
Whatever the model, three things are non-negotiable: requirements must be written and agreed, traceable to what satisfies them, and changed only through a controlled process. The V-model does this in one document; Agile does it in a backlog. The discipline is identical.