Traceability Matrices: Headache Or Real Value?

Traceability is becoming increasingly important in most engineering projects, if only on the grounds of ‘good practice,’ and it is specifically required for projects that have to meet safety standards such as DO-254 and ISO 26262.

To provide traceability, you must maintain the relationships between all aspects of a project; from the system-level requirements through implementation and verification. Unfortunately, many organizations reduce their traceability responsibilities to preparing a few matrices for major reviews and to comply with respective safety standards. Such an approach is very time-consuming and I would argue it does little if anything to improve the overall management of the project. Or the design for that matter.

Good traceability data helps prevent errors and omissions in specifications, design and test plans. The first step is to define a traceability model.

Figure 1. Example Traceability Model.

A traceability model is valuable for documentation purposes and, more importantly, to ensure that traceability relationships are created correctly. However, this is not doable without tool support.

Properly maintained relationships allow us to quickly determine which elements are likely to be impacted by a change to a requirement or test case.

Below is a view available from within Spec-TRACER that helps visualize impact analysis.

Figure 2. Impact Analysis.

This view shows the relationships between all project items. Clearly, the modification to the test case stipulating that the sensor for the brake pedal position must be monitored (TC-010) must have an impact on the testbench (TB_00120). It is also essential for the modification to tie in with the parent requirement HRD_REQ_010(3).

This change must be assessed and, to make it reliable, we need to review the related requirement and in most cases its parent items like safety goal and system requirement. The task becomes more challenging when there is a situation where a single test case verifies two or more requirements, which are themselves verified by other test cases. Without a tool maintaining traceability, full impact analysis becomes very difficult.

Assuming all relevant data is located in a single database, the impact analysis shown above can be performed in seconds. Also, any kind of traceability matrix required for review or documentation purpose can be generated without any extra labor and with confidence that it is based on real data.

Capturing traceability information
The key to correct (and therefore meaningful and valuable) traceability data is to have properly established relationships. Traceability links created together with the requirements, test cases and any other project-related items produce the best results.

Because there are frequently more than a dozen artifacts in any given project, we need some kind of pattern on which to produce new requirements, test cases and other project-related items. Below is another view from Spec-TRACER.

Figure 3. Item template for Hardware Requirement with automatic relationship to System Requirement.

In the above Item Creation window there are a number of templates, all of which ensure the relationships to decomposed system requirements will be established automatically.

Traceability for derived requirements
We also have ‘derived requirements.’ These are not decomposed from higher level requirements but come from a design decision. They are effectively new.

However, this does not mean that derived requirements are not traceable to the higher level requirements. Design decisions are made to meet requirements, so a derived requirement is also created to meet the higher level requirements.

This means that there are no reasons to exclude such requirements within your traceability model. Furthermore, the ability to trace the functionality described by derived requirements significantly aids the tracking and management of feature changes. Since derived requirements require additional assessment and validation, the traceability matrix must be supplemented with relevant information, as in the following example:

Figure 4. Traceability Matrix.

Traceability to source code
Almost every change in a functional specification impacts the design and test bench code. As such, having relationships to the source code together with code preview and navigation capabilities simplifies the assessment of the impact (of change).

Each organization has its own method of tracking requirements throughout the design test cases and test benches. This may be direct coverage information or through the use of tags. The relationship may be general, such as a relationship to a file or module, or more detailed, such as a link to an output port, block or function.

Regardless of the method, relationships to source code should be maintained in the same database as other traceability data. It is clear that the requirements management tool should support capturing such relationships. Below, we have another view from Spec-TRACER.

Figure 5. Source Code Parser panel presenting captured tags with traceability information highlighted with green, yellow and red.

The Source Code Parser available within Spec-TRACER is dedicated to managing relationships back to source code. Accordingly, for the previously considered modification of test case TC-010, the parsing related test bench code is presented. Such visibility supports an assessment of how the test case modification impacts the related test bench code.

Valid traceability data
Clearly, we do not want traceability data to become damaged or outdated due to changes in a specification or source code. This can happen when traceability is maintained in separate spreadsheets or another databases. In the example above, the traceability data is in the same database as the requirements and test cases. Operations are secure and do not require the additional burden of managing traceability data.

Summary
Traceability data definitely increases the quality of your product and, not without reason, the activity is required by safety standards. The key is to manage it according to its intended purpose; as a part of change management.

Maintaining traceability information in the form of a spreadsheet or simple database using manual processes may take from a few minutes to several hours. You just don’t know. If an engineer must also refer to the baseline specification, this trace activity can be even more protracted. By using a requirements management tool, once the data is entered the appropriate relationships are established – and no further action is required.