What requirements traceability is
Requirements traceability is the ability to follow each requirement forward to the design that implements it and the test that proves it, and backward to the need or risk that created it. A traceability matrix is the usual tool: one row per requirement, with links to its source, design output, verification, validation and risk controls.
In regulated product development, traceability is how you prove completeness. Without it, nobody can show that every user need was met, every hazard was controlled and every test has a reason to exist. The same idea runs through aerospace software, automotive functional safety and medical devices; this guide focuses on medical devices, where FDA and notified bodies read traceability closely.
For a ready-to-use traceability matrix template, see Design Traceability Matrix Template for Medical Devices (QMSR and Software).
What regulators expect
| Source | Traceability expectation |
|---|---|
| ISO 13485:2016 clause 7.3 (incorporated into FDA’s QMSR from February 2, 2026) | Design planning must note “traceability methods”; FDA’s QMSR training also shows a “risk traceability matrix” being updated during design review (FDA) |
| FDA software premarket guidance (June 14, 2023) | “Each requirement identified in the software requirements specification should be traceable” (FDA) |
| Same guidance, risk management | Risk is shown by “tracing the identified hazard to the verified specific risk control measures” with test identifiers and pass/fail results |
| Same guidance, verification | Expected analyses include “traceability analyses (e.g., software requirements specification to software design specification (and vice versa)“ |
| IEC 62304 (software lifecycle) | Traceability between hazards, software items, risk controls and their verification (paraphrased; the standard is paywalled) |
| ISO 14971 (risk management) | Each risk control must be implemented and its effectiveness verified, which in practice requires links from hazard to control to test (paraphrased) |
FDA’s software guidance scales the submission by documentation level. “Enhanced Documentation” applies where a software failure “could present a hazardous situation” with “a probable risk of death or serious injury”; in that case FDA also expects the software design specification to show “how the software design traces to the SRS” (FDA). Basic-level submissions still need traceable requirements and hazard-to-test links; the design detail stays in the design file.
The layers a traceability matrix should connect
- User needs and intended use
- Design inputs: system and software requirements, including regulatory and standards requirements
- Risk analysis: hazards, hazardous situations and risk control measures
- Design outputs: specifications, drawings, code modules, labeling
- Verification: test protocols, test cases and results that show outputs meet inputs
- Validation: clinical, human factors or simulated-use evidence that user needs are met
- Changes: design change records that update every affected link
A practical rule: every row should answer “where did this come from?” and “how do we know it works?” A requirement with no test, or a test with no requirement, is a gap.
Example matrix rows
| User need | Requirement | Risk control | Design output | Verification | Validation |
|---|---|---|---|---|---|
| UN-04 Alarm is noticed in a noisy ward | SRS-112 Alarm at ≥65 dB(A) at 1 m | RC-17 for hazard H-09 (missed alarm) | Speaker spec SPK-3, firmware module ALM | TC-112 sound test: pass | Human factors study HF-2, task 6 |
| UN-07 Dose cannot be entered twice | SRS-140 Confirm screen before delivery | RC-21 for H-14 (double dose) | UI spec UI-8 | TC-140 to TC-143: pass | HF-2, task 3 |
Illustrative only; IDs and values are invented.
Common traceability failures
- One-way trace. Requirements link to tests, but tests are not checked back to requirements, so orphan tests and untested requirements both survive.
- Risk file disconnected. Hazards list risk controls that never appear as requirements or tests.
- Stale after changes. A design change updates the code and the test but not the matrix.
- Untestable requirements. “User-friendly” or “robust” cannot be verified; inputs must be “able to be verified or validated” under clause 7.3.3 (FDA).
- Spreadsheet sprawl. Several matrices, each partly current, with no single source of truth.
Where AI fits
Tracing is a text-matching problem at scale, and research is moving quickly. A February 2026 study reported that its LLM-based approach “achieves state-of-the-art F2 scores, outperforming traditional IR baselines,” while noting that performance depends “critically on the quality of prompt engineering” (arXiv, TraceLLM). In practice, AI is most useful for suggesting candidate links, finding requirements with no test and flagging wording that cannot be verified. Engineers still confirm each link, because a wrong trace in a regulated file is worse than a missing one.
Traceability checklist
- Traceability method defined in the design and development plan
- Every user need traces to at least one requirement
- Every requirement traces to a design output and a verification activity
- Every hazard traces to risk controls, and every control to a passed test
- Validation evidence linked to user needs
- No orphan tests or orphan requirements
- Requirements written to be verifiable
- Matrix updated through design change control
- Software traceability matches the FDA documentation level
- One controlled source of truth for the matrix
Find broken links before a reviewer does
AskDona reads requirements specifications, risk files and test reports together, checks them against your traceability procedure, ISO 13485 clause 7.3 or FDA software guidance, flags missing or one-way links and untestable wording, and cites the passage behind every finding.
Run a sample traceability assessment on one subsystem’s requirements and tests. AskDona shows the evidence; your engineers decide.
FAQ
What is requirements traceability? The ability to link each requirement to its source, design, tests and risk controls, forward and backward.
What is a requirements traceability matrix? A table or tool view that shows those links, typically one row per requirement.
Does FDA require a traceability matrix? FDA does not mandate a specific format, but its software guidance expects each requirement to be “traceable” and hazards to trace to verified risk controls (FDA).
What is design traceability? Traceability between design inputs and design outputs, required as part of design and development planning under ISO 13485.
Can AI build a traceability matrix? AI can suggest links and flag gaps, but engineers should confirm each link before it enters a controlled record.
References
All pages opened and checked by October 14, 2026.
| Source | Type | Date | Used for |
|---|---|---|---|
| FDA: QMSR Design and Development (slides) | Regulator training | 2026 | Clause 7.3, traceability methods |
| FDA: Content of Premarket Submissions for Device Software Functions | Regulator guidance | Jun 14, 2023 | Software traceability, documentation levels |
| arXiv: TraceLLM | Research preprint | Feb 1, 2026 | AI trace link recovery |