How We Stopped Worrying and Learned to Love Requirements
This article was written by an SRES systems and functional safety expert with extensive experience in safety-critical embedded systems, software architecture, and requirements-driven development. The series explores practical approaches to writing clear, verifiable, and maintainable requirements for complex automotive and autonomous systems. It continues with Part 2: It’s Requirements all the Way Down and Part 3: Requirements as She is Spoke.
Looking to go deeper? Explore our ISO 26262 Functional Safety Training for practical guidance on safety requirements, traceability, verification, and requirements-driven development workflows. SRES also provides hands-on consulting support for automotive functional safety and software safety engineering.
“Show me the requirements!” is a ubiquitous refrain in systems, safety, and security engineering. Requirements are the basic foundation of most rigorous development standards like ISO 26262. Requirements can be an invaluable tool for communicating intent and guiding the development process. Why, then, are requirements often so difficult, seen as a challenge, and, in some cases, not used when they are created? One possibility is that documents are written that contain statements which are called “requirements” but are not really requirements, or are confusing, so the message is lost.
This blog is the first in a series of thoughts on requirements and how you can learn to recognize, write, use, and love good requirements.
What makes a good requirement?
Many engineers are familiar with the SMART formulation for requirements, along the line of “specific, measurable, achievable (or atomic), reasonable, testable.” ISO 26262:2018-8 clause 6.2.4 also specifies required characteristics for safety requirements. However, these heuristic guidelines often get lost in practicality. One of the most common pitfalls of “requirements” is that statements of design are often labeled requirements.
Consider this statement: [Statement-A] The beam shall have a length of 100±1cm and have a circular cross section of radius 5.0±0.1cm, circularity to within ≤0.02cm, deviation from straight along the entire length ≤0.2cm.
This statement is specific, measurable, testable, and has enough detail to allow a manufacturer to produce a beam. However, this statement violates the “implementation free” characteristic described by ISO 26262. So is this statement a requirement or is it a statement of design? What does this beam do? Does it serve its purpose?
Consider instead: [Statement-B] The mechanism shall maintain a linear separation between the two brackets of 100cm and support loads of X Newtons along the line between the two brackets and loads of Y Newtons in any direction in the plane orthogonal to the line between the two brackets.
[Statement-B] is closer to what we’d call an “implementation free” requirement: It specifies the purpose of the design. Note that the information in [Statement-B] allows an engineer to determine if the information in [Statement-A] is correct. Another way to think about the distinction is that a requirement provides context, where a design just defines “what is.” In other words, a requirement says why, a design statement says what to build, in order to achieve a goal. Another distinction is that designs can be constructed while requirements cannot.
This distinction is often particularly evident with software requirements. Software “requirements” tend to be written in a way that resembles pseudocode which is arguably not implementation free and contributes to sentiment that software requirements are superfluous – especially if they are written after software code itself has been written.
The general takeaway is that attempting to put too much detail into a requirement often results in a restatement of the design itself.
This can have safety and security risks due to unintended consequences relating to failures in communication of intent.
One caveat: there are often design constraints, often called requirements, most commonly deriving from regulation or business rules. These constraints are put into “requirements” documents, and they do specify a required design. For example, “high voltage cables must be a particular color” or “Components must have this specific label.” Incidentally these design constraints do have an implicit requirement behind them that is often not codified in a regulation. “Indicate to maintenance personnel that this is a high voltage cable” or “Indicate the component is subject to certain regulations” to follow the examples above.
Regardless of the conventions your organization uses, the intent is to promote a thinking about how we write requirements and how we make a distinction between “requirement” information and “design information” that fulfills requirements. This is just a starting point for deeper understanding. Once we have a distinction between “requirement” and “design statement”, how does that help us make more effective (technically and economically – including faster development cycles) products? How does this fit in with the concept of hierarchical design principles, or model-based systems engineering? We look forward to exploring these topics more deeply in the future.
Quick Links: Part 2 and Part 3
Have insights or questions? Send us an email at info@sres.ai or leave a comment below—we welcome thoughtful discussion from our technical community.
Interested in learning more about our approach? Explore why teams choose SRES training and how we help automotive organizations with consulting support across functional safety, cybersecurity, autonomy safety, and EV development.
