You can’t build good software without good requirements. For safety-critical avionics software, where failure can cause severe injuries or fatalities, good isn’t good enough. Your requirements must be foolproof. Your DO-178C certification depends on it.
This 10-point best practices checklist emphasizes requirements while providing overall tips to fly a safe course to DO-178 certification. Here’s what you’ll need.
DO-178C compliance demands thoroughness, clarity and precision. Be prepared to explain every step based on entry and exit criteria, tools used during your analysis, and any procedures, reports or data the certification authorities require. Make sure you show the big picture too, so authorities can see how all the details add up.
Make it easy for authorities to connect the dots. Show how the low-level requirements trace to high-level requirements, high-level requirements trace to the system requirements, and up to the test cases and test results. Spell out which tool or tools you’re using.
Words matter, and in safety-critical avionics software they can be a matter of life or death. Prevent ambiguity and confusion by specifying when/if to use words like will, shall, should and must.
Note any words that should be avoided or used with caution.
Express functional requirements in terms of a specific system’s quantitative input and output. Specify tolerances not just in relation to input and output quantities, but also to system reaction times. (This is where data transmission times and latencies are stored.)
Ambiguity is a peril to safety. Don’t give any stakeholder or reviewer a reason to wonder what you mean. The measurement units and technical terms must be consistent with every use in the requirements. To enforce consistency and demonstrate your commitment to it, create an updatable glossary.
If you specify every implementation detail of how an algorithm should function, the system will become cluttered. That will overload the checking system, causing problems in verification. Apply the less-is-more rule and limit details to only those that are essential.
It’s helpful to explain the rationale behind derived requirements, but be careful that your explanation or rationale doesn’t misrepresent or conflict in any way with what the requirements say. Keep explanatory text separate from the stated requirement for ease in reviewing.
Requirements are written in natural language, making the two-step manual analysis process even longer and more tedious. Open-source NLP tools can automate the process, generate reports and protect your schedule, freeing engineers for more critical tasks.
Diverse stakeholders can unknowingly trigger requirements bloat, clogging your processes. Use an analysis tool to eliminate duplicate or conflicting requirements and find ways to combine similar ones, resulting in a manageable, more highly focused set.
DO-178C states that derived requirements must be “provided to the systems processes,” which means the requirements analysis process as well as the system safety assessment process. In other words, you need to apply your documented process of requirements analysis to all the high-level software requirements that you have defined.
Ask a Software Testing Expert
Following these best practices will set you on the right course for successful DO-178C compliance. However, DO-178C lists dozens of objectives for processes and activities. The higher the risk to passengers and safety of your software, the more objectives you’ll have to meet.
Aerospace software testing experts, with their shift-left approach to the SDLC, can help ensure the rigorous attention to detail and precision required, while keeping your project schedule and delivery perfectly on track.
