What the standard controls
The lifecycle covers planning, requirements, architecture, detailed design and implementation, verification, integration, system testing, release, maintenance, risk-related software activities, configuration management and problem resolution.
- Plan the lifecycle and its deliverables.
- Establish traceability between software requirements, implementation and tests.
- Control configuration, anomalies and changes.
- Maintain the software after release using the same disciplined evidence chain.
Safety classification changes rigour
Software safety classification is based on the possible injury resulting from a hazardous situation to which software can contribute, considering external risk-control measures. Higher classification increases the required lifecycle activities and evidence.
- Class A: no injury or damage to health is possible.
- Class B: non-serious injury is possible.
- Class C: death or serious injury is possible.
IEC 62304 is not the whole product lifecycle
The standard does not independently establish intended use, clinical validity, usability, system architecture, cybersecurity or complete product validation. These must connect through the wider quality and design-control system.
Key takeaways
- Software classification must be supported by product risk analysis.
- Lifecycle evidence should remain proportionate but connected.
- Software compliance cannot compensate for weak system requirements or validation.
This article provides general educational information. Applicable requirements depend on the device, jurisdiction, lifecycle stage and current regulatory position.