Requirements for Safety-Critical & Regulated Systems

September 2, 2026· 9 min read

In most projects, "verifiable" and "traceable" are qualities you aim for. In a safety-critical or regulated system, they stop being adjectives and become legal requirements. The specification is no longer a working document — it is evidence, and a missing traceability link is a finding, not a style issue.

This post is about what that shift means for how you write requirements, and what the major standards actually demand of them.

Why regulation changes the spec

An unregulated product can ship with an undocumented decision and nobody will ever ask. A regulated product will be audited, and the auditor will ask one question about every claim: show me the requirement, and show me the evidence it was met.

That question turns the specification into the spine of the whole project. If the trace from requirement to design to code to test is broken anywhere, the audit fails — even if the product itself works perfectly.

The standards, briefly

IEC 62304 — medical device software. Classifies software by risk (A/B/C) and demands documented requirements with traceability to design and verification, heavier for higher classes.
ISO 26262 — automotive functional safety. Assigns ASIL levels (A–D) and requires safety goals decomposed into safety requirements, each traced to design and tests.
DO-178C — airborne software. Defines design assurance levels (DAL A–E) and requires both forward and backward traceability plus verification with coverage analysis.
IEC 61508 — the parent functional-safety standard for electrical/electronic systems, which the others specialize.
In energy storage, the same discipline applies across IEC 62619 (cell safety), UL 9540 (energy storage systems), and NFPA 855 (installation) — where a safety requirement without evidence is a hazard, not a formality.

What the standards actually demand

Requirements that are written, reviewed, and under change control — not a living wiki anyone can edit.
Forward traceability — every requirement maps to design, code, and tests that satisfy it.
Backward traceability — every line of code and every test points back to a requirement, so nothing exists that was not asked for.
Verification with evidence — a test record, not an assertion, proving each requirement is met.
Risk-driven rigor — the higher the safety class (ASIL, DAL, or IEC 62304 class), the more evidence you must produce.
Change control as a discipline — a change to a requirement is a change to the safety case, and must be re-verified.

Traceability is the load-bearing requirement

In these systems the traceability matrix is not a deliverable you produce at the end. It is the structure that holds the safety case together, and it must be maintained continuously — because a requirement that cannot be traced is, from the auditor’s point of view, a requirement that does not exist.

This is the single biggest difference between writing requirements for an app and writing them for a certified system: in the app, a forgotten link costs you a bug. In the certified system, it costs you the certification.

What this means in practice

Write requirements you can point to — singular, unambiguous, and with a unique identifier each.
Keep the trace maintained, not reconstructed — build it as you go, or the audit rebuilds it for you, painfully.
Treat every change as a controlled event — assess impact, re-verify, and record it against the requirement.
Keep the evidence — the test record is as much a part of the spec as the sentence.

In a regulated system the specification is not documentation of what you built. It is the proof of what you promised — and the auditor reads it like a contract, because that is exactly what it is.