Safety Requirements in System Specifications: Functional or Non-Functional?
System Requirements and the Textbook View
A System Requirements Specification (SRS) defines what a system shall do. It also describes the conditions under which the system shall operate. Engineers use this document as a basis for architecture, design, implementation, verification, and validation.
General academic teaching in software engineering, often based on widely cited requirements engineering literature, divides requirements into functional and non-functional requirements.
Functional requirements describe system behavior. They state what the system shall do.
Non-functional requirements describe qualities and constraints. Examples include response time limits, availability targets, fault tolerance levels, reliability targets, resource use, and safety-related limits.
Teaching often presents safety as a non-functional property because safety constrains acceptable system behavior. However, practical safety engineering shows a broader picture: safety can also define explicit system behavior. In practice, this boundary is rarely as clean as textbook classifications suggest.
Safety Requirements in Practice
The difference between theory and practice becomes clear in real projects.
A requirement such as “The system shall transition to a safe state upon detection of an internal failure” describes safety behavior. It tells the system what to do when a fault occurs. Engineers can verify this requirement through methods such as fault injection or diagnostic testing.
Another requirement may state: “The system shall transition to the safe state within 100 ms.” This requirement also concerns safety. However, it defines a timing constraint, not a new function. Test teams can verify this through timing analysis and test evidence.
This is not just a theoretical concern. A requirement can be meticulously written, correctly categorized, and fully reviewed — and still be implemented in a way that misses its intent entirely. The engineering process around the requirement matters just as much as the requirement itself.
© Randall Munroe, xkcd.com/2021, CC BY-NC 2.5 — “Software Development”
Verifiability Matters More Than Classification
Safety requirements can take different forms. They are functional when they specify what the system must do to maintain a safe state. They are non-functional when they constrain how reliably, how quickly, or how robustly that behavior must be achieved.
Many organizations define internal guidelines for requirement writing. However, these should extend beyond textbook classifications and focus on practical quality criteria.
A sound safety requirement is clearly specified, verifiable, measurable where necessary, and traceable across architecture, design, and verification artifacts.
Safety cannot remain an abstract property in safety-critical systems. It must be expressed as concrete system behavior and, where applicable, supported by measurable constraints.
In short, safety belongs in the system requirements specification as a cross-cutting concern. It describes what the system must do, how well it must do it, and how the architecture must support it.
The practical goal is not strict classification. The goal is clear and verifiable safety requirements.
At innotec, this is exactly the kind of work we do with our clients every day. We support teams in structuring safety requirements that go beyond textbook classification — requirements that are clear enough to implement, specific enough to verify, and robust enough to survive a safety assessment. Get in touch with us to learn more.
