Traceability

Requirements Traceability

Purpose

Ensure bidirectional traceability between requirements, hazards/risks, design, code, tests, and anomalies for medical device software.

When to Apply

• All lifecycle phases; especially during changes and release preparation.

Requirements (testable)

1. ID Schema: Use stable IDs for requirements (REQ-###), hazards (HZ-###), risks/controls (RISK-CTRL-###), design (DES-###), tests (TEST-###), and anomalies (ANOM-###). Rationale: unambiguous linkage.
2. Bidirectionality: Maintain trace both forward (REQ->DES->CODE->TEST) and backward (TEST->REQ). Rationale: completeness and impact analysis.
3. Automation: Generate traceability matrices from managed artifacts (reqs tool + code tags + test metadata). Rationale: reduce drift.
4. Change Impact: For each change, update trace links and assess affected items/tests. Rationale: controlled updates.
5. Evidence Storage: Store trace outputs as release artifacts; version them with builds. Rationale: auditability.
6. SDP Traceability [Class A, B, C]: Maintain trace from system requirements to software requirements, system tests, and software risk controls per development plan. Rationale: 5.1.1 c.
7. Software Hazard Chain [Class B, C]: Maintain links: hazardous situation → software item → cause → risk control → control verification. Rationale: 7.3.3.

Recommended Practices

• Keep a traceability.yaml or use ALM exports to CSV/HTML for submissions.
• Include trace tags in code comments and test names.
• Integrate trace checks in CI (e.g., missing links).

Patterns

Traceability entry (YAML):

# REQ-TRC-01
REQ-62304-102:
  design: [DES-PUMP-01]
  code: [pump_stop_on_door_open]
  tests: [TEST-410, TEST-411]
  hazards: [HZ-07]
  risks: [RISK-CTRL-19]

CI check (concept):

Validate: every TEST-* references a REQ-*; fail build on missing link.

Anti-Patterns (risks)

• Trace only in one direction -> risk: missing coverage.
• Manual spreadsheets without automation -> risk: drift and errors.
• Unlabeled code/tests -> risk: broken trace in audits.
• Trace outputs not baselined -> risk: mismatch to released build.

Verification Checklist

• IDs consistent and present across artifacts.
• Forward/backward traces maintained; gaps resolved.
• Trace matrices generated automatically and stored per release.
• Change impact updates traces and triggers required tests.
• CI checks for missing/invalid links in code/tests.
• Software hazard trace chain maintained for Class B/C (7.3.3).

Traceability

• Central traceability.yaml/tool export; code/test tags; release-stored matrices.

References

• IEC 62304:2006+A1:2015, 5.1.1 c, 7.3.3, 5.3.6 (trace analyses).
• REG-IEC62304-SWRM, DOC-SW-REQ.
• ISO 14971:2019 for hazard-to-control linkage.
• FDA/MDR submission expectations for trace matrices.

Changelog

• 1.1.0 (2026-05-21): Added 5.1.1 c and 7.3.3 software hazard trace chain.
• 1.0.0 (2026-01-04): Initial traceability skill with IDs, automation, and CI checks.

Audit History

• 2026-01-04: Audit performed. Verified:
  • IEC 62304 traceability (5.1-5.6) references accurate
  • ISO 14971 hazard-to-control linkage correctly noted
  • FDA/MDR trace matrix expectations appropriate