Which documents are mandatory for Class A, B, and C under IEC 62304?
IEC 62304 §5, §6, §7, §8, §9
The short answer
Document requirements scale from Class A to Class C. Class A has a defined baseline. Class B adds architecture documentation and unit verification. Class C adds per-unit design specifications and full four-way traceability. No document set is optional — each missing document is a finding in any IEC 62304 audit.
Document requirements by class
| Document | Class A | Class B | Class C |
|---|---|---|---|
| Software Development Plan (SDP) | Required | Required | Required |
| Software Requirements Specification (SRS) | Required | Required | Required |
| System / Integration Test Records | Required | Required | Required |
| Software Release Records | Required | Required | Required |
| SOUP Register (with known anomalies) | Required | Required | Required |
| Problem Resolution Records | Required | Required | Required |
| Software Architecture Document | — | Required | Required |
| Unit Verification Records | — | Required | Required |
| Integration Records | — | Required | Required |
| SOUP Anomaly Evaluation Records | — | Required | Required |
| Traceability Matrix (Req ↔ Tests) | — | Required | Required |
| Software Design Specification (per unit) | — | — | Required |
| Unit Implementation Records | — | — | Required |
| Full Traceability (Req ↔ Arch ↔ Units ↔ Tests) | — | — | Required |
| Independent Test Review Records | — | — | Required |
Brief description of each document
- Software Development Plan (SDP): How the software will be developed and maintained; team, methodology, tools, standards referenced, deliverables
- Software Requirements Specification (SRS): Functional, non-functional, and safety requirements for the software system; basis for testing
- Software Architecture Document: Partitioning of the software into software items; interfaces between items; rationale for architecture decisions
- Software Design Specification: Per-unit design; detailed design decisions, algorithms, data flows (Class C only)
- Unit Verification Records: Evidence that each software unit meets its design specification; unit test results
- Integration Records: Evidence that software items work correctly when integrated together; interface tests
- System Test Records: Evidence that the complete software system meets all SRS requirements
- Traceability Matrix: Links requirements to architecture, to units, to tests; ensures completeness
- SOUP Register: List of all third-party components with version, function, and anomaly evaluation
- Problem Resolution Records: Bug and issue tracking; all problems from all development phases
- Release Records: Documents what was released, what version, what tests were run, who approved release
Frequently missing documents
- SOUP anomaly evaluation missing: SOUP register exists but anomalies are not evaluated — just listed or ignored
- Traceability matrix not maintained: Created once, never updated after requirements or tests changed
- Architecture document too high-level: Shows only major system blocks; does not partition software into software items; insufficient for Class C
- No software version history: Releases made without formal release records; no reproducible build baseline
Frequently asked questions
Can documents be combined?
Yes. IEC 62304 specifies required content, not document titles. You can combine the SDP and SRS into a single document if all required content is present. Similarly, unit verification records can be part of the same document as integration records. What matters is that all required information is documented and accessible.
What is the minimum viable documentation set for Class A?
Class A minimum: Software Development Plan, Software Requirements Specification, system test records (showing SRS requirements were tested), software release records, SOUP register with known anomaly list, and problem resolution records. Six document types — none optional.
How granular must a Class C traceability matrix be?
The traceability matrix must link every software requirement to the architecture element that implements it, to the software unit(s) that implement it, and to the test case(s) that verify it. There is no requirement for line-of-code level traceability. Requirement-level traceability is the expected granularity.