Requirements document with functional, performance, and interface requirements traceable to system-level inputs — foundational SDLC practice.
Risk control measures implemented in software must be explicit requirements; security requirements covering authentication, audit trail, and communication integrity are now mandatory.
Bidirectional traceability matrix — requirement IDs must link to test cases, and risk control requirements must trace back to the risk analysis.
Maps to
IEC 62304: §5.2 Software requirements analysis
ISO 13485: §7.3.3 Design and development inputs
Pre-QMSR Part 820 (legacy QSR): §820.30(c) Design input.
Requirement text
The manufacturer shall define and document software requirements that implement and refine system requirements, including functional, performance, interface, and safety requirements. Risk control measures that are implemented in software must be explicitly captured as software requirements.
Why this clause exists
Risk control measures identified in the ISO 14971 risk analysis do not automatically translate into implemented safeguards — they must pass through the software requirements layer to become verified, traceable artifacts. If the requirement to implement a control (for example, an input-range validation that prevents a hazardous dosage calculation) is never captured in the software requirements list, the implementation cannot be verified as complete, and the risk control cannot be audited as effective. IEC 62304:2006+A1:2015 clause 5.2 mandates the explicit linkage between risk controls and software requirements for this reason: without it, organizations systematically discover at design verification that controls designed on paper are absent from the build, because no requirement existed to include them. The breadth of the clause — requiring functional, performance, interface, security, alarm, and regulatory requirements all in a single document — reflects the regulatory principle that undocumented requirements are the same as absent requirements: if a test-case writer cannot find a requirement for a feature, they cannot write a test for it, and an unverified feature in safety-critical software is an uncontrolled variable that erodes the integrity of the entire verification record.
What changed
Amendment 1 (2015) expanded the scope to explicitly include health software and Software as a Medical Device (SaMD), not just software embedded in physical medical devices. A new compliance path for legacy software (Clause 4.4) was introduced, allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
The software safety classification criteria (Clause 4.3) shifted from severity-only to include probability of hazardous situations. External risk control measures (hardware or clinical procedures) can now reduce the software safety class, but internal software mitigations cannot. The standard clarified that logical segregation (not just physical) is acceptable for classification purposes.
The definition of SOUP was narrowed to apply only to software items — a complete medical device software system cannot be claimed as SOUP to bypass lifecycle requirements. New requirements were added for publishing known defects with risk assessments (5.1.12), IT security and networking considerations (5.2.2), and Class A software received additional testing, release, and monitoring requirements.
Common gaps (what we see in audits)
- Requirements lacking unique identifiers and traceability — Requirements exist but are not assigned unique IDs and are not linked to specific test cases. Auditors need to confirm every requirement has a corresponding verification record — a requirements list alone is insufficient. Bidirectional traceability from requirement to test to result is expected.
- Non-testable requirements — Software requirements are written at levels that cannot be objectively verified at the system level. Requirements like 'the system shall be user-friendly' or 'the system shall be reliable' provide no basis for objective verification. Every requirement must be verifiable.