Systems Engineering

Best Practices for Developing Safety-Critical System Software Requirements

By |

What do you call a system that has never-changing requirements? An obsolete system. Systems that are healthy and growing are always evolving or changing in some way.

Avionics, automotive and medical systems require airtight requirements. For the customers and users of these complex systems—and the companies building them—safety and security is critical.

Getting safety-critical requirements right is a surefire step in the right direction.

But too often, the requirements for these systems’ components invite more questions than they answer, and requirements management turns into a process of trying to pick out the bits of data you need, when you need them, while everything churns together in a roiling, boiling stew.

Safety-critical systems developers working with regulations and compliance standards know that opting for speed over safety, or safety over speed, adds risk. To succeed, both must be prioritized.

The majority of product, version and variant failures stem from weak requirements.

According to Vance Hilderman, CEO of the safety-critical systems and software engineering company AFuzion, “Safety-critical requirements include safety aspects, but not exclusively. There’s a grey area between functional, performance and safety requirements because if the system doesn’t function, it can’t be safe. If it doesn’t meet performance criteria it might not achieve safety aspects, but then there are explicit safety requirements as well. The problem is that most safety-critical requirement specifications are incomplete. They lack complete hazard-prevention mitigation. They can all be improved.”

“Almost all accidents related to software components in the past 20 years can be traced to flaws in the requirement specifications such as unhandled cases.” – Software Engineering, Safety-Critical Requirements & Specification

The challenge is to prevent those accidents in the first place and try to make tomorrow’s unhandled case be a handled case today. Knowing the right procedures for developing safety-critical requirements is the key. But what are these best practices, why are they the “best,” and how do teams utilize them? Vance offers some tips, below:

  • Good requirements should be mandatory. That means not a goal, not if you have time but truly mandatory.
  • Requirements must be consistent. Meaning, they don’t conflict with other requirements. Systems engineers must be able to manage and analyze requirements; with complex systems you need tools for that.
  • Requirements must be uniquely identified. They must state what we do, not how. The “how” is design and architecture.
  • Requirements need to be complete and unambiguous. That means full concurrence among developers as to what a requirement means, with no need for interpretation, because the requirement has sufficient detail to know exactly what the developer of that requirement intended.
  • Requirements must be consistent, with no conflicting characteristics. We know the priority, the timing aspects and we know the performance attributes. We cannot have conflicting logic. A or B, or A and B when C is not valid. We avoid different terms. For example, “trigger, assign, prompt, display, cue.” Those five words could be interchangeable but they’re different. We must be consistent.
  • Requirements must be traceable. That’s an essential part of good requirements management activities—to trace up to a system-level requirement and trace down to the implementation and the test. Traceability is also used during the code review to assess, “Does this logic fully implement all it should”?
  • Requirements must be testable. Each requirement is defined in quantifiable terms. For each requirement, can a test be formulated that will unambiguously answer the question, “Has the requirement been met?” Some things are that simple.
  • Requirements must be verifiable. For example, take this requirement, “The system shall support autonomous driving or flying.” All of us in the automotive world, we’re leaning towards that, from aviation to new AVs.

To learn more about how to build, maintain and reuse a rock-solid requirements foundation, please watch Developing Safety-Critical System & Software Requirements.

Latest posts by Marc Oppy (see all)