Requirements management and the traceability matrix for medical devices are two halves of one design control job. Short answer: requirements management is how you write, review, approve and change every user need and design input. The requirements traceability matrix (RTM) is the record that proves each input reached a design output, a verification result and, where it controls a hazard, a risk control. Since 2 February 2026 the FDA reads this against ISO 13485:2016 clause 7.3, which the QMSR incorporates by reference. This page covers the four requirement levels, the RTM columns, the clauses and when a spreadsheet stops working. Matrix Req is the tool we build for this job.

A note on interest: we work at Matrix One, the company behind Matrix Req, and our engineers and RA/QA specialists sit in ISO 13485, IEC 62304 and ISO 14971 audits with customers. This guide ranks nothing. Where it mentions our product, read it as our view. The ranking lives in our guide to the best requirements traceability tools for medical devices.

What is requirements management in medical device development?

Requirements management is the discipline of defining what the device must do (functional requirements), how well it must perform (performance requirements), what standards it must meet (regulatory requirements), and how safe it must be (safety requirements). Requirements flow through multiple levels: from user needs and intended use statements, down through system requirements and software requirements, to hardware specifications and manufacturing procedures. Every requirement must be clear, testable, traceable, and verifiable.

Poor requirements management manifests as: ambiguous specifications that different engineers interpret differently; forgotten or misinterpreted requirements that are not addressed in the design; redundant requirements that waste verification effort; conflicting requirements that create design deadlock; and requirements that are stated but never verified, leaving compliance gaps.

Done well, requirements management means every design decision has a recorded reason, verification effort goes where the risk is, and you can show an investigator that each design element serves a defined purpose. That record is the foundation of good design and the evidence for it at the same time.

Why is requirements management the foundation of safe design?

Medical device design is purpose-driven. The design must satisfy intended use, address identified hazards, control safety risks, and meet applicable standards. If requirements are unclear, incomplete, or not properly traced through design and testing, the device may be designed to meet the wrong targets. A software algorithm that meets its specification might still produce wrong answers if the specification itself does not correctly implement the user requirement. A material that passes testing might be incompatible with the actual intended use if that use was never properly captured as a requirement.

Requirements management is the mechanism by which design intent is communicated from concept to implementation. It is the 'contract' between the user or clinician (what do you need?) and the design team (what will we build?). When this contract is clear, complete, and properly traced, design reviews can verify that design outputs meet design inputs. When it is not, design reviews become subjective arguments about what 'should' have been designed.

Additionally, requirements are the basis for verification and validation planning. Every requirement must have a corresponding test, clinical study, or inspection method that confirms the requirement is met. If a requirement is not documented, it cannot be verified, and the organization has no evidence that the device meets its intended use. Regulators examining verification and validation records look for this traceability: Can you show that every major requirement was verified? If not, the organization has a compliance gap.

What are the four levels of requirements in medical device development?

What are user needs?

User needs are high-level statements about what the device must accomplish from the perspective of patients, clinicians, or operators. Examples: 'The infusion pump must deliver medication at precise rates without user error,' 'The diagnostic device must produce accurate results in less than five minutes,' 'The surgical tool must provide haptic feedback to the surgeon.' User needs are typically qualitative and broad. They define the intended use and inform all downstream requirements.

User needs are often captured through interviews with clinicians, review of clinical practice guidelines, analysis of competitor devices, and regulatory precedent. In medical devices, user needs must include consideration of the full user population: novice and expert users, users with varying physical or cognitive abilities, and uses in both ideal and real-world conditions.

What are system requirements, or design inputs?

System requirements translate user needs into functional and performance specifications for the device as a whole. System requirements are more concrete than user needs but not yet design-specific. Examples: 'The infusion pump shall deliver between 0.1 and 500 mL/hour with ±2% accuracy,' 'The diagnostic device shall detect biomarker concentrations from 10 to 1000 ppm,' 'The device shall operate in temperatures from 15°C to 40°C.' System requirements address functionality, performance, safety, reliability, and applicable standards.

System requirements must be testable, so each one needs a clear acceptance criterion. 'The device shall be easy to use' is not testable; 'users shall complete the setup procedure in less than 5 minutes with zero errors on the first attempt' is. ISO 13485:2016 clause 7.3.3 calls these design and development inputs and requires that they are reviewed for adequacy and approved, and that they are complete, unambiguous, able to be verified or validated, and not in conflict with each other.

Under the QMSR that clause is now the FDA requirement as well. The old 21 CFR 820.30(c) design input text no longer exists, so a procedure or RTM header that still cites it points at a withdrawn rule.

What are software requirements under IEC 62304?

For software-driven devices, software requirements translate system requirements into software-specific specifications. Examples: 'The software shall validate pump infusion rate input to ensure it falls within 0.1-500 mL/hour,' 'The software shall sample the sensor at least every 100 milliseconds,' 'The software shall log all user actions with timestamps.' Software requirements address algorithms, data structures, interfaces, timing, error handling, and user interactions.

IEC 62304 clause 5.2, software requirements analysis, requires the manufacturer to define and document software requirements from the system requirements. Clause 5.2.6 then requires verifying them, including that each is traceable to a system requirement or other source and stated so that test criteria can be set. Many teams blur system requirements (what the device must do) and software requirements (how the software delivers it). The RTM is where that line is drawn explicitly.

What are regulatory requirements?

Regulatory requirements are constraints imposed by applicable regulations, standards, and guidelines. Examples: 'The device shall meet IEC 60601-1 electrical safety requirements,' 'The device shall be sterilizable by ethylene oxide without degradation per ISO 11135,' 'The device shall include warning labels per ISO 15223.' Regulatory requirements are mandatory and non-negotiable. They do not directly describe the device's intended use but rather the conditions and standards the device must satisfy.

Capture regulatory requirements explicitly and trace them to design elements and verification activities. Many teams keep a 'regulatory requirements' block in the RTM to show that each applicable standard is addressed. This pays off in pre-submission meetings, where explicit traceability to regulatory expectations shows the agency that compliance was planned rather than retrofitted.

What is a requirements traceability matrix (RTM)?

What does an RTM track?

A Requirements Traceability Matrix is a table that maps requirements across levels of abstraction and through the design lifecycle.

A typical RTM shows: (1) User needs and their mapping to system requirements; (2) System requirements and their implementation in design specifications or software designs; (3) Requirements and their verification (what test or activity confirms the requirement is met?); (4) Requirements and their linkage to risk controls (if this is a safety-critical requirement, what design control mitigates the risk?); (5) Downstream impact of changes (if a requirement changes, what design elements and tests are affected?).

The RTM is a living document that evolves with the design. As new requirements emerge or requirements are clarified, the RTM is updated. As design changes are made, the RTM shows what requirements are affected. As testing uncovers gaps, the RTM captures whether new requirements must be added or whether testing is incomplete.

What columns should an RTM have?

A workable RTM starts with the columns below. Mature RTMs add priority, status, due date and version history.

The RTM should be indexed and searchable. Requirements are typically numbered using a hierarchical system (e.g., REQ-001, REQ-001.1, REQ-001.1.a) that indicates the requirement level and sequence. Each requirement should have a unique identifier so that it can be referenced unambiguously in design documents, test procedures, and risk assessments.

How do you build a requirements traceability matrix, step by step?

• Step 1: Capture User Needs. Conduct interviews with intended users (clinicians, technicians, patients, caregivers), review clinical guidelines, analyze competitor devices, and document the intended use. Document user needs as clear, broad statements of what the device must accomplish. Organize user needs by user type or functional area.

• Step 2: Define System Requirements. For each user need, define one or more system requirements that are testable and measurable. System requirements should address: Functional requirements (what the device does), Performance requirements (how well it performs), Safety requirements (how hazards are mitigated), Usability requirements (how users interact with the device), Reliability requirements (how often it works), and Regulatory requirements (applicable standards).

• Step 3: Map to Design Specifications. As design progresses, identify which design outputs (hardware specifications, software designs, manufacturing procedures) implement each system requirement. A single requirement may be implemented across multiple design elements, or conversely, a single design element may address multiple requirements.

• Step 4: Define Verification Methods. For each requirement, define how it will be verified: testing (bench testing, software testing, clinical testing), inspection (visual review of design drawings), analysis (calculation or simulation), demonstration (showing the device in operation), or review (expert review of design documentation). A requirement that cannot be verified is incomplete.

• Step 5: Link to Risk Controls. For requirements addressing identified hazards or risks, link the requirement to the corresponding risk assessment and design control. This creates bidirectional traceability: risk assessments show which design requirements mitigate identified risks, and requirements show which risks they address.

• Step 6: Maintain and Update. As design changes occur, update the RTM to show what requirements are affected. As verification activities are completed, update the RTM with test results. As post-market feedback emerges, update the RTM to show whether requirements need clarification or whether new requirements must be added.

What changed for the RTM when the FDA QMSR took effect on 2 February 2026?

The Quality Management System Regulation became effective on 2 February 2026. It amends 21 CFR Part 820 by incorporating ISO 13485:2016 by reference, so FDA design control expectations are now read against ISO 13485 clause 7.3 and its subclauses rather than the old 820.30 text.

The inspection method changed on the same day. The FDA stopped using the Quality System Inspection Technique (QSIT) and now inspects under Compliance Program 7382.850; programs 7382.845 and 7383.001 are no longer used. The FDA also states that devices made under an investigational device exemption are not exempt from the design and development requirements in 21 CFR 820.10(c) and ISO 13485 clause 7.

For the RTM the practical job is a remap. Re-head any column or procedure that cites 820.30(c) to (j) with the matching ISO 13485 clause 7.3 subclause, and check that early feasibility and IDE projects carry the same traces as the commercial programme. Our guide to building an RTM that holds up in an FDA audit walks through what an investigator probes.

What do ISO 13485, IEC 62304 and ISO 14971 require of requirements management?

Both standards implicitly require traceability: you must be able to trace from design inputs (requirements) to design outputs (specifications) to verification activities. If a design output does not address any design input, it is unnecessary. If a design input is not addressed by any design output, it is not implemented. If a requirement is not verified, there is no evidence it is met.

ISO 13485 also expects requirements to be revisited as the design matures. Inputs are reviewed for adequacy, and design reviews under clause 7.3.5 check the outputs against them at each gate, so requirements are reconsidered rather than frozen on day one. That is why the RTM has to be a living record.

What are the most common requirements management failures?

• Ambiguous or untestable requirements: 'The device shall be fast,' 'The device shall be user-friendly' are subjective and cannot be verified.

• Missing traceability: Requirements exist but are not linked to design elements or test activities, making it impossible to verify they are addressed.

• Requirements added mid-project: New requirements appear after design review has been completed, requiring rework and delaying release.

• Conflicting requirements: Different requirements state incompatible constraints (e.g., 'device shall be lightweight' vs. 'device shall withstand 500 N force'), creating design deadlock.

• Requirements not verified: Testing is planned but never executed, leaving no evidence that requirements are met.

• RTM as static artifact: The RTM is created early, then abandoned as design evolves. Late-stage design changes are not reflected in the RTM.

• Software requirements skipped: For software-intensive devices, detailed software requirements are not documented; design jumps directly to code, missing traceability and verification.

• Regulatory requirements forgotten: Applicable standards (e.g., electrical safety, biocompatibility, software validation) are not captured as explicit requirements, leading to gaps in compliance.

When should you move an RTM from a spreadsheet to an ALM tool?

Many teams start with a spreadsheet RTM, and for a small project a single Excel file with rows for requirements and columns for design mapping, verification and status works. As the project grows it becomes unwieldy: (1) version control breaks down when several people edit the same file; (2) cross references break when rows are inserted or deleted; (3) filtering large matrices becomes tedious; (4) impact analysis is manual and error prone; (5) the audit trail is lost, because changes are made without recording who changed what or why.

Requirements and ALM tools such as Matrix Req, Jama Connect, Siemens Polarion ALM and PTC Codebeamer fix those five points: (1) impact analysis, so changing a requirement shows every affected design element, test and risk; (2) bidirectional links that survive moves and renames; (3) approval workflows with documented sign-offs; (4) search and reporting for audits and submissions; (5) integrations that link test cases, development tickets and risk management controls to the requirements.

The right time to switch is when the RTM gets hard to keep current: typically a few hundred requirements, several subsystems or software modules, or frequent change. For a portfolio of devices or a software intensive product, a dedicated tool is the practical choice. Our guide to moving requirements out of Excel covers what survives the import.

How does Matrix Req keep the traceability matrix current?

In Matrix Req the standard traces are predefined, and each one can be configured as optional or required, so the trace report flags broken, missing or outdated links before an auditor does. Change one item and impact analysis shows every downstream requirement, risk control and test with warnings. Trace tables and controlled documents are generated from the data, with audit trails and e-signatures.

Native two way integrations with Jira, Azure DevOps, GitHub and GitLab keep implementation tickets linked to the requirements they implement, and Excel columns or Word sections can be mapped to Matrix Req fields so an existing RTM imports with its traceability intact.

Related articles

• Medical Device Traceability: From User Needs to CE Marking

• DHF & DDF Explained: Design History File and Design and Development File

• Medical Device Design Control: A Complete Guide to ISO 13485 & FDA Requirements

For the audit side of the same problem, including the clause map and the five probes an investigator actually runs, see our guide to how to build a requirements traceability matrix that holds up in an FDA audit.

If your requirements are still held in a spreadsheet, our ranking of the best tools for moving requirements out of Excel covers what actually survives the import and what you have to rebuild.

For the tool side, see how RTM software for medical devices compares, and for software teams the best IEC 62304 tools.

Summary: what are requirements management and the traceability matrix for medical devices?

Requirements management is the controlled process for writing, approving and changing user needs and design inputs; the requirements traceability matrix is the proof that each input reached a design output, a verification result and, where relevant, a risk control. Since 2 February 2026 the FDA checks this against ISO 13485:2016 clause 7.3 through the QMSR, so the RTM is now read against the same clauses in the US and the EU. Matrix Req is the tool we build to keep that matrix current as the design changes.

1. Write every design input so it is complete, unambiguous and verifiable, as ISO 13485 clause 7.3.3 requires.

2. Trace each input forward to an output, a verification record and any ISO 14971 risk control, and back to its user need.

3. Remap any 21 CFR 820.30 references to ISO 13485 clause 7.3 now that the QMSR is in force.

To compare the tools that automate this, read our ranking of the best requirements traceability tools for medical devices.

Last updated: 20 October 2026.