V-model development: a matching verification for every stage
Going down the left side you break down requirements and design; going up the right side you verify with the test that pairs with each stage.
Requirements analysis ──────────────── System verification / acceptance test
System design ─────────────────── System integration test
SW architecture design ────── SW integration test
SW detailed design ───── Unit test
└── Implementation ──┘
Core principles
- Traceability: every requirement has to lead to design elements and test cases. You must be able to answer "why does this code exist?" and "how was this requirement verified?".
- Design the test in advance at the paired stage: when writing a requirement, decide together how it will be tested. A requirement that cannot be tested ("responds quickly") is turned into a number ("within 100 ms").
Example work products
| Stage | Work product |
|---|---|
| Requirements | Requirements specification (with IDs) |
| System design | HSI (hardware-software interface) |
| SW architecture | Module structure, interfaces, task design |
| Detailed design | Function-level behaviour, state machines |
| Test | Test specifications and result reports |
It works on small projects too
Even for a balancing robot, leaving documents in the order "ten requirements → HSI table → module structure → unit tests → integration test" lets a portfolio show not "what I built" but "how I developed it". ASPICE, in the automotive industry, is the model for assessing this process.