What the V-Model Is — and Why GAMP 5 Uses It
The V-model is the conceptual framework that underlies every GAMP 5 validation project. It maps every design document on the left-hand side of the V to a corresponding test activity on the right-hand side. The model makes a simple but powerful statement: for every decision you make during design, there must be a corresponding test that verifies the decision was implemented correctly.
Understanding the V-model is the fastest way to understand why validation projects are structured the way they are — why you need both an FDS and an OQ, why the URS drives the PQ, and why gaps in the test evidence always trace back to gaps in the design documentation.
The Left Side — Design and Specification
The left arm of the V represents the progression from high-level requirements down to the detailed design. Each level adds specificity and must be approved before the next level begins.
- URS — what the system must achieve, technology-neutral, approved by the user and QA
- FDS/HDS — how the system achieves it, technology-specific, written by the engineer. The URS vs FDS difference is critical to get right
- FAT — factory test verifying the FDS was implemented correctly before the system leaves the supplier
The Right Side — Qualification and Testing
The right arm represents the qualification activities at site. Each one tests a corresponding left-side document:
- IQ — verifies the system was installed correctly as per the HDS. Checks hardware, versions, calibration, network config
- OQ — verifies the system operates correctly as per the FDS. Tests every functional requirement with documented evidence
- PQ — verifies the system performs correctly under real operating conditions as per the URS. Tests process outcomes, not just system functions
See the IQ OQ PQ guide for a detailed breakdown of what each protocol must contain.
How Traceability Connects the Two Arms
The horizontal dashed lines in the V-model diagram represent traceability — the documented link between a design decision and the test that verifies it. This is what the traceability matrix captures: every URS requirement traces through FDS sections to OQ test cases to PQ runs.
A gap on either side of the V creates a traceability problem. A URS requirement with no OQ test case means something was required but never tested. An OQ test case with no URS requirement means something was tested that was never formally required — it's gold-plating that adds no regulatory value.
Common V-Model Mistakes on First Pharma Projects
- Skipping the FAT — treating it as optional or "just a demo." The FAT is the gate between design and site qualification. Without it, defects that should be caught at the factory arrive at site during IQ/OQ, causing expensive delays
- Writing the URS after the FDS — engineering-driven projects often design first, then reverse-engineer requirements to match. This produces untestable requirements and a traceability matrix that can never close
- Treating IQ and OQ as one activity — IQ checks what was installed. OQ checks how it operates. Running them as one document confuses installation verification with functional testing and creates scope gaps
- No VSR — the Validation Summary Report closes the V and declares the system validated. Without it, there's no formal documented conclusion, and a QA reviewer has no single point of reference for validation status
Every document in the framework maps to a specific position on the V-model. The Validation Plan defines which V-model activities apply to your project and their sequence. The Traceability Matrix maintains the horizontal links between left-side and right-side documents throughout execution.