Home Features Risk, SOUP & design
The clause 7 slice, the software you did not write, and the units underneath
Three registers that share one discipline: record the judgement, link it to the thing it is about, and let verification come from the trace rather than a second argument.
Software risk — the §7 slice, and only that
Hazards, harms, probability estimation, benefit-risk and post-market surveillance belong to the system risk management file your quality system owns. A risk record points at it by reference. SpecPad holds what software contributes: the hazardous situation, the units or components that could cause it, and the requirements controlling it.
No probability, deliberately. For software you cannot argue probability down; severity and the presence of a control carry the analysis. A row made acceptable by rating its probability “remote” is the error this register refuses.
A cause must be a software unit, not a cross-cutting design view — a view describes structure across units and cannot fail on its own.
SOUP and off-the-shelf software
Both regimes in one record. IEC 62304 wants the functional and performance requirements you place on the component (§5.3.3) and what it needs to run (§5.3.4). The FDA off-the-shelf guidance wants provenance, purpose, design limitations, and — at Enhanced level — support and end-of-life contingency.
- The version is exact, never a range: an anomaly evaluation is only valid for the version it was performed against.
- End of life is a date, with its source, not a sentence — a date can be compared to today, and a component already out of support is what the register exists to surface.
- Every performance requirement carries a number. “Renders 250 rows in under 200 ms”, not “no perceptible delay”.
- Development tools are not SOUP. Compilers, bundlers and test runners fall under §5.1.4 — none of it ships.
- This is not an SBOM. An SBOM is a recursive inventory generated from the manifests; this is the assessed subset. Letting one stand in for the other misrepresents both.
Detailed design that stays linkable
Sections are prose with a stable identity — markdown that can hold flowcharts and diagrams, and an immutable identifier that requirements point down at. The design is free to be rewritten without breaking a single trace.
A section declares whether it is a software unit (§5.4.2) or a cross-cutting design view (IEEE 1016). The distinction is load-bearing: §5.4.1 asks for a unit list, §5.5.3 asks for acceptance criteria per unit, and risk causes must resolve to units.
Change a section and every requirement referencing it becomes suspect — the design moved, so whether the requirement still holds as written is an open question. The skill makes that re-review part of the same job rather than a thing to remember.
Verification that attacks, not just demonstrates
A near 1:1 register of requirements to tests is the commonest failure in a verification protocol, and it is invisible — everything verified, governance clean, coverage 100%, and every requirement shown to work only when nothing goes wrong.
| Kind | What it exercises |
|---|---|
nominal | The happy path — the behaviour the requirement describes, under the conditions it assumes |
boundary | The edges of the accepted range, and which side of each edge is accepted |
negative | Invalid input, refused operations, and error paths — what the system will not do |
stress | Volume, concurrency, exhaustion and sustained load |
security | Testing beyond ordinary verification, in a security context (FDA §V.C) |
And separately, at what scope — because IEC 62304 treats §5.5, §5.6 and §5.7 as three activities with distinct records:
| Level | Activity |
|---|---|
unit | Unit |
integration | Integration |
system | System |