Requirements management is the process of capturing, analyzing, documenting, organizing, and tracking product requirements throughout the device development lifecycle. A Requirements Traceability Matrix (RTM) is the tool that links requirements across levels—from user needs through regulatory requirements to design specifications, test cases, and risk controls. Weak requirements management is a root cause of design flaws, test gaps, compliance failures, and field problems. This article explains why requirements management matters, how to build a compliant RTM, and when spreadsheets must give way to dedicated tools.

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.

Effective requirements management ensures that design decisions are intentional and justified, that verification activities are focused on what matters, that nothing falls through the cracks, and that the organization can demonstrate to regulators that every design element serves a defined purpose. This is not bureaucracy—it is the foundation of good design.

Why Requirements Management Is 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.

The Four Levels of Requirements in Medical Device Development

User Needs (Stakeholder Requirements)

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.

System Requirements (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—each requirement must have a clear acceptance criterion. A requirement like '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 testable. ISO 13485 calls these 'design inputs' and requires they be approved before design begins. IEC 62304 calls them 'software safety requirements' and 'software user requirements.' FDA 21 CFR 820.30(c) requires 'design input' documentation.

Software Requirements (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 (medical device software lifecycle) requires that software requirements be documented, traced to system requirements, and verified through testing and code review. Software requirements are lower-level than system requirements but must still be clear and testable. Many organizations struggle with the distinction between system requirements (what the device must do) and software requirements (how the software implements it).

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.

Regulatory requirements should be explicitly captured and traced to design elements and verification activities. Many organizations maintain a 'regulatory requirements' row in their RTM to show that applicable standards are addressed in the design. This is particularly important for pre-submission regulatory meetings—showing explicit traceability to regulatory expectations demonstrates compliance planning.

What Is a Requirements Traceability Matrix (RTM)?

What the RTM Tracks

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.

RTM Format and Structure

A simple RTM might be a spreadsheet with columns: Requirement ID | User Need | System Requirement | Design Input | Design Output (Specification) | Verification Method | Verification Evidence | Regulatory Standard | Risk Control | Owner. More sophisticated RTMs include additional columns for priority, status, owner, 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.

Building 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.

Requirements Management Under IEC 62304 and ISO 13485

IEC 62304 (Medical device software lifecycle) Section 5 requires that software requirements be: documented in a Software Requirements Specification (SRS), testable and unambiguous, traceable to system requirements and software design, and organized hierarchically. The standard distinguishes between Software Safety Requirements (addressing safety concerns), Software User Requirements (addressing intended use and user interactions), and Software System Requirements (addressing system-level functionality).

ISO 13485 Section 7.3.3 requires that design input requirements be: documented, reviewed, and approved before design output development begins, complete and unambiguous, not in conflict with other requirements, and include criteria for acceptance. (Note: Section 7.3.2 covers design and development planning; design inputs are specifically addressed in Section 7.3.3.) The standard also requires that requirements be retained and reviewed for adequacy as design progresses. This ‘feeding forward’ of requirements through design review is a key ISO 13485 concept—requirements are not static but are reconsidered at each design gate.

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.

FDA 21 CFR Part 820.30 requires similar elements: design inputs must be documented and approved, design outputs must address design inputs, design review must verify that outputs meet inputs, design verification must confirm requirements are met, and design change controls must manage modifications. The FDA interprets the RTM as evidence of this traceability.

Common Requirements Management Failures

• Ambiguous or untestable requirements: 'The device shall be fast,' 'The device shall be user-friendly'—these 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.

Spreadsheets vs. ALM Tools: When to Make the Switch

Many organizations start with a spreadsheet-based RTM. This works for simple, small projects: a single Excel file with rows for requirements and columns for design mapping, verification, and status. As the project grows, spreadsheets become unwieldy: (1) Version control becomes difficult when multiple people edit the same spreadsheet; (2) Cross-linking breaks when rows are inserted or deleted; (3) Searching and filtering large matrices becomes tedious; (4) Impact analysis (if this requirement changes, what else is affected?) is manual and error-prone; (5) Audit trails are lost—changes are made without recording who changed what or why.

Application Lifecycle Management (ALM) tools (such as JIRA, Polarion, Matrix Req, or Requisite Pro) excel where spreadsheets fail: (1) Automatic impact analysis—change a requirement and the system shows all affected design elements, tests, and risks; (2) Bidirectional traceability—links are maintained automatically when elements are moved or renamed; (3) Workflow management—requirements move through approval workflows with documented sign-offs; (4) Search and reporting—complex queries are easy, and reports can be generated for audits or submissions; (5) Integration with other tools—test cases are linked directly to requirements, design tools feed in specifications, risk management systems link to mitigation controls.

The right time to switch to an ALM tool is when the RTM becomes difficult to manage in a spreadsheet—typically when there are more than a few hundred requirements, multiple subsystems or software modules, or frequent changes. For organizations developing multiple devices or managing large, complex products (e.g., software-intensive devices with hundreds of user-facing features), an ALM tool is essential.

💡 Matrix Req's unified requirements management automatically captures user needs, system requirements, software requirements, and regulatory requirements in a searchable, bidirectional traceability matrix. Automatic impact analysis shows what design elements, tests, and risk controls are affected by each requirement. Integration with design systems, test management, and risk management ensures end-to-end visibility. Compliance checking validates that all requirements are traced, verified, and addressed in design.

Requirements management is the linchpin of medical device compliance and quality. It transforms vague user needs into precise, verifiable specifications. It ensures that nothing falls through the cracks between concept and design. It enables rigorous verification that the device meets its intended use. And it creates the documented record that satisfies regulators during audits and inspections. Organizations that invest in disciplined, systematic requirements management—captured in clear specifications and maintained through a traceable RTM—build devices that are safer, easier to verify, and more defensible against regulatory challenge.