Requirements Traceability — what is it (good for)?

Boris Holzer
4 min readDec 6, 2019

--

I want to explain requirements traceability: What is it? What are today’s challenges? What are the potential benefits?
The management summary is: It is so much more than a matrix which relates requirements and test cases.

According to Wikipedia, traceability is the capability to trace something. According to uncounted publications, requirements traceability is about links between requirements and test cases. The common suggestion is to create a matrix consisting of e.g. one row per requirement, one column per test case (or the other way around). In this matrix, you can tick those cells representing a requirement which is verified by a test case. Wonderful Terry Pratchett would have called this explanation “a lie for children”, i.e. it gives a simple explanation which may be wrong, but is understood and accepted even by complete laymans.

Today’s challenges

There are two drivers in modern software or systems development which make things a little more complicated. To stay in Pratchett’s picture, I will now tell a “lie for students”.

One driver is the complexity of modern systems. To master this complexity, we use derivations and refinements. A software test may e.g. verify a software requirement which is implied by a software architecture decision which is based on the system design which has been decided to meet a given customer requirement. To which requirement should the software test now be traced? The answer is simple: It should be traceable to each requirement, design element, etc. which has an impact on it. The solution is to create traceability links between pairs of artifacts. By doing so, a trace can be regarded as a chain of traceability links. This idea of consistent traceability is so powerful.

That is why several standards declare it as mandatory for the development of safety-critical systems.

An example for the specification of traceability — in this case as part of theAutomotive SPICE Process Assessment / Reference Mode

By the way, in this post Florian explains, why a multi-dimensional trace matrix will hardly solve the problem.

The other driver is the amount of data. In the field of safety-critical systems, projects comprise hundreds of thousands of artifacts. Current projects in the area of autonomous driving expect millions of artifacts. The resulting matrix won’t probably fit into an Excel file.

Potential benefits

Imagine the benefits you can get from a good traceability tool. It should not only be able to recognize all relevant artifacts but also to maintain the trace links between them. The tool should also be able to analyze the resulting graph of development artifacts. They are your project.

The low hanging fruits provided by such tools are answers to the questions “What is linked?” and “What is not linked?”. These so-called impact- and coverage-analyses are state-of-art in the field of requirements traceability.

Impact analysis: What is linked to Stakeholder Requirement 2.1.5

The change analysis is a little bit more challenging. Imagine you want to compare different versions of requirements or complete specification documents. You may even want to compare the entirety of artifacts in your project. Given that your traceability tool provides historization of data, such a comparison should be possible, too.

Delta Report: A requirement changed and there are some new integration tests

Now let’s go one step further. You don’t want to get only the low-hanging fruits. You want the whole cake. The data provided by a traceability tool can contain so much more information than “pure” traceability.

You could, for instance, check your project’s KPIs based on these data. As an example, we define the implementation status for customer requirements as follows:

A requirement is considered to be…
… New - if is not linked at all
… Analyzed - if it has at least one link to an internal requirement
… Implemented - If all traces (i.e. link chains) are complete
… Work in Progress - if none of the above cases matches

You can then run your analysis regularly and get a project progress monitor.

Requirement Implementation Status in Traceability Dashboard

You also could create smooth tool integrations which e.g. provide navigation support for your engineers.

Navigation from code to software design model to test case

Finally, I want to draw your attention to an empirical evaluation done by Prof. Dr. Patrick Mäder et.al. The findings show that subjects utilizing traceability performed on average 24% faster on a given task and created on average 50% more correct solutions. That means that traceability does not only save effort but can profoundly improve the quality of software maintenance.

Do you have comments or ideas? Please let me know.

The screenshots in this post show the tool YAKINDU Traceability.

--

--