3-Step Guide to Defining Requirements for DO-178C Software Development

To verify and complete any DO-178C guided software project, every part of that project needs to be requirements driven.  

Requirements are what enable an avionics software project as a whole, and act as a “control group” throughout the rest of the project’s lifecycle. And it should go without saying that control is key in avionics and flying aircraft, benefiting every project and function of the industry. Most aerospace professionals know that building requirements takes careful consideration, read: time. But if you have a good plan for building your requirements definitions, like the three-step approach ConsuNova developed to help said professionals, that time is significantly reduced and projects are improved across all metrics.

Preface: Establish high- and low-levels

The first step in Development is to define the high-level requirements of your code. Later in Development, you will define low-level requirements. Developing high-level requirements involves refining the context of system requirements allocated to software and defining any software-specific requirements that do not map to system requirements as derived requirements. While defining both high and low-level requirements, you should ensure that you follow the processes you agreed to follow in your PSAC – your certification authority is likely to check that you have done so during future SOIs.

1. Your requirements should be verifiable

It’s important to ensure that the requirements you write can be tested using the verification methodology you said you were going to use in your PSAC. This is important for both high and low-level requirements. If you generate requirements that can’t be tested, you’ll have two options: rewrite your requirements or change your verification methodology (and

renegotiate the changes with your certification authority). The cost of both options is high, so it’s best to ensure that your requirements are verifiable.

Common causes of unverifiable requirements include:

  • Not including specific verifiable and quantitative acceptance criteria such as values or behaviors in requirements.
  • Writing requirements that include implementation details without including enough detail on the behavior of a component to unambiguously define the aspects of its behavior that must be specified to support testing.

An example of this is writing requirements for the behavior of a state machine without including information on all possible inputs and the outputs expected from different inputs. This information must be specified in requirements as it may not be possible to infer the behavior of a component during testing, depending on the level at which the testing occurs. Having a well thought out Requirements standard should help your project avoid generating unverifiable requirements and reduce rework costs.

2. Collaboration is key

Engineers across your team will typically collaborate on requirements authoring and review, using requirements authoring tools and revision control systems to keep everyone synchronized. Pay attention to how you will meet major integral process objectives:

  • For configuration management, make sure that you have unique identification of each version of each requirement. You don’t need formal change control until you start later life cycle phases. For example, you can work informally on high-level requirements, discussing and amending as you go, but once you want to start the design work, you should create a baseline to store the reviewed and analyzed high-level requirements against which you perform the design work.
  • Verification evidence at this level includes reviews and analyses of the consistency and completeness of the requirements.
  • Quality assurance records from this stage can be generated by having SQA personnel involved in some of the requirements reviews, independently performing reviews and analyses, or having some proportion of the requirements re-reviewed or re-analyzed.

3. The importance of requirements traceability

Ensuring the correct management of traceability information (parent child relationships between requirements) is of paramount importance during the design assurance process. Aviation regulations dictate that airborne software must only implement Intended Aircraft Functionality. Traceability, and the validation of traceability links, is a key mechanism to ensure that only Intended Aircraft Functionality is implemented. The reason that DO-178C requires bi-directional traceability is that downstream traceability ensures that all Intended Aircraft Functionality is implemented, while upstream traceability ensures that all elements of the implementation exist to deliver Intended Aircraft Functionality. For this reason, traceability is a cornerstone of not just requirements for DO-178C, but also SOI#2 and #3 reviews.

Most projects working towards DO-178C compliance select to use a tool (either commercial or in-house) to manage requirements and generate traceability information. It is worth considering how well any tools you plan to use for verification interface with your requirements management tool. Some tools may offer features to import requirements information from your requirements management tool, thus helping you view your verification results in the context of your requirements. This makes it easier to map between your verification results and the requirements.

When everyone on your team understands what they need to do and have confidence in their required elements, it’s easy to both see and execute on the right path forward. Simply put, when your requirements are correctly defined, recorded and implementable, you’re going to get much better results no matter the focus or scope of your software or system.

Our live and online training courses review the importance of requirements definitions and traceability, among many other DO-178C and other guidelines’ best practices. To learn more and sign up for an upcoming course, visit our training page, here.

Leave a Reply