Maps to
QMSR / ISO 13485: §820.30(c)
ISO 13485: §7.3.3
IEC 62304: §5.2
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.
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.