IEC 62304

The foundational step where software is assigned a safety class (A, B, or C) based on the risk of death or serious injury. Class A: No harm. Class C: Death or serious injury possible. This classification directly dictates the rigor of documentation and verification required. For example, a Class C diagnostic algorithm requires exhaustive unit verification and detailed architectural design, while a Class A scheduling tool requires minimal documentation.

Establishes the Software Development Plan (SDP), which defines the processes, deliverables, and tools for the entire lifecycle. This plan must reference or integrate with the Quality Management System (QMS) and ISO 14971 risk management. Key outputs include development standards, tool qualification plans, and configuration management strategies.

The systematic process of defining and documenting both functional and non-functional software requirements. Each requirement must be unambiguous, testable, and traceable to system-level risk controls. This phase produces the Software Requirements Specification (SRS) and establishes bidirectional traceability to system hazards identified in the risk management file.

Transforms requirements into a structured Software Architectural Design that decomposes the system into software units and interfaces. For higher safety classes, a Detailed Design is required for each unit, specifying algorithms and data structures. This phase ensures segregation of safety-critical components from non-critical ones to prevent fault propagation.

The coding and static/dynamic verification of individual software units against their detailed design. Verification strategies include code reviews, static analysis, and unit testing. For Class C software, additional verification methods like abstract interpretation or formal proof may be required to ensure no undefined behavior exists in safety-critical execution paths.

A progressive process of combining software units and verifying their interactions before testing the complete system against the SRS. This phase requires documented test plans, cases, and procedures. Anomalies are managed through a formal Software Problem Resolution Process, which includes change control board review and impact analysis on existing risk assessments.

Finalizes the software version, archives the Design History File (DHF), and ensures the release package is reproducible. Post-market, the Software Maintenance Plan governs changes. Every modification, even a minor patch, triggers a re-evaluation of the safety classification and requires regression testing to ensure no new hazards were introduced into the fielded device.

IEC 62304 is inseparable from ISO 14971. Software risk controls are identified as software requirements and traced through design, implementation, and verification. The standard mandates that software contributing to hazardous situations must be identified, and the effectiveness of software-based risk control measures must be verified with the same rigor as the risk controls themselves.