How do I build a traceability matrix for IEC 62304?
IEC 62304 §5.1.1 (e) · §5.7.5 · §5.8.8
The short answer
A traceability matrix links requirements to architecture, to software items, and to verification tests. It is mandatory for Class B (requirements ↔ tests) and Class C (full four-way: requirements ↔ architecture ↔ software items ↔ tests). It ensures every requirement is tested and every test covers a requirement. Gaps in either direction are nonconformities.
What traceability connects
- System Requirements — top-level device requirements (from risk management and intended purpose)
- Software Requirements (SRS) — derived software requirements; each must trace to a system requirement
- Software Architecture — architecture elements/items that implement each requirement
- Software Items / Units — specific code modules or components that implement each architecture element
- Verification Tests — unit tests, integration tests, system tests that verify each requirement
- Risk Controls (ISO 14971) — risk controls implemented as software requirements must trace to their test evidence
Minimum requirements by class
| Class | Required traceability | What it means |
|---|---|---|
| Class A | Not required | No formal traceability matrix required |
| Class B | Requirements ↔ Tests | Each SRS requirement must link to at least one test case; each test must link to at least one requirement |
| Class C | Requirements ↔ Architecture ↔ Software Items ↔ Tests | Full four-way traceability; architecture and unit links added to Class B requirements |
For Class B and C: any requirement without a corresponding test is a nonconformity. Any test without a corresponding requirement is a nonconformity. Bidirectional traceability is required.
Practical tools
- Excel/spreadsheet: Most common; columns for Req ID, Req text, Architecture ref, Unit ref, Test Case ID, Test result, Status. Works well for smaller systems.
- Jira with custom fields: Requirement tickets linked to test execution tickets; traceability via issue links. Requires discipline in populating links consistently.
- Dedicated ALM tools: Polarion, Jama Connect, Codebeamer, Helix ALM — designed for IEC 62304/DO-178C traceability; expensive but highly auditable output.
- GitHub issues with labels: Possible for smaller teams; requirement IDs in issue titles, linked to test IDs via PR references. Requires a consistent naming convention.
Common traceability errors
- Test-only traceability: Tests reference requirements but requirements do not reference tests — unidirectional, not bidirectional
- Requirements without tests: SRS requirements with no corresponding test case (common when requirements are added late)
- Stale matrix: Traceability matrix created at the start and never updated after requirements or tests change — no longer reflects the actual system
- Risk controls not linked: Risk controls identified in the risk management file are implemented as software requirements, but those requirements do not appear in the traceability matrix
- Architecture references missing: Class C matrix has requirements linked to tests but no architecture or unit reference columns
Frequently asked questions
How granular must requirements be for effective traceability?
Requirements must be specific enough to be individually testable. A requirement like "the system shall be safe" cannot be traced to a test. A requirement like "the system shall alarm within 5 seconds when a glucose reading exceeds 400 mg/dL" can be. Use verifiable, testable requirement statements.
Does SOUP need entries in the traceability matrix?
SOUP itself does not need to appear as requirements in the traceability matrix. However, requirements that the SOUP must satisfy (Class C) should be in the SRS and traced to tests that verify the SOUP meets those requirements in your device context.
Do automated test case IDs count in the traceability matrix?
Yes — automated test IDs (e.g. test function names, test case IDs in JUnit/pytest output) can be used as the Test Case ID in the traceability matrix, provided the test output is captured and archived. The key is that the link between requirement and test evidence can be demonstrated.
How often must the traceability matrix be updated?
The traceability matrix must be updated whenever requirements are added, changed, or removed, and whenever tests are added, changed, or removed. In an Agile process, this typically means updating after each sprint that introduces requirement or test changes. Stale traceability at the time of an audit is a finding.