The Traceability Matrix:
How to Link Requirements
to Test Cases

What the Traceability Matrix Actually Does

The traceability matrix (TM) is a living document that maps every user requirement to the design specification that addresses it, and from there to the test case that verifies it was met. It answers one question in both directions: has every requirement been tested, and does every test case justify its existence?

Without a traceability matrix, you can produce a complete set of IQ, OQ, and PQ protocols and still arrive at a QA review with gaps — requirements that were never tested, or test cases that don't trace back to any stated requirement. The TM is the mechanism that prevents both.

The Structure of a GAMP 5 Traceability Matrix

In its simplest form, the traceability matrix is a spreadsheet with one row per requirement. Across the columns, each row traces that requirement through the full V-Model chain:

What Each Column Should Contain

The exact columns vary by project and client, but a robust traceability matrix for a Cat 4 PLC/SCADA project typically includes:

• URS Reference — the unique ID of the requirement (e.g. URS-F-001)
• Requirement text — the full requirement as written in the URS
• Priority / Risk — Critical / Major / Minor, drives test depth
• FDS Reference — which section of the FDS addresses this requirement
• FAT Reference — which FAT test case(s) test this requirement at the factory
• IQ Reference — which IQ check(s) verify the hardware/software for this requirement
• OQ Reference — which OQ test case(s) verify operation
• PQ Reference — which PQ run(s) verify performance under real conditions
• Status — Open / In progress / Closed, updated as protocols are executed

What Gaps Look Like — and What They Cost

There are two types of gap, and both are findings in a QA review:

Untested requirement — a URS requirement with no corresponding test case in any protocol. The regulator's question is: how do you know this requirement was met? Without a test case, the answer is "we don't." For 21 CFR Part 11 requirements, this is a critical finding — one that can result in a warning letter.

Untraceable test case — a test case in your OQ with no corresponding URS requirement. This is less severe but still a finding — it means your testing scope was defined by what was convenient to test, not by what the client actually required.

In our experience, a project without a maintained traceability matrix will typically have 3–8 untested requirements when reviewed. Each one becomes a deviation to resolve — at the worst possible time, immediately before go-live.

Building One That Actually Works in Practice

The practical steps for building a traceability matrix that holds up under scrutiny:

• Number every URS requirement at authoring time — not as an afterthought (our URS guide covers the correct ID format)
• Classify each requirement as Functional, Safety, Performance, or Regulatory — this drives which protocol phases it needs
• Assign a risk level (Critical/Major/Minor) — higher risk requirements need more test depth
• Populate the FDS reference before starting the IQ/OQ protocols
• Write OQ test case IDs into the TM as you write each test case — not at the end
• Filter for blank cells before submitting for QA review — any blank in the OQ column is a gap