V-Model

The V-Model in CSV, Explained Simply

Updated 2026-11-07

The V-model is the picture most people draw when explaining how a validation fits together. It is simple once it clicks: everything you specify on the way down has a matching test on the way up. This short guide explains it without jargon.

New to the field? Read what Computer System Validation is first.

The shape

Imagine a letter V. Down the left side you write progressively more detailed specifications. Up the right side you run progressively broader tests. The two sides mirror each other, and each test on the right verifies the specification at the same level on the left.

Left side, top to bottom:

  • User Requirements Specification (URS) — what the user needs.
  • Functional Specification (FS) — what the system does to meet those needs.
  • Design / Configuration Specification (DS/CS) — how it is built or configured.

Right side, bottom to top:

  • Installation Qualification (IQ) — verifies the design/configuration was installed correctly.
  • Operational Qualification (OQ) — verifies the functions work as specified.
  • Performance Qualification (PQ) — verifies the system meets the user requirements in real use.

So the pairs are: URS ↔ PQ, FS ↔ OQ, DS/CS ↔ IQ. You always test against what you specified, at the matching level of detail.

Why it matters

The V-model enforces a discipline: nothing gets tested that was not specified, and nothing important gets specified without a test to confirm it. That two-way link is exactly what a traceability matrix records — each requirement tracing down to its specification and up to its test, and back. At an inspection, that matrix is how you show there are no gaps and no orphan tests.

It also explains why PQ is run against user requirements and not against the design: PQ sits opposite the URS, so it confirms the system does what the user actually needed, in the real process — not merely that the code matches the design.

A common misunderstanding

The V-model is a way of showing relationships, not a rule that every project must be a rigid, sequential waterfall. Modern, risk-based and even agile approaches still honour the core idea — specify, then verify at the matching level — while organising the work more flexibly. GAMP 5 supports scaling and adapting the lifecycle; the V’s pairing of specification to test survives the adaptation.

Putting it to use

When you pick up an unfamiliar validation package, the V-model is a map. Find the URS, find the PQ, and check they correspond. Find the FS and the OQ, and check the functions specified are the functions tested. Gaps in those pairings are the first thing worth questioning — and the first thing an inspector tends to probe.

Next