Traceability MatrixRequirements Traceability Matrix

The Requirements Traceability Matrix is the bookkeeping that turns a pile of documents (URS, FS, DS, configuration records, test scripts, test results) into a single auditable chain. Each row starts with a URS requirement ID and walks left-to-right through: the Functional Specification element that delivers it, the Design Specification element that builds it, the test case that exercises it, the executed test result (with run date, tester, outcome and any deviation), and — for medical devices — the risk-control measure the requirement implements. Read down a column you can answer 'are all requirements tested?'; read across a row you can answer 'why does this feature exist?'

1. Requirement ID (URS-001, URS-002 …) — stable, immutable, never re-used.
2. Requirement text — verbatim from the approved URS.
3. Criticality (GxP / Business / Informational) — drives test rigour under CSA.
4. Risk link — for device software: the ISO 14971 risk-control measure ID this requirement implements (or 'none').
5. Functional Spec section — where the function is described.
6. Design Spec section — where the build is specified (config item, code module, recipe step).
7. Build evidence — config-baseline ID, code-review record, recipe-version pinned at release.
8. Test case ID(s) — the IQ / OQ / PQ / UAT script(s) that exercise this requirement.
9. Test result — pass / fail / partial; protocol-run date; tester e-signature.
10. Deviation IDs — any test deviations and their disposition.
11. Status — Open / Built / Tested / Released / Withdrawn.

An RTM is bidirectional or it is not an RTM. Forward trace (left-to-right) confirms every URS line is built and tested — a missing test cell is a coverage gap. Reverse trace (right-to-left, sometimes called the 'orphan check') confirms every shipped feature, every test case, every line of GxP-relevant code maps back to an approved requirement. Orphans are the dangerous side: undocumented features mean the validation envelope does not match the released system, which is the second-most common Annex 11 / Part 11 finding behind audit-trail gaps.

FDA's 2022 Computer Software Assurance (CSA) draft guidance reframed CSV away from 'document everything' towards critical-thinking and risk-based test rigour. CSA explicitly endorses unscripted / ad-hoc / exploratory testing for low-risk requirements and scripted, signed protocols for high-risk requirements. What CSA did NOT remove is traceability itself — every requirement still needs evidence it was implemented and verified, the difference is the type of evidence is now proportionate to risk. The RTM is the place that proportionality is documented; the criticality column drives the test-rigour decision.

• Change control feeds the RTM — every approved change adds / amends / withdraws requirements with the change-control ID linked.
• Periodic review reads from the RTM — the periodic review is the orphan and coverage check at a point in time.
• Re-qualification is scoped from the RTM — the OQ / PQ subset to re-run after a configuration change is the set of test cases linked to the impacted requirements.
• Audit prep is the RTM with a date filter — 'show me everything that changed since the last inspection' is one query, not three weeks of forensic archaeology.

For medical-device software the RTM gains an extra dimension: every risk-control measure from the ISO 14971 risk file must trace to a software requirement, which traces to design, which traces to a verified test result, which feeds back into the residual-risk evaluation. IEC 62304 §5.1 and §7 require this loop explicitly; missing it is a top notified-body finding. The same RTM that satisfies GAMP 5 / Annex 11 for a manufacturing system is the spine of the IEC 62304 software safety classification for an SaMD product.

1. RTM built once, never updated — a change-control closed the spec but no-one walked back to the matrix.
2. Coverage cells point to test-case IDs but the test cases were never executed (or executed and failed, with no deviation traceable).
3. Reverse trace skipped — features in production with no requirement behind them.
4. Requirements written so vaguely ('the system shall be user-friendly') that no test case can verify them — RTM compliant, but the underlying URS is unprovable.
5. Criticality column blank, so all rows treated the same way — defeats the CSA risk-based logic.
6. RTM held in a spreadsheet outside the validated environment, so the matrix itself fails Part 11.

• URS, FS, DS, configuration baselines, test scripts and executed test results live in linked records — the RTM is generated, not authored.
• Every change-control adds, amends or withdraws requirement rows; the matrix and the change record are always in agreement.
• Criticality drives the validation template — high-risk requirements force a signed scripted protocol; low-risk requirements allow a CSA-style unscripted evidence record.
• Coverage and orphan reports run on demand — pre-inspection prep is one click, not a fortnight of reconciliation.
• For device-software customers, ISO 14971 risk controls link directly to URS rows, giving the IEC 62304 trace as a by-product of the same matrix.
• Periodic review uses the RTM as its agenda — open requirements, failed tests, orphan features and overdue re-qualifications are surfaced automatically.