Requirements Traceability: ISO 26262 Software Compliance

Requirements and the Traceability Matrix

In ISO 26262, requirements management is a mandatory part of the software development process and the traceability of those requirements to implementation—and subsequently, proof of correct implementation needs to be ensured.

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).”¹

In the simplest sense, requirements traceability is needed to keep track of exactly what you’re building when writing software. It is used to verify requirements, which means checking documentation and design specifications against requirements to ensure the software does what it’s supposed to and that you’re only building what is needed.

Traceability works both to prove you satisfied the requirements and to identify what doesn’t. 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 go beyond providing proof of the implementation. Disciplined traceability is an important visibility into development progress.

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, 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 diagram of software.

Graphic showing how traceability goes forward and backward through each phase of development. — The classic V diagram shows how traceability goes forward and backward through each phase of development.

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 through execution to validate requirements.

Graphic of V-model validation between each development and testing phase. — Various levels of requirements are validated at various phases of development using different test methods.

Acceptance testing validates customer requirements.
System testing validates system requirements.
Integration testing validates architecture design.
Unit testing validates module design.

Software development on any realistic moderate to large 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 a document that illustrates the satisfaction of requirements with a corresponding work item, like a unit test, module source code, architecture design element, 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 PTC Codebeamer. It shows system level requirements decomposed to high-level and low-level requirements, and the test cases that verify each.

Snapshot of a Codebeamer traceability matrix — Requirements traceability matrix example in PTC Codebeamer.

Automating Bidirectional Traceability

Maintaining traceability records on any sort of scale requires automation. Application lifecycle 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 such as PTC Codebeamer, Polarion from Siemens, Jama Connect, Atlassian Jira, and Azure DevOps Requirements.

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, and test case definitions. Traceability is managed through the central reporting and analytics dashboard, Parasoft DTP.

Infographic of Parasoft tools and their bidirectional requirements traceability with requirement management systems by way of DTP. — Parasoft provides bidirectional traceability from work items to test cases and test results, displaying traceability reports with Parasoft DTP and reporting results back to the requirements management system.

Parasoft DTP correlates the unique identifiers from the management system with static analysis findings, code coverage, and 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 test cases, static analysis findings, the source code files, and the manual code reviews.

Screenshot of DTP showing ISO 26262 compliance dashboard — Requirements traceability matrix template from Parasoft DTP integrated with Polarion ALM.

The bidirectional correlation between test results and work items provides the basis for 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 lifecycle 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 into test automation results and complete the software test verification and validation of requirements.

¹Gotel O.C.Z and Finkelstein A.C.W., “An analysis of the requirements traceability problem”, in Proceedings of ICRE94, 1st International Conference on Requirements Engineering, Colorado Springs, Co, IEEE CS Press, 1994

ISO 26262 Software Compliance in the Automotive Industry

Requirements and the Traceability Matrix

Requirements Traceability Matrix

Automating Bidirectional Traceability

Elevate your software testing with Parasoft solutions.