Traceability - why actually?

(Traceability) is an important concept in systems engineering. Even the V-model with its arrows suggests traceability, and systems engineering standards, such as the ISO 15288demand this in many places. Traceability also plays a major role in areas where functional safety is important. Whether ISO 26262 (vehicles) or ISO 13485 (medical devices), traceability is important everywhere.

But as with many other things, the creation and maintenance of traceability should not be an end in itself. There are said to be companies that have their own departments that do nothing other than maintain traceability. Even if this is used for analyses, the question arises as to whether the cost-benefit ratio is given with several full-time employees. But even if the effort is low, it is only justified if traceability is used effectively. What you should look out for here is discussed below.

Registration for the systems.camp North of the GfSE on October 7 in Hamburg. Details and registration >>

What is a trace actually?

A trace is initially simply a traceable relationship. This does not even have to be explicit: If two files are in the same folder, this could represent the relationship to the same project. If a term in the text is also listed in the glossary (and can be looked up), this is also a relationship.

In systems engineering, work is usually more formal. Professional tools store many traces automatically: this includes, for example, the version history, which allows users to examine how the element has changed over time and who has made these changes.

However, we usually think of traces as explicitly set relationships, for example between user requests and system requests.

What does the relationship mean?

A major problem with traceability is that it is often not explicitly defined what a trace actually means. Here is a concrete example:

In which direction should the arrow between "Functional Requirement" and "Test Case" point? And what does the trace mean?

According to the V-model, (a) is correct: The test tests the requirement. The meaning of the relationship is "tests".

However, you can also argue for (b). For example, if the arrow is to represent a dependency: The requirement has the dependent element Test. The meaning of the relationship is "has the dependent element". Below I show how this interpretation can improve the handling of changes.

It is already apparent here that there can be problems if it is not clear within the team what the traces mean. And this is particularly important if the traces are to be used, for example for dealing with changes.

If the meaning of traces is not clear and they are not used consistently, then traceability is largely worthless. [tweetthis]If the meaning of traces is not clear, then traceability is worthless[/tweetthis]

Use traceability

With modern tools, traceability can easily be used in both directions. This is not so easily the case without tools. To take the glossary example again: With a manually maintained glossary, traceability from requirement to glossary is easy (look it up in the glossary). Conversely, it is difficult and possibly imprecise (where is this term from the glossary used?).

It looks different with tools. In a professional tool, "Requirement" and "Test" would each be separate elements, with a navigable trace in between. A good tool should be able to determine the test coverage, regardless of the direction of the traces. Specifically: How many requirements (and which ones) are not covered by any test? This question can actually be answered by any professional requirements tool. For example, by defining a corresponding filter or a corresponding report.

Dealing with changes

Another area where traces are extremely important and helpful is when dealing with changes. Let's take a look at the example with requirements and tests. The direction plays a role here: if the test is adapted, this has no effect on the requirement. This is because the same requirement is still tested. If, on the other hand, the requirement changes, the test may no longer match it and must be reviewed. For this purpose, many tools have the option of setting a so-called "Suspect" flag. So if the requirement changes in the specific example, the trace for the test would become suspect: a person must check whether the test in its current form is still valid for the changed requirement. If yes, then the suspect flag can be reset. If not, the test must be adapted. This can then trigger further suspect relationships.

It has proven itself in practice that the direction of traceability is used universally for setting the suspect link. The advantage of this approach is that it is immediately clear what the direction means. It also makes a traceability analysis intuitively understandable. Specifically: Which avalanche of suspect links would trigger a change?

It has proven useful to use the direction of traceability to find "suspect" elements in the event of changes. [tweetthis]The direction of traceability shows "suspect" elements when changes are made[/tweetthis].

One last note on the subject of "Suspect": Not every change should trigger a suspect. For example, if the priority of a requirement changes, this should have no effect on the test.

Not everything can be linked

Finally, not every relationship should be allowed. Instead, careful consideration should be given in advance to which relationships exist and which are mandatory (for completeness analyses). Here is an example of a simple data model:

A solid arrow means that the relationship must exist, dashed lines show optional relationships. A good tool would only allow the relationships shown to be created.

Above, we asked ourselves which direction between "Functional Requirement" and "Test Case" is the right one. With the semantics of the suspect elements, solution (b) makes more sense than solution (a), which the V-model would suggest.

Conclusion

Good traceability ensures robust, complete system descriptions and helps when dealing with changes. For this to work, there must be an understandable traceability model. And you need a good tool to be able to use traceability effectively. But if both of these are in place, then you have a solid basis for every development project.