This is a ready-to-use requirements traceability matrix (RTM) for an IEC 62304 software project. It carries a requirement all the way from the software requirements specification through the architecture, the detailed design, the code, and the test that verifies it, and it carries every software-implemented risk control the same distance from the hazard that created it to the verification that closes it. Build it as you write requirements, not after the fact; retrofitting trace links across a finished codebase is slow and error-prone. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. Confirm each cited regulation against the current source before you rely on it.
Document control header
| Field | Entry |
|---|---|
| Matrix title | IEC 62304 Requirements Traceability Matrix |
| Document number | <<FILL: MTX-ID, e.g. MTX-SW-005>> |
| Software system / product | <<FILL: SYSTEM NAME, e.g. companion dosing application>> |
| Release / version | <<FILL: version>> |
| Owner | <<FILL: role, e.g. Software Lead>> |
1. Purpose
This matrix demonstrates that every software requirement for <<FILL: SYSTEM NAME>> traces to the architecture item that implements it, the design that specifies it (for Class C items), the test that verifies it, and, where applicable, the hazard and risk control it exists to satisfy. It is the single document a reviewer or Notified Body auditor uses to walk the chain in either direction: from a requirement forward to proof it was tested, or from a hazard backward to proof its control was actually implemented and verified.
2. Scope
This matrix covers every requirement in the software requirements specification for the release identified above, across all safety classes. Detailed-design references are required for Class C items only; leave that field marked not applicable for Class A and B items unless your organization elects to design them in equal depth.
3. How to use this matrix
- Start it when you write requirements, not after coding. Assign each requirement an ID as it is written and add its row immediately.
- Every software-implemented risk control gets its own row, with the hazard or threat ID it addresses filled in. A risk control that exists only in the code and not as a row here was never formally verified.
- Update the architecture, design, and test columns as those artifacts are produced, not in a single retrofit pass before release. A matrix built retroactively is the version most likely to contain silent gaps.
- Keep it living across the maintenance process. A change to a requirement, a design, or a test updates this matrix in the same change-control action, not as a follow-up task.
- Review it at release against the acceptance criteria in section 6 before the software is released, as part of the release record described in the parent article’s lifecycle section.
4. Column definitions
| Column | Contents | Required |
|---|---|---|
| Req ID | Unique requirement identifier | Yes |
| Requirement (brief) | Short, testable statement of the requirement | Yes |
| Safety class | A / B / C, the class of the item that implements this requirement | Yes |
| Risk control? | Yes/No; if Yes, the hazard or threat ID from the ISO 14971 risk file or the security risk assessment | Yes |
| Architecture item | The architecture item ID that implements this requirement | Yes |
| Detailed design ref | Design document reference | Required for Class C; note “N/A, Class A/B” otherwise |
| SOUP dependency | SOUP component ID if a third-party component is load-bearing for this requirement | If applicable |
| Test ID(s) | Every test that verifies this requirement | Yes |
| Result | Pass / Fail / Not yet executed | Yes |
| Verified by, date | Name and date of the verifying reviewer, independent of the author for Class C | Yes |
5. The matrix template
| Req ID | Requirement (brief) | Safety class | Risk control? (Hazard/Threat ID) | Architecture item | Detailed design ref | SOUP dependency | Test ID(s) | Result | Verified by / date |
|---|---|---|---|---|---|---|---|---|---|
<<FILL: SRS-001>> | <<FILL>> | <<FILL: A/B/C>> | <<FILL: Yes, HAZ-ID / No>> | <<FILL>> | <<FILL, or N/A>> | <<FILL, or N/A>> | <<FILL>> | <<FILL>> | <<FILL>> |
<<FILL: SRS-002>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> | <<FILL>> |
6. Acceptance criteria
- Every requirement in the software requirements specification has a row; every row’s requirement exists in the specification. Neither side has an orphan.
- Every row marked as a risk control cites a real hazard or threat ID that exists in the ISO 14971 risk file or the security risk assessment, and the reverse holds, every software-implemented risk control in those files has a corresponding row here.
- Every Class C row has a detailed design reference; no row is blank where the column is required.
- Every row has at least one test ID with a recorded result; no requirement ships untested or with an unresolved result.
- The matrix as issued matches the architecture and design documents current at release; a mismatch is treated as a release blocker until resolved.
7. References
IEC 62304, Medical device software, Software life cycle processes (current edition). ISO 14971, Medical devices, Application of risk management to medical devices (current edition). FDA guidance, Content of Premarket Submissions for Device Software Functions (final, June 2023), for the documentation-level expectations this matrix supports.
Confirm the current edition of each standard before issue.
Filled specimen
The following extends the worked example from the companion article: a dosing engine (Class C), an alarm function (Class C), a trend display (Class B, segregated), and one security-relevant requirement tied to the wireless dosing-confirmation link.
| Req ID | Requirement (brief) | Safety class | Risk control? | Architecture item | Detailed design ref | SOUP dependency | Test ID(s) | Result | Verified by / date |
|---|---|---|---|---|---|---|---|---|---|
| SRS-014 | Reject commanded dose exceeding configured maximum, alert user | C | Yes (HAZ-03, overdose) | ITEM-DOSE | DD-DOSE-7 | SOUP-014 (numerical library) | ST-031, ST-032 | Pass | R. Okafor, 2026-08-22 |
| SRS-021 | Display sensor signal-loss alarm within 30 seconds | C | Yes (HAZ-07, silent failure) | ITEM-ALARM | DD-ALARM-2 | N/A | ST-040 | Pass | R. Okafor, 2026-08-22 |
| SRS-055 | Compute 14-day glucose trend | B | No | ITEM-TREND | N/A, Class B | SOUP-014 (numerical library) | UT-110, IT-022 | Pass | M. Chen, 2026-08-19 |
| SRS-071 | Verify message authentication code on dosing-confirmation message before acting on it; reject and alert on failure | C | Yes (T-04, message-tampering threat, linked to HAZ-03) | ITEM-COMMS | DD-COMMS-3 | N/A | ST-088 | Pass | R. Okafor, 2026-08-23 |
| SRS-090 | Settings module stores and displays the configured maximum dose value | A | No | ITEM-SET | N/A, Class A | N/A | UT-201 | Pass | M. Chen, 2026-08-18 |
Notice SRS-071: a security requirement traces exactly like a safety requirement, with its own threat ID and its own verification, and it is explicitly cross-referenced to the hazard it also protects (HAZ-03). That is what keeps the security risk assessment and the ISO 14971 file from silently drifting apart.
Common inspection findings this matrix prevents
- A risk control that exists in the code but was never written as a requirement, so it was never captured in a matrix row and never formally verified.
- A requirement with no test ID, or a test result left blank or marked “not yet executed” at release.
- A Class C item with no detailed design reference, or a design reference that points to a document that was never actually written.
- A security-relevant requirement tracked only in a separate cybersecurity document with no link back to the safety risk file, so a reviewer working from the ISO 14971 file alone never finds it.
- A matrix that was visibly built in one retroactive pass right before an audit, evidenced by identical verification dates across unrelated requirements.
How to adapt this matrix
- Set your document number and link it to your software requirements specification and risk management file in the header.
- If your organization uses a requirements management tool that generates traceability automatically, use this template as the specification for what the generated report must contain, then attach the export as the actual matrix.
- For a large system, split the matrix by architecture item or subsystem, but keep one master index that shows every requirement is accounted for somewhere.
- Extend the SOUP dependency column’s linkage to your SOUP inventory log so a component update’s downstream requirement impact is traceable in both directions.
- Keep this matrix under the same change-control discipline as the requirements, design, and test artifacts it references, so it never becomes stale relative to the documents it is supposed to summarize.