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: §820.30(c) Design input.
Requirement text
For each software system of the medical device, the manufacturer must define and document software system requirements from the system level requirements and, as appropriate to the medical device software, must include in the software requirements: functional and capability requirements; software system inputs and outputs; interfaces between the software system and other systems; software-driven alarms, warnings, and operator messages; security requirements; user interface requirements implemented by software; data definition and database requirements; installation and acceptance requirements of the delivered medical device software at the operation and maintenance site or sites; requirements related to methods of operation and maintenance; requirements related to IT-network aspects; user maintenance requirements; and regulatory requirements. For software safety classes B and C, the manufacturer must include risk control measures implemented in software in the requirements as appropriate to the medical device software.
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) introduced a new compliance path for legacy software (Clause 4.4), allowing previously released software to meet requirements through post-market data and risk management rather than full retrospective documentation.
In Clause 4.3, Amendment 1 struck the 2006 sentence "The software safety classes shall initially be assigned based on severity as follows" and its three severity-based class definitions, and inserted class definitions that depend on whether the software system can contribute to a hazardous situation which results in unacceptable risk after consideration of risk control measures external to the software system, with the resulting possible harm being non-serious injury (Class B) or death or serious injury (Class C). Figure 3 states that the probability of a software failure shall be assumed to be 1 and that only risk control measures not implemented within (external to) the software system shall be considered. The 2006 text already allowed a hardware risk control measure to reduce the class (from C to B, and from B to A); Amendment 1 inserted a NOTE 1 stating that external risk control measures can be hardware, an independent software system, health care procedures, or other means. Amendment 1 also inserted a NOTE to clause 5.3.5 (Identify segregation necessary for risk control) that ends: "Other means of segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3)."
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 identification and avoidance of common software defects (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.