EN 62304:2006+A1:2015 Section 5.4 requires the manufacturer to refine the software architecture into a detailed design of the software units for Class B and Class C software. The detailed design decomposes each software item into software units, specifies the behaviour of each unit at a level that supports implementation, and defines the interfaces between units so the downstream unit implementation and verification activity under Section 5.5 has documented criteria to verify against. For Class A software, the standard does not require detailed design as a distinct activity — the architecture and the code are the documented levels. For Class B and Class C, the detailed design is the layer that converts the architectural view into unit-level specifications that a developer can implement and a verifier can test. The MDR is the North Star. EN 62304:2006+A1:2015 is the tool that operationalises the detailed design obligation under MDR Annex I Section 17.2.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN 62304:2006+A1:2015 Section 5.4 is the software detailed design clause — the activity that refines the software architecture from Section 5.3 into unit-level design that supports unit implementation and verification under Section 5.5.
  • Detailed design is mandatory for Class B and Class C software. For Class A, Section 5.4 is not required by the standard — the architecture and the code are the documented levels.
  • For Class C, the standard requires the design to be refined to a level where each software unit can be implemented directly. Class B requires enough detail that each software item is decomposed into software units with documented interfaces.
  • The interface specification between software units is the part of the detailed design that most teams underweight. Without documented unit interfaces, the downstream verification activity has nothing to verify against.
  • Traceability closes from software architecture to software units to detailed design to acceptance criteria to verification case. Every link must hold.
  • The lean move is to keep the detailed design in the repository, versioned with the code, referenced by stable identifiers from the tests — not in a parallel document that drifts from what is deployed.

Why detailed design is the layer that makes the architecture buildable

Software architecture tells you how the system decomposes into items and how those items talk to each other. Detailed design tells you how each item decomposes into units and how each unit is supposed to behave at a level that a developer can implement without guessing and a verifier can test without inventing the criteria. Without the detailed design layer in between, the architecture hands off to implementation with a gap that each developer fills on their own — and the resulting code is only as consistent as the judgement of whoever was typing at the time.

For Class A software the gap is acceptable under EN 62304:2006+A1:2015 because the risk profile does not justify the formalisation cost. For Class B and Class C the gap is not acceptable, and the standard closes it by requiring the manufacturer to document the design at the unit level before implementation starts. This is not ceremony. Every Notified Body review we have seen treat the detailed design as the structural evidence that unit verification under Section 5.5 has something real to verify against. A unit test file with no detailed design upstream is a test without a specification, and a test without a specification is not a verification activity.

Section 5.4 is also where the honest class-by-class subtraction pays off most clearly. A team that has allocated software items to safety classes correctly in the architecture activity arrives here with a short list of items that need detailed design and a longer list that does not. The team that bulk-assigned every item as Class C pays the Section 5.4 cost on every unit in the system. The team that bulk-assigned every item as Class A skips the activity where the standard requires it and will be caught at audit. The class determines the scope of the activity. Honest classification is how the subtraction move works.

Section 5.4 scope — what the clause covers

Section 5.4 of EN 62304:2006+A1:2015 — software detailed design — sits between software architectural design (Section 5.3) and software unit implementation and verification (Section 5.5). The clause has two parts. First, the manufacturer refines the software architecture into a detailed design for each software item, down to the level where each software item is decomposed into software units. Second, the manufacturer documents the detailed design for each software unit, and specifies the interfaces between software units and between each software unit and the components external to it.

The clause does not prescribe a notation. Detailed design can be documented in structured text, in diagrams, in tables, in headers, in pseudocode, or in any combination the team finds maintainable. What the standard requires is that the documented design is specific enough that implementation proceeds from it and verification can be planned against it. A detailed design that is too abstract to implement from is not a detailed design — it is a second copy of the architecture.

The scope of the clause scales with the software safety class. Section 5.4 is not required for Class A software. For Class B software, the clause requires the architecture to be refined down to the software-item level with documented interfaces between software units. For Class C software, the clause requires the fullest refinement — detailed design of each software unit at a level sufficient to implement the unit directly and to verify it against the Class C acceptance criteria categories that Section 5.5 calls out (event sequencing, data and control flow, resource allocation, fault handling, initialisation, self-diagnostics, memory management, boundary conditions).

The activity connects upward through EN 62304:2006+A1:2015 to MDR Annex I Section 17, which requires software to be developed in accordance with the state of the art taking into account the principles of development life cycle, risk management, verification, and validation. (Regulation (EU) 2017/745, Annex I, Section 17.) The detailed design is part of the design information in the technical documentation described in MDR Annex II, and the Notified Body reads it as structural evidence that the development lifecycle is real.

What detailed design actually means in practice

Detailed design in practice is the act of converting the architectural view of a software item into a unit-level specification that answers a specific set of questions for each unit. What is the unit's responsibility. What are its inputs. What are its outputs. What are the preconditions the unit assumes. What are the postconditions the unit guarantees. What errors can the unit encounter, and how does it handle them. What is the internal state the unit maintains, if any. What are the resources the unit consumes. What is the expected performance, if performance matters.

The form this takes varies by technology. For a back-end service written in a modern language, the detailed design is often a block of structured text or structured comments in the file that declares the contract the unit satisfies, paired with a type-annotated signature that enforces the interface at the language level. For embedded firmware, the detailed design is closer to traditional module specifications — memory layout, timing constraints, interrupt behaviour. For a machine-learning component, the detailed design includes the model interface, the input-preprocessing pipeline, the output-postprocessing rules, and the fallback behaviour when the model is uncertain.

What makes a detailed design audit-ready is that each unit's specification is written down, referenced by a stable identifier, linked forward to the verification cases that test it, and linked backward to the architecture that positions the unit in the larger system. The specification is not a paragraph of prose in a Notion page that nobody opens after the first draft. It is a living artefact in the repository that changes when the code changes, reviewed in the same pull-request process, and stored with the rest of the file.

Scaling by safety class — A, B, and C

The class-driven scaling of Section 5.4 is one of the sharpest subtraction opportunities in the whole lifecycle.

Class A. The standard does not require detailed design as a distinct activity for Class A software. The architecture from Section 5.3 and the implementation from Section 5.5 are the documented levels. Most teams still write some form of unit-level documentation for Class A code because it helps the engineering, but the regulatory obligation does not apply. A Class A item that has been honestly classified does not need the Section 5.4 deliverables.

Class B. Class B software requires detailed design at the software-item level, with the items decomposed into software units and with documented interfaces between the units. The depth is enough to support unit implementation and to give the verification activity documented acceptance criteria at the unit level, but it does not have to address the full Class C categories. A Class B detailed design can be shorter than a Class C detailed design for the same item and still satisfy the clause.

Class C. Class C software requires the fullest detailed design — refinement down to the software unit level at a depth that supports direct implementation and supports the Class C acceptance criteria categories under Section 5.5. The specification includes behaviour under fault conditions, resource constraints, boundary inputs, initialisation sequences, and state transitions that matter for safety. The verification that follows is only credible if the design the verification is checking against was written at this depth.

When Class A can legitimately skip this step

The most common error is treating Class A as "the class where you do not have to document anything" or as "the class you claim when you want to avoid work." Neither is what the standard says. Class A is the class assigned to a software item that cannot contribute to a hazardous situation, even indirectly, per the EN ISO 14971:2019+A11:2021 risk analysis honestly applied at the item level. For an item that meets that definition, Section 5.4 does not require a detailed design artefact, and the team does not have to produce one for the regulatory file.

The subtraction is real — and it is also narrow. A team that runs a segregation argument from Section 5.3 to isolate a Class C module inside a mostly Class A system can skip Section 5.4 for every Class A item, provided the segregation argument survives audit. A team that has a single monolithic back end with some Class C risk controls inside it cannot skip Section 5.4 anywhere, because the highest class applies to the whole thing in the absence of documented segregation.

The practical rule of thumb is this. Before claiming Class A for an item, verify two things. First, the EN ISO 14971:2019+A11:2021 risk analysis supports the claim — the item cannot contribute to any hazardous situation, and the analysis records that conclusion with the evidence. Second, the architecture either does not share resources with higher-class items, or the segregation argument from Section 5.3 holds. If both conditions are met, Section 5.4 does not apply to the item and the team saves the work honestly. If either condition fails, the Class A claim is not defensible and Section 5.4 applies.

The interface specification — the part most teams underweight

The part of the detailed design that auditors look for, and that most startup teams produce least consistently, is the interface specification between software units. A software unit's interface is the contract that defines how the unit interacts with other units and with external components. A detailed design that describes the internal behaviour of a unit in detail but leaves the interface implicit is only half complete.

An interface specification for a software unit answers a specific set of questions. What are the entry points into the unit — functions, methods, messages, endpoints. What are the parameters, including type, range, and semantic meaning. What are the return values or outputs, including the cases where the unit returns an error. What are the preconditions the caller must satisfy. What are the postconditions the unit guarantees when the call returns normally. What are the error conditions and how is the error reported. What is the timing contract — synchronous, asynchronous, timeout behaviour. What is the side-effect contract — does the unit modify global state, write to persistent storage, make external calls.

The specification does not have to be lengthy. A short block of structured text per entry point, paired with a type-annotated signature and a pre/post-condition statement, is enough for most cases. What matters is that the specification exists, is referenced by a stable identifier, and matches what the implementation actually does. The interface specification is what gives unit verification under Section 5.5 its acceptance criteria — without it, the verification activity has to reverse-engineer the criteria from the code, which is not verification.

Traceability from architecture to detailed design

Traceability at the detailed design level runs from the software architecture to the software item to the software unit to the detailed design entry to the acceptance criteria to the verification case. Every link has to hold. The architecture identifies the item and its safety class. The detailed design decomposes the item into units and specifies each unit's behaviour and interface. The acceptance criteria turn the specification into pass/fail conditions. The verification case exercises the unit against the criteria.

A gap anywhere in the chain is a finding. An architecture item with no detailed design is an unspecified item. A detailed design with no architecture entry is an orphan. An acceptance criterion with no detailed design entry to trace back to is a floating requirement. A verification case with no acceptance criterion is a test that measures nothing specific.

The practice that keeps traceability cheap is storing the detailed design in the same repository as the architecture, the acceptance criteria, and the code. Stable identifiers — unit IDs, criterion IDs, case IDs — let the links close as queries over the repository rather than as hand-maintained spreadsheets. A broken link becomes a CI failure. An audit finding is just a missed CI signal.

Common mistakes startups make with detailed design

  • Treating detailed design as a second copy of the architecture. If the detailed design says the same things at the same level of abstraction as the architecture, it is not a detailed design. The distinction is that the detailed design is specific enough to implement from, unit by unit.
  • Writing detailed design in a separate document that drifts from the code. A Confluence page written once and never updated is not a detailed design that survives audit. Keep the design in the repository with the code.
  • Skipping Section 5.4 for Class B items by claiming they are Class A. The risk analysis determines the class, not convenience. Class B items need the detailed design, and misclassifying to avoid the work will surface in the risk-file review.
  • Leaving interface specifications implicit. A unit with a typed signature and no behavioural contract is underspecified. Document the preconditions, postconditions, error modes, and side effects.
  • Over-designing Class A units to be safe. If an item is legitimately Class A under the risk analysis, Section 5.4 does not require detailed design. Writing one anyway pays the cost without the benefit.
  • Failing to link the design to acceptance criteria. Detailed design without downstream links is a dead-end document. Every unit specification should feed into the acceptance criteria that drive unit verification under Section 5.5.
  • Writing detailed design after implementation. Designing after coding is not design — it is documentation of whatever was typed first. The sequence matters because the design is what the verification activity verifies against, and a design written to match existing code verifies nothing new.

The Subtract to Ship angle

The Subtract to Ship move on software detailed design is to let the software safety class drive the depth of the activity, and to keep the artefacts inside the repository rather than parallel to it.

Classify honestly at the item level using the EN ISO 14971:2019+A11:2021 risk analysis. Class A items skip Section 5.4. Class B items get decomposed into software units with documented interfaces, at a depth sufficient to support unit verification. Class C items get the full refinement including the Class C acceptance criteria categories that Section 5.5 calls out. No bulk assignment in either direction.

Write the detailed design where the code lives. Structured text in the repository, versioned with the code, reviewed in pull requests, referenced by stable identifiers from the acceptance criteria and the verification cases. The audit artefact is the repository, not a separate document.

Keep the interface specifications tight and specific. Entry point, parameters, preconditions, postconditions, error modes, timing, side effects. A short block per entry point beats a long narrative.

Close the traceability chain. Architecture to item to unit to detailed design to acceptance criteria to verification case. Every link is queryable from the repository, not hand-maintained.

Cut every detailed design artefact that does not trace forward to a verification case or backward to an architectural element. Artefacts that do not trace are the Subtract to Ship tell — they exist because someone thought they should, not because the standard requires them. For the broader framework, see post 065.

Reality Check — Is your software detailed design audit-ready?

  1. Have you classified every software item honestly using the EN ISO 14971:2019+A11:2021 risk analysis, so that Class A, B, and C assignments reflect real risk rather than convenience?
  2. For every Class B and Class C software item, is there a documented detailed design that decomposes the item into software units?
  3. Does each software unit have a documented interface specification covering entry points, parameters, preconditions, postconditions, error modes, timing, and side effects?
  4. For Class C units, does the detailed design support the Section 5.5 acceptance criteria categories — event sequencing, data and control flow, resource allocation, fault handling, initialisation, self-diagnostics, memory management, and boundary conditions?
  5. Does the detailed design live in the same repository as the code, versioned and reviewed in the same change process?
  6. Does every detailed design entry trace backward to an architectural element and forward to acceptance criteria and verification cases, with no broken links?
  7. If you are skipping Section 5.4 for Class A items, does the risk analysis support the Class A claim and does the architecture either avoid shared resources with higher-class items or carry a documented segregation argument?
  8. Would the detailed design survive a Notified Body reviewer reading it as part of the technical documentation under MDR Annex II?

Any question you cannot answer with a clear yes is a gap that will surface at audit. Close it before the submission, not during it.

Frequently Asked Questions

Is software detailed design mandatory under EN 62304:2006+A1:2015? Detailed design under Section 5.4 is mandatory for Class B and Class C software. For Class A software, the clause does not require detailed design as a distinct activity — the architecture and the implementation are the documented levels. The obligation scales with the software safety class assigned through the EN ISO 14971:2019+A11:2021 risk analysis at the software-item level.

What is the difference between software architecture and software detailed design? Software architecture, under Section 5.3, describes how the software system decomposes into software items and how those items interact. Software detailed design, under Section 5.4, refines each software item down to the software unit level and specifies the behaviour and interfaces of each unit at a depth sufficient to support implementation and verification. The architecture is the structural view. The detailed design is the specification view at one level finer.

Does EN 62304:2006+A1:2015 require a specific notation for detailed design? No. The standard does not prescribe UML, a specific document template, or any particular diagrammatic notation. Structured text, tables, pseudocode, type-annotated signatures with pre- and post-condition statements, or any combination that produces a design specific enough to implement from and to verify against is acceptable. What matters is that the design is documented, traceable, and consistent with what is deployed.

Can a Class A software item skip Section 5.4 entirely? Yes, provided the Class A assignment is supported by the EN ISO 14971:2019+A11:2021 risk analysis and the architecture either avoids sharing resources with higher-class items or carries a documented segregation argument under Section 5.3. If both conditions are met, Section 5.4 does not apply to the item and the team does not owe a detailed design for it. If either condition fails, the Class A claim is not defensible.

What has to be in the interface specification for a software unit? The interface specification for a software unit covers the entry points into the unit, the parameters including type and semantic meaning, the return values and output channels, the preconditions the caller must satisfy, the postconditions the unit guarantees, the error conditions and how they are reported, the timing contract, and any side effects on shared state or persistent storage. A short structured block per entry point is usually enough, provided every field is addressed.

Where does detailed design sit in the MDR technical documentation? MDR Annex II lists the design and manufacturing information the technical documentation must contain, and the software detailed design is part of the design information for any device where software qualifies as a medical device or is an integral part of the device. (Regulation (EU) 2017/745, Annex II.) The Notified Body reads the detailed design as evidence that the Class B and Class C software units are specified at a depth that supports the verification activity under Section 5.5.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I Section 17; Annex II (Technical Documentation). Official Journal L 117, 5.5.2017.
  2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), Section 5.4 Software detailed design. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I and for the software safety class determination that scales Section 5.4.
  4. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for the QMS that wraps the software lifecycle.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the software detailed design activity required by EN 62304:2006+A1:2015 Section 5.4 for Class B and Class C software. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the harmonised tool that operationalises the detailed design obligation under MDR Annex I Section 17.2, and the detailed design is part of the technical documentation required by MDR Annex II, not an independent authority. For startup-specific support on scoping detailed design honestly by software safety class, documenting unit interfaces that survive audit, and keeping the design artefacts in sync with the deployed code, Zechmeister Strategic Solutions is where this work is done in practice.