The Workbench · Craft
IEC 62304 ties software requirements to risk twice
This blog has already covered what IEC 62304's safety classification decides before a manufacturer writes code, and how the standard's SOUP duty runs independent of that classification. Clause 5.2, software requirements analysis, sits earlier in the lifecycle than either, and it does something ISO 13485's own design-input clause doesn't: it doesn't just ask a risk analysis to hand the requirements process its constraints once. It requires the manufacturer to re-open that same risk analysis every time the requirements themselves change — a link that runs in both directions, not one.
A requirements list has to cover more than function
Clause 5.2.2 of IEC 62304 doesn't let a software requirements specification stop at what the software does. Alongside the functional and capability requirements a team writes first, the clause's own list reaches into the software's inputs and outputs, its interfaces to other systems and to its own user interface, requirements tied to data and database definitions, installation and acceptance requirements at the site where it's deployed, how the software is meant to be operated and maintained once it's running, the environment it has to run in, and security requirements — authorization, authentication — that a purely functional read of “what the software does” leaves out entirely. A requirements document built around a feature list and nothing else has covered maybe half of what 5.2.2 is actually asking for.
Risk control measures are requirements, not attachments
Clause 5.2.3 makes a specific demand out of that list: any risk control measure the device's risk analysis assigns to software has to be included among the software requirements themselves, not filed separately in the risk management record and linked back with a cross-reference. A dose limit enforced in code, an interlock that blocks a command until a precondition clears, a timeout that forces a device into a safe state — each of those is a requirement the SRS has to state directly, in the same document and at the same level of specificity as any functional requirement next to it. A risk file that names the control and a requirements document that only gestures toward it with “per risk analysis” hasn't satisfied 5.2.3; it's split one requirement across two documents and left the actual wording of the control undefined in either.
The link runs backward too
This blog has already covered how ISO 13485's Clause 7.3.3 pulls risk management's outputs into design inputs — a one-time capture, upstream of the design work that follows. IEC 62304 doesn't stop at that single handoff. Clause 5.2.7 requires the manufacturer to re-evaluate the medical device's risk analysis whenever the software requirements are established, and again whenever they're updated. A late-stage requirements change — a new interface added after integration testing exposed a gap, a performance requirement loosened because the original spec proved unbuildable on the target hardware — doesn't just need a version bump on the SRS. It reopens the same risk analysis the original requirements were built from, on the theory that a changed requirement can change what the device can go wrong in ways nobody re-checked.
Verifiable is one test among several
Clause 5.2.6 doesn't ask a reviewer to read the finished requirements list and judge whether it feels complete. It sets six specific tests every individual requirement has to pass: it has to implement whatever parent requirement or risk control it traces to, avoid contradicting any other requirement in the set, read unambiguously, be uniquely identified, be traceable back to that parent, and be verifiable — written specifically enough that a later test can pass or fail against it, not just be discussed. A security requirement that reads “the system shall restrict access to authorized users” states an intention, but it doesn't pass 5.2.6 on its own; naming the authentication mechanism and the specific access levels it has to enforce is what turns it into something a test procedure can actually check — a distinction that matters as much for a Class A item as for a SOUP-flagged one.
Where this meets the file
None of this runs before the safety classification decides how much of the standard's own rigor a given software item owes — but once a class is set, 5.2's own content, risk-control, and re-evaluation duties apply regardless of how low that class turned out to be. A software requirements worksheet built around the full 5.2.2 category list, a field that carries each risk control measure's own wording rather than a cross-reference, and a re-evaluation trigger tied to every requirements change — not just the ones that look safety-related on first read — is previewed in the launch catalog. If your team structures that loop differently, the shelf takes that correction directly.
The Regulatory Toolkit launches soon — a free shelf of source-mapped templates, checklists and browser-only tools for regulatory teams. Get one email when it opens, or contribute a template.