Build your traceability matrix
Enter your project information, edit the example requirements or add your own, and generate a matrix. Example requirements are illustrative and should be reviewed against your intended use, risk assessment, quality system, and applicable regulations.
This tool runs in your browser. The information entered is not uploaded by this page.
1. Requirements register
Use one row for each uniquely identified requirement. A requirement should be specific, testable, and traceable to an approved source.
| # | Requirement ID | Requirement statement | Source | Risk | Design output / control | Verification method | Test / protocol ID | Evidence reference | Owner | Status | Action |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||||
| 2 | |||||||||||
| 3 | |||||||||||
| 4 | |||||||||||
| 5 |
2. Requirements Traceability Matrix
Interpretation: this tool checks whether key fields are populated and whether rows are marked verified. It does not independently validate a system, approve a requirement, or determine regulatory compliance.
Traceability coverage
| Requirement ID | Requirement | Source | Risk | Design output / control | Verification method | Test / protocol ID | Evidence reference | Owner | Status | Traceability review |
|---|
Items requiring attention
Recommended review actions
Before controlled use, review this output, resolve gaps, confirm test evidence, and manage the approved record under your organization's document-control process.
What is an eDHR requirements traceability matrix?
A requirements traceability matrix (RTM) is a structured record that links each requirement to its source, implementation or design output, and verification evidence. For an electronic Device History Record (eDHR) project, it helps teams demonstrate how requirements have been addressed throughout configuration, testing, and release.
What should an eDHR traceability matrix contain?
- Unique requirement ID: a stable identifier that can be referenced in reviews and tests.
- Requirement source: such as an approved user requirement, process specification, risk control, or applicable procedure.
- Risk classification: a designation consistent with the project's approved risk-management approach.
- Design output or control: the configuration, workflow, permission, interface, or other solution addressing the requirement.
- Verification method and test ID: how the requirement will be tested or otherwise verified and where the protocol is documented.
- Objective evidence: the executed test result, review record, or other controlled evidence supporting the conclusion.
- Owner and status: the responsible role and the current progress of implementation or verification.
How to use this generator
- Replace the illustrative examples with approved project requirements.
- Use unique IDs and check that each requirement has a clear source.
- Link requirements to relevant design outputs, controls, and verification activities.
- Record actual protocol identifiers and evidence references when available.
- Generate the matrix, review the highlighted gaps, and assign actions to responsible owners.
- Export the result and handle it through your document-control and approval procedures.
How does traceability support eDHR validation?
Traceability can help connect intended use and user needs to system configuration, risk controls, and verification activities. The appropriate scope and rigor depend on the system's intended use, product and process risks, applicable requirements, and the manufacturer's quality system. The matrix itself is a planning and documentation aid, not proof of validation or compliance.