V-Model — major processes & flow maps

Left side descends (decomposition); right side ascends (integration and verification). Dotted arrows show traceability pairing.

Guide · Updated · Source

1. V-Model structure (classic)

Classic V-Model structure

How left-side decomposition pairs with right-side integration and verification across levels.

  1. StartEntry point for applying the classic V lifecycle discipline.
  2. Core steps (see walkthrough below)Descend through specification levels; ascend through matching verification levels.
  3. OutcomeIntegrated system validated with traceability across every V-level.

Left side descends (decomposition); right side ascends (integration and verification). Dotted arrows show traceability pairing.

2. Traceability flow

Requirement-to-evidence traceability

How requirements link to tests and recorded results as the V-Model core deliverable.

  1. StartA stakeholder need or requirement enters the traceability chain.
  2. Core steps (see walkthrough below)Map each requirement to tests and capture results as reviewable evidence.
  3. OutcomeA complete requirement-to-evidence chain with no traceability gaps.

3. Test-level gate decision

V-level test gate checks

How entry and exit gates at each V-level govern test readiness and recorded results.

  1. StartA verification activity at a given V-level begins.
  2. Core steps (see walkthrough below)Pass entry readiness, execute tests, then evaluate exit results.
  3. OutcomeLevel exit with documented results or bounded rework at the source level.

4. Change impact (V-Model perspective)

V-Model change ripple analysis

How a requirement change propagates across design, implementation, and tests at multiple levels.

  1. StartA change request targets a requirement or specification artifact.
  2. Core steps (see walkthrough below)Analyze impact across all affected V-levels before committing rework.
  3. OutcomeBounded rework plan covering every impacted specification and test level.

A change to a requirement potentially impacts design, implementation, and tests at multiple V-levels.

5. Phases A–F (V-Model mapping)

Blueprint phase V-Model locus
A Shape Stakeholder needs; concept of operations
B Plan Requirements analysis + acceptance test planning (paired)
C Build System design → detailed design → implementation (left side descent)
D Verify Unit → integration → system testing (right side ascent)
E Release Acceptance testing; deployment readiness
F Learn Operational validation; field feedback; lessons for next cycle

6. Flow details (walkthrough)

V-Model structure — The V is not just a picture; it encodes a discipline. Each left-side level produces specifications that the corresponding right-side level will verify. Test planning happens during design, not after coding. This early pairing catches specification issues before they become implementation defects.

Traceability — The requirement-to-evidence chain is the V-Model's core deliverable. Every requirement must be testable, every test must trace to a requirement, and every test result must be recorded. Gaps in traceability indicate either missing tests or unnecessary requirements.

Test-level gates — Each V-level has an entry check (test readiness) and exit check (test results). Failures feed back to the corresponding development level for resolution, not to a generic "fix bugs" phase.

Change impact — Changes in the V-Model are expensive because they ripple across levels. Impact analysis must consider all affected V-levels: a requirement change may require design updates, code changes, and retesting at unit, integration, system, and acceptance levels.

7. Authoritative sources & further reading

Full curated list: External reference URLs (methodology guides).