DO-178C Software Compliance for Aerospace and Defense

In airborne systems, requirements management is a mandatory part of the software development process and the traceability of those requirements to implementation. Subsequently, teams must ensure proof of correct implementation.

Requirements traceability is defined as “the ability to describe and follow the life of a requirement in both a forwards and backwards direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of on-going refinement and iteration in any of these phases).”
The objectives of traceability are to ensure the following:

• Functional, performance, and safety-related requirements of the system that are allocated to software were developed into the high-level requirements.
• High-level requirements and derived requirements were developed into the low-level requirements.
• Low-level requirements were developed into source code.
• Traceability between requirements and test cases, test procedures, and test results.

In the simplest sense, requirements traceability keeps track of each requirement’s decomposition into software and the tests used to verify and validate each requirement. It also tracks exactly what you’re building when writing software. This means making sure the software does what it’s supposed to and that you’re only building what’s needed.

If there are architectural elements or source code that can’t be traced to a requirement, then it’s a risk and shouldn’t be there. The benefits also go beyond providing proof of the implementation. Tracking each requirement’s analysis and decomposition is commonly used for visibility into development progress.

Requirements analysis requires that “All software requirements should be identified in such a way as to make it possible to demonstrate traceability between the requirement and software system testing.”

It’s important to realize that many requirements in safety-critical software are derived from safety analysis and risk management. The system must perform its intended functions, of course, but it must also mitigate risks to greatly reduce the possibility of injury. Moreover, in order to document and prove that these safety functions are implemented and tested fully and correctly, traceability is critical.

Tracing requirements isn’t simply linking a paragraph from a document to a section of code or a test. Traceability must be maintained throughout the phases of development as requirements manifest into design, architecture, and implementation. Consider the typical V-model of software.

Each phase drives the subsequent phase. In turn, the work items in these phases must satisfy the requirements from the previous phase. System design is driven from requirements. System design satisfies the requirements and so on.

Requirements traceability management (RTM) proves that each phase is satisfying the requirements of each subsequent phase. However, this is only half of the picture. None of this traceability demonstrates that requirements are being met. That requires testing.

In the V-model, each testing phase verifies and validates (V&V)the corresponding design/implementation phase. In the example, you see:

• Acceptance testing validates requirements.
• System testing verifies the system design.
• Integration testing verifies architecture design.
• Unit testing verifies module design and so on.

Software development on any realistic scale will have many requirements, complex design and architecture, and possibly thousands of units and unit tests. Automation of RTM in testing is necessary, especially for safety-critical software that requires documentation of traceability for certifications and audits.

Requirements Traceability Matrix

A requirement traceability matrix is an artifact or document that illustrates the linking of requirements with corresponding work items, like a unit test, module source code, architecture design element, other requirements, and so on.

The matrix is often displayed as a table, which shows how each requirement is “checked off” by a corresponding part of the product. Creation and maintenance of these matrices are often automated with requirements management tools with the ability to display them visually in many forms and even hard copy, if required.

Below is a requirements traceability matrix example from Intland Codebeamer. It shows system level requirements decomposed to high-level and low-level requirements, and the test cases that verify each.

Automating Bidirectional Traceability

Maintaining traceability records on any sort of scale requires automation. Application life cycle management tools include requirements management capabilities that are mature and tend to be the hub for traceability. Integrated software testing tools like Parasoft complete the verification and validation of requirements by providing an automated bidirectional traceability to the executable test case, which includes the pass or fail result and traces down to the source code that implements the requirement.

Parasoft integrates with market-leading requirements management and Agile planning systems including:

As shown in the image below, each of Parasoft’s test automation tools, C/C++test, C/C++test CT, Jtest, dotTEST, SOAtest, and Selenic, support the association of tests with work items defined in these systems, such as:

• Requirements
• Stories
• Defects
• Test case definitions

Traceability is managed through the central reporting and analytics dashboard, Parasoft DTP.

Parasoft DTP correlates the unique identifiers from the management system with the following:

• Static analysis findings
• Code coverage
• Test results from unit, integration, and functional tests

Results are displayed within Parasoft DTP’s traceability reports and sent back to the requirements management system. They provide full bidirectional traceability and reporting as part of the system’s traceability matrix.

The traceability reporting in Parasoft DTP is highly customizable. The following image shows a requirements traceability matrix template with requirements authored in Polarion that trace to the following:

• Test cases
• Static analysis findings
• Source code files
• Manual code reviews

The bidirectional correlation between test results and work items provides the basis of requirements traceability. Parasoft DTP adds test and code coverage analysis to evaluate test completeness. Maintaining this bidirectional correlation between requirements, tests, and the artifacts that implement them is an essential component of traceability.

Bidirectional traceability is important so that requirement management tools and other life cycle tools can correlate results and align them with requirements and associated work items.

The complexity of modern software projects requires automation to scale requirements traceability. Parasoft tools are built to integrate with best-of-breed requirement management tools to aid traceability of test automation results and complete the software test verification and validation of requirements.