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
Therefore, safety requirements can appear in different forms. They are functional when they define what the system shall do to remain safe. They are non-functional when they define how reliably, quickly, or robustly the system shall perform the safety behavior.
Many companies provide internal guidelines for writing requirements. These guidelines however should go beyond textbook categories.
In practice, the key question is not classification. It is whether the requirement is clear, testable, measurable where needed, and traceable to architecture, design, and verification results.
A good safety requirement should be clear, testable, and measurable where needed. It should also trace to architecture, design, and verification results.
Safety cannot remain an abstract quality statement in a safety-critical system. Engineers must translate it into concrete behavior and 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.
