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.<\/p>\n
Avionics, automotive and medical systems require airtight requirements. For the customers and users of these complex systems\u2014and the companies building them\u2014safety and security is critical.<\/p>\n
Getting safety-critical requirements right is a surefire step in the right direction.<\/p>\n
But too often, the requirements for these systems\u2019 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.<\/p>\n
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.<\/p>\n
The majority of product, version and variant failures stem from weak requirements. <\/strong><\/p>\n According to Vance Hilderman, CEO of the safety-critical systems and software engineering company AFuzion, \u201cSafety-critical requirements include safety aspects, but not exclusively. There\u2019s a grey area between functional, performance and safety requirements because if the system doesn\u2019t function, it can\u2019t be safe. If it doesn\u2019t 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.\u201d<\/p>\n \u201cAlmost all accidents related to software components in the past 20 years can be traced to flaws in the requirement specifications such as unhandled cases.\u201d<\/strong> – Software Engineering, Safety-Critical Requirements & Specification<\/em><\/p>\n The challenge is to prevent those accidents in the first place and try to make tomorrow\u2019s 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 \u201cbest,\u201d and how do teams utilize them? Vance offers some tips, below:<\/p>\n\n