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.
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.
Atomic constraints
- •Software requirements must be derived from and traceable to system requirements.
- •Software requirements must include functional, performance, and interface requirements.
- •Risk control measures implemented in software must appear as explicit software requirements.
- •Requirements must be verified (reviewed for correctness and completeness) before implementation.
- •Software requirements must be updated when system requirements or risk analysis changes.
- •Requirements must be uniquely identified to support traceability.
- •Software requirements must include functional and capability requirements addressing performance, physical characteristics, and computing environment.
- •Software requirements must include software system inputs and outputs.
- •Software requirements must include interfaces between the software system and other systems.
- •Software requirements must include software-driven alarms, warnings, and operator messages.
- •Software requirements must include security requirements addressing authentication, authorization, audit trail, communication integrity, and system security/malware protection.
- •Software requirements must include user interface requirements implemented by software.
- •Software requirements must include installation and acceptance requirements at the operation and maintenance site.
- •Software requirements must include regulatory requirements applicable to the software.
- •The manufacturer must re-evaluate the medical device risk analysis when software requirements are established and update it as appropriate.
- •Software requirements verification must confirm that requirements implement system requirements including those relating to risk control, do not contradict one another, are expressed unambiguously, permit establishment of test criteria, can be uniquely identified, and are traceable to system requirements or other source.
Common gaps
Requirements lacking unique identifiers and traceability
majorRequirements 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
moderateSoftware 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.
Evidence signals
- •
FILE_EXISTS
Software.*Requirements|SRS|SRL|Requirements.*List|System.*Requirements
- •
CONTENT_MATCH
Does this document list software requirements with unique identifiers, including requirements derived from risk control measures, and are requirements traceable to system-level requirements?
Audit defense
The Software Requirements List for [your product] (Doc ID: [your document ID]) contains uniquely identified requirements traceable to system requirements and risk control measures. Requirements were verified using our Checklist Software Requirements before implementation began, per IEC 62304 section 5.2.6.