The V-model principle that implementation-level design precedes coding — detailed design has always been a recognized lifecycle phase.
Explicit requirement to subdivide software to units as a documented step, not just an implicit outcome of coding. Class B applicability added by A1:2015. [Class B, C]
Documented software unit list with traceability to software items, and alignment of unit boundaries with the unit verification approach.
Maps to
IEC 62304: §5.4.1 Subdivide software into software units
ISO 13485: §7.3.4 Design and development outputs
Pre-QMSR Part 820 (legacy QSR): §820.30(d) Design output.
Requirement text
The manufacturer shall subdivide the software until it is represented by software units. Some software systems are not divided further. [Class B, C]
Why this clause exists
Software architecture documents describe components at a level sufficient to plan the system — they are not implementation blueprints. Detailed design requires decomposing each architectural component to the smallest unit that can be independently implemented and verified. Clause 5.4.1 establishes this decomposition as a deliberate, documented step rather than an informal outcome of coding: without it, developers make unit-boundary decisions ad hoc during implementation, producing inconsistencies between the architecture and the code structure that make verification of risk controls against design nearly impossible. For Class C software especially, where each software unit must be individually verified, the unit boundary definition drives the entire downstream verification scope — a poorly bounded unit set either fragments testing unnecessarily or obscures the actual functional boundaries that matter for safety.
What changed
Amendment 1 (2015) updated the clause title from 'Subdivide software into software units' in the 2006 edition to 'Subdivide software into SOFTWARE UNITS' with capitalized defined term, and the body requirement was simplified to 'The MANUFACTURER shall subdvide the software until it is represented by SOFTWARE UNITS.' The Class B applicability was added by A1:2015 (the 2006 edition applied this clause only to Class C). Class B software must now be subdivided to the unit level as well.
Common gaps (what we see in audits)
- Architecture document treated as detailed design without decomposition to units — Manufacturers use the software architecture document as the detailed design artifact without performing the 5.4.1 subdivision to software units. Architectural components are too coarse for unit verification — the architecture describes the system structure, while units must be at implementation granularity.
- Unit boundaries defined in code but not documented — Developers decompose to units informally in the code (e.g., as functions, classes, or modules) without documenting the unit list. The code structure implies units, but IEC 62304 requires documented decomposition so that verification can be planned against an enumerated unit set.