Requirements Traceability Matrix (RTM) is a structured document that links each product requirement to its source, design output, verification test, and validation result. In medical device development, an RTM shows regulators and internal teams that every user need and design input has been addressed, tested, and closed out before release.
What is a Requirements Traceability Matrix (RTM)?
A Requirements Traceability Matrix (RTM) is a table, usually built as a spreadsheet or a module inside an application lifecycle management (ALM) tool, that maps relationships between requirements and the artifacts that satisfy them. Each row typically represents one requirement; the columns capture its source, the design output that addresses it, how it was verified or validated, and its current status.
Inside a medical device Design History File (DHF), the RTM acts as the connective layer, tying user needs to design inputs, design inputs to design outputs, and design outputs to verification and validation records. Without it, a design team has documents that exist independently, with no evidence that the pieces actually cover each other.
Why Requirements Traceability Matrix (RTM) matters in medical device development
Patient safety depends on every functional and safety requirement actually being tested, not just documented. An RTM surfaces the gaps: a requirement with no linked test case, or a test case that traces back to nothing. Missing that link in a spreadsheet is a minor annoyance; missing it in a device that reaches a patient is a field action waiting to happen.
Regulators treat traceability as a proxy for design control maturity. FDA reviewers and notified body auditors routinely ask for a traceability matrix during a 510(k) review, a technical file audit, or a design control inspection. A weak or incomplete RTM is a common finding in FDA Form 483 observations and ISO 13485 audit nonconformities, since it exposes exactly where design control discipline broke down.
Cost matters too. An untraced requirement is cheap to fix at design review, costs a retest cycle if caught during verification, and can mean a design change or a recall if caught after launch.
How a Requirements Traceability Matrix (RTM) works
An RTM is built incrementally as the design controls process runs, not assembled at the end as a paperwork exercise. The typical structure links:
- User needs: the clinical or functional needs the device must meet.
- Design inputs: the translated, testable requirements derived from those needs.
- Design outputs: drawings, specifications, source code, and other artifacts that implement the inputs.
- Verification records: objective evidence that a design output meets its design input, per FDA 21 CFR Part 820.30(f).
- Validation records: evidence that the finished device meets user needs and intended use, per 21 CFR Part 820.30(g).
- Risk controls: linkage to the risk management file under ISO 14971, since many requirements originate as risk mitigations.
Good traceability runs both directions. Forward traceability confirms every user need reaches a verified, validated output. Backward traceability confirms every test case maps back to an actual requirement, so nobody is testing something that was never asked for. Software-driven devices also reference IEC 62304 software items and test records at the unit, integration, and system levels. Under EU MDR 2017/745, the same matrix supports the general safety and performance requirements checklist.
Common challenges and best practices
The most common failure mode is a spreadsheet that goes stale. Requirements change during development, but nobody updates the matrix, so it stops reflecting the actual design. By the time an auditor asks for it, the RTM describes an earlier version of the product.
A second problem is one-directional traceability: teams trace forward from requirements to tests but never check backward. That gap lets scope creep and untraceable “nice-to-have” features slip into the build unnoticed. Orphaned requirements follow the same pattern: a design input with no linked verification activity, usually because a test was deferred and never revisited. A row-by-row scan before a design review or audit catches most of these first.
Best practice treats the RTM as a living record owned by the design team, updated at every design review gate rather than reconstructed before submission. Many teams now maintain it in dedicated ALM or requirements management software rather than a spreadsheet, since automated linking reduces the chance of a broken reference after an edit. Whatever the tool, review it against current design documents at each phase gate, not just once at project close.
How SJML helps with Requirements Traceability Matrix (RTM)
SJML builds traceability into its design control process from early feasibility work, not as a document produced after the fact. Engineering teams maintain requirements traceability across user needs, design inputs, design outputs, and verification and validation activity as part of phase-gate program management, with change control that keeps the matrix current as designs evolve. Risk management under ISO 14971 and usability engineering under IEC 62366 link into the same structure, keeping risk controls and use-related requirements tied to their evidence. This runs across SJML’s electromechanical design and design transfer work, helping teams reach a design review or audit with a matrix that reflects the current device.
Talk to SJML’s engineering team →
Frequently asked questions
A Design History File (DHF) is the complete compilation of records describing a device’s design history, including design plans, inputs, outputs, and reviews. The RTM is one document inside that file: the index linking every requirement to its supporting evidence elsewhere in the DHF.
Neither FDA 21 CFR Part 820.30 nor ISO 13485 names “RTM” explicitly, but both require demonstrable links between design inputs, outputs, verification, and validation. An RTM is the standard way manufacturers meet that requirement and present it to auditors.
At minimum: user needs, design inputs, design outputs, verification test references, validation test references, and status. Many teams also add risk control linkage under ISO 14971 and, for software-containing devices, IEC 62304 software item references.
Ownership typically sits with the design or systems engineering lead, though quality and regulatory affairs review it at each design review. In practice, it is shared: engineering populates it, QA/RA audits it.
A spreadsheet works for small, stable projects, but it is prone to becoming outdated as requirements change. Larger or more complex programs generally benefit from ALM or requirements management software that auto-links changes and flags orphaned requirements.
Related terms
- Design History File (DHF)
- Design Verification
- Design Validation
- Design Controls
- Risk Management File (ISO 14971)
