Requirement and Test Traceability: 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 also any system requirement is linked to one or more software or hardware requirements.

Traceability and audits

Nevertheless, it is found in the audit that many software requirements, are somehow related to the linked system requirements, but 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 also start thinking about the time and money you spent to achieve a good Requirement and Test Traceability. You almost inevitably raise the question now, what is the justification for the use of tools and engineering time, if the result is such poor. You may start thinking about a drastically reduction of time and effort in this area in the next project.

“Everything” to “Everything” traceability

However, instead of doing this, you should start a root cause analysis, to identify the real issues. Basically, the use of tools is very useful and there is also a significant added value if you do traceability correctly.
A major cause of the problems described is often the linkage of “everything” to “everything”, as a substitute for the use of a project-specific traceability strategy.
In former times, when there was no convenient tool support, in the creation of traceability, this problem just did not exist. The effort to create such traceability was far outside any acceptable range. Because of this fact, the projects were forced to make very intense thoughts about the following challenges:

1. Which results of the Hazard and Risk Analysis are implemented in which requirement(s)?
2. What are the software requirements which 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 can not 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 verifies which requirement, really?
7. In which architectural block which requirements are implemented?

This list of questions does not claim to be complete.

But it forms a good starting point if you want to achieve a useful traceability.

Thanks to the support of modern and innovative Tools it is today much easier to put the individual artifacts in the software development process in an useful relation (Traceability) to each other. There are a variety of database-driven tools that reduce the complexity and the error rate for the traceability creation significantly. If you additionally make yourself aware of the issues described and you develop appropriate solutions, you are on the way to achieve the desired added value.

Traceability benefits:

1. Very effective mean to assure that the customer’s requested product was built accordingly.
2. Easy and quick navigation from the System Requirements to the Source Code/Hardware Implementation
3. In case of changes, effective support of required analysis to avoid unintended side-effects
4. Support / simplification of the completeness check with respect to the product implementation
5. Support / simplification of a completeness check with respect to the product verification
6. Good mean to track the implementation and verification progress

Releated HEICON Blog posts:

• Requirement Engineering – Aspects which even not considered in RE theory!
• Structural source code coverage and Requirements – Is there any dependency?
• DO-178B/C, ISO 26262, IEC 61508: How many level of Software requirements are necessary and useful?

Are you ready for a status workshop, to analyse improvement potentials in your requirement engineering, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.