Traceability: The most important link types

Traceability is important - word has gotten around by now. But what does a link actually mean? A link has semantics, often only implicitly. The most important link types are presented below.

Traceability is an important concept in systems engineering. Why traceability supports our activities I have already explained this in the past. In that article, I already explained that the meaning of links is important, but is often not explicitly documented, which can lead to problems.

The direction of traceability

In practice, we find two different philosophies on the direction of traceability. The following image illustrates this:

In which direction should the arrow between "Functional Requirement" and "Test Case" point? The short answer is: Both are correct, but the meaning is different. Specifically:

• (a) Here the trace means: "tests" (Test Case tested Functional Requirement)
• (b) Here the trace means: "is tested by" (Functional Requirement is tested by Test Case)

Nowadays, the tool specifies the link direction, as this is relevant for certain functions. For example, all professional requirements management tools are familiar with the concept of "suspect links". In this example, a test case becomes suspect if at least one of the linked functional requirements has changed. This is because it is then possible that the test case no longer matches the requirement. Conversely, however, a change to the test case would have no effect on the functional requirement in terms of "suspect". However, if a "test result" was attached to the test case, this would become suspect as a result of the change to the test case.

Since modern tools allow traceability to be navigated in both directions anyway, a clear understanding within the team is more important than the actual choice of the two options.

Implicit link types often sufficient

In the example just shown, it is probably clear to most people that the relation represents a test relationship. A label on the arrow "tests" is therefore redundant. Whether and how corresponding traceability link types are created in the tool is also of secondary importance. Care should be taken here to ensure that the user's work is not made more difficult, for example by having to select a link type as an additional work step. Of course, the semantics of the link should still be described in the process documentation. A rule of thumb: If a specific use case requires explicit link types, e.g. to be able to use corresponding filters, then this is justified.

The most important traceability link types

The link types described here are used in requirements management. If there are corresponding link types from the MBSE (e.g. defined via the SysML), these are also used.

"Derive" describes the relationship between two requirements, whereby the first was derived from the second. A derive relationship often indicates that we have moved from one level to the next, e.g. from the system view to the design view. I recommend not using a derive relationship in the same level if possible (even if it is There are situations where this could make sense).

As a rule, this also means that derived requirements are enriched with information that is not available in the higher-level requirement, for example as a result of design decisions.

Instead of "testing" further open we could also have used more general "verify" can write. Because testing is only one way of verifying. This relationship is used extremely frequently in practice. Problems can arise if the tool breaks, i.e. if there is no automatic traceability between requirements and tests.

Link types for MBSE Traceability

With the two link types just described, we can already define all relationships in a primitive V-model represent. In practice, however, there are almost always others, even with traditional systems engineering. More on this below.

We also work with textual requirements in model-based systems engineering (MBSE). This is why we also need the link types Derive and Verify presented above. But there are more to come:

"Refine" is used to make information more precise. The Refine relationship originates from the Modeling and is often used for relationships between model elements and requirements. In traditional requirements management (without system modeling), I recommend not using Refine so as not to confuse the team with its similarity to Derive.

Also in modeling, the Satisfy link shows how model elements fulfill corresponding requirements. Like Refine, the Satisfy relationship is the bridge between (textual) requirements and the model.

An important activity in systems engineering is "cutting" into subsystems and components. This is how we realize the Decoupling the systemwhat the Complexity makes it controllable. In order to bridge the gap between the logical and concrete structure of the system, we need to assign logical elements to concrete elements. This is done by assigning functions to subsystems with the Allocate link type.

Other link types

What I have presented here is the absolute minimum. Especially when developing systems where security plays a role, we need special link types for the corresponding traceability. This includes, for example, "mitigation", which links risks with the requirements that mitigate them.

In requirements management, we can configure the traceability and link types according to our own needs. In this respect, there are no real standards, only best practices. This also applies to the semantics of the links. It is advisable to document this.

With MBSE, on the other hand, the modeling language usually specifies both the link types and their semantics. The link types shown here are the SysML but are similar in most modeling languages. Here I recommend ensuring that all team members have the correct and same understanding of the link types used.

Do not forget: Implicit traceability

Finally: Not all traces are explicit. The team must also have a common understanding of the implicit link types. To name just one example: Even in document-based work, headings have a meaning and have an implicit traceability to the paragraphs in the chapter. This may sound trivial, but it is precisely things like this that can lead to major (and expensive) misunderstandings.

Photo by Susan Q Yin on Unsplash