EXECUTIVE SUMMARY

Software Considerations in Airborne Systems and Equipment Certification, better known as DO-178C, has in recent years become the de facto standard for avionics software development.

As its title implies, DO-178C doesn’t specify a specific software process. Instead, it creates a flexible development framework designed to lead to system certification by relevant authorities. DO-178C specifies software lifecycle process objectives, along with activities for meeting those objectives. It also provides guidance for tailoring process objectives and activities to the level of safety the software must provide and for collecting evidence to show the process objectives have been met.

While DO-178C focuses on the software development process, it has implications at the system level, as well. In particular, the software requirements process is directly impacted by the system requirements process, which dictates the high-level software requirements.

This guide describes ten requirements engineering (RE) best practices aerospace organizations can apply to help assure their avionic software complies with DO-178C. The accompanying checklist is meant to help those organizations embed these best practices, both within their RE process and in the minds of their engineers.

1. DOCUMENT YOUR PROCESS FOR REQIRMENTS ANALYSIS AND REVIEW

Paragraph 5.1 of DO-178C provides guidance for the software requirements process. It’s first two recommendations are:

• “The system functional and interface requirements that are allocated to software should be analyzed for ambiguities, inconsistencies and undefined conditions.”
• “Inputs to the software requirements process detected as inadequate or incorrect should be reported as feedback to the input source processes for clarification or correction.”

Since DO-178C focuses on building software processes that assure adequate safety, it’s a good idea to have solid, well-documented system-level RE processes feeding your software processes. You should be able to show certification authorities you have standardized, repeatable processes that comply with their standards.

Your requirements analysis process documentation should provide an overview of the process and a description of each step. Describe the steps in terms of entry and exit criteria, procedures, tools to be used in your analysis, and any data or reports that are to
be produced.

Further recommendations for this process will be provided throughout the remainder of this guide.

2. DEFINE YOUR METHODS FOR ASSURING REQUIREMENTS TRACEABILITY

To comply with DO-178, your software requirements and design processes must demonstrate traceability. High-level software requirements must trace to system requirements. Low-level software requirements to high-level requirements, and so forth.

It’s important to plan how you will do this and to be able to show how you do it.

Decide what tool or tools you are going to use to maintain and demonstrate traceability. All commercially available requirements management (RM) tools have facilities for this. If you choose such a tool, be sure you understand its traceability mechanisms.

If you use a custom-built database or document-based RM system, your organization must define its own requirements traceability system. Typically, this is done by assigning a “unique identifier” number or code to each requirement and building tables or matrices that demonstrate the traceability of each requirement —both upward to its original source requirement and downward to the verification process

Learn how QVscribe can transform your design process.

Download a PDF copy of this guide.

3. DEFINE YOUR CRITERIA FOR EVALUATING REQUIREMENTS

Another DO-178C “activity” (or requirement), from paragraph 5.1.2, drives several of the best practices in this document: “The high-level requirements should conform to the Software Requirements Standards and be verifiable and consistent.”

To assure that your requirements are consistent, you need to define your criteria for evaluating requirements.

These criteria should include rules for the use of imperatives like shall, will, must and should—which of these are allowed and what each means in the context of the requirements document. Your criteria will also specify:

• The form and placement of unique identifiers in requirement statements
• Any templates to be used in forming requirement statements
• Words to avoid or to use with caution due to their tendency to introduce ambiguity
• How rationale and other explanation should be separated from the requirement statement

If you use a requirements analysis software tool, it will likely come initialized with a default set of evaluation criteria. You should adjust these settings to match your organization’s own criteria.

You may need to reference applicable documents. For example, your organization might decide to base your analysis criteria on those listed in the INCOSE Guide for Writing Requirements. Or you might adopt the Easy Approach to Requirements Syntax (EARS) as templates for your requirement statements. If so, you should reference those documents in your process documentation.

Some of the best practices that follow provide additional criteria for evaluating requirements.