Traceability – 7 questions you need to ask to derive real value

Think about the following situation: You are near the end of your safety-related project, and you have established traceability between all the project artifacts. In an audit (e.g. Internal Quality Assurance, Customer, External Authority) you have to demonstrate which software requirements are developed from which system requirements. Each software requirement is linked to one or more system requirements, and any system requirement is also linked to one or more software or hardware requirements. You are in great shape for an audit – or are you?

Despite all the diligent linking, it is found in the audit that, while many software requirements are somehow related to the linked system requirements, an integrated traceability strategy is not recognizable. If it is then determined in further audited examples that some aspects of system requirements are not implemented in the software (or hardware), the audit starts to be stressful.

After this situation, you may start thinking about the time and money you spent to achieve a good traceability. You almost inevitably raise the question now: what is the justification for the use of tools and engineering time, if the result is so poor? And you may start thinking about a drastic reduction of time and effort in this area in the next project.

However, instead of doing this, you should start a root cause analysis, to identify the real issues. Basically, tools are very useful but there is also a significant added value if you do traceability correctly.

A major cause of problems is often the practice of “ link everything” to “everything”, as a substitute for a project-specific traceability strategy. In former times, when there was no convenient tool support for creating traceability, this problem simply did not exist. The effort to create such traceability was far outside any acceptable range. Because of this fact, project managers and teams were forced to do some very intense thinking about the following questions:

1. Which results of the Hazard and Risk Analysis are implemented in which requirement(s)?


2. What are the software requirements that implement (really!) the considered system functionality (= System Requirements)?


3. Which Software Requirement is not derived from any system requirement, but arises as a consequence of architectural decisions and should therefore remain (=no link to another functional Requirement) as “Derived” Requirement?


4. Which source code cannot be derived from functional requirements, but (e.g.) from the interface to the hardware?


5. Which source code occurs, for example, due to applied principles as Defensive programming and not on the basis of functional requirements?


6. What tests actually verify which requirements?


7. In which architectural block are which requirements implemented?

Thanks to the support of modern and innovative tools, it is much easier todayto put individual artifacts in the software development process into a useful relationto each other (that’s essentially what Traceability is). There are a variety of data-driven tools that reduce the complexity and the error rate for traceability creation significantly. If you also make yourself aware of the issues described here, and you develop appropriate solutions, you are on the way to achieve the desired added value (and less stressful audits!)

Traceability benefits:

• Very effective means to assure that the customer’s requested product was actually built.


• Easy and quick navigation from the system requirements to the source code/hardware implementation.


• In case of changes, effective support of required analysis to avoid unintended side-effects.


• Support and simplification of completeness checking with respect to the product implementation.


• Support and simplification of completeness checking with respect to the product verification.


• Good means to track the progress of implementation and verification

About the Author

Martin Heininger, of Heicon Global Engineering, has worked in management and implementation of functional safety projects in the aerospace, industrial automation, automotive and medical device industry for more than 15 years. Besides being a consultant and leading international safety critical projects, he is a frequent speaker about functional safety and an expert in offshoring verification and validation of software projects.

Photo: flickr.com/kelp