Cross-tool traceability: referencing or synchronization?

That Traceability has already been highlighted here. Professional tools in the systems engineering environment generally support this. However, one tool is usually not enough (see question 3 in Seven questions for choosing the right tool for systems engineering). And the moment more than one tool is needed, the question arises as to how traceability can be realized across tool boundaries. This often leads to two approaches: referencing and synchronization.

Before we look at these solutions, it is of course important to understand the problem: Which use cases should actually be realized with the help of cross-tool traceability, and why? This is the first question that will be discussed below. We will then take a closer look at the possible solutions.

What is to be achieved?

Of the many ways in which traceability can be used, two stand out that are important in practice:

Coverage: Tracking can be used to ensure that "everything has been taken into account". Specifically, if there is a link from each stakeholder requirement to at least one system requirement, we can assume that all stakeholder requirements have been taken into account.

Dealing with changes: A change automatically marks all "derived" requirements as "suspect". Derived is in quotation marks here because the word is sometimes used in very different ways. However, it is important here that only changes on one side of the relationships are used to set "suspect".

A concrete example is the following customer requirement: "The car should have a range of 250 km". Derived system requirement: "The battery has a capacity of at least 50 kWh". If the capacity is now increased to 55 kWh due to an additional consumer, this has no influence on the customer requirement. However, if the range is increased to 300 km, the derived system requirement must be checked and improved if necessary. In this case, the system requirement would be marked as "suspicious".

The two most important use cases for traceability are coverage and change management. [tweetthis]The two most important use cases for traceability are coverage and change management[/tweetthis].

What can the tools do?

Before we look at cross-plant traceability, it is important to ensure that the tools themselves support these use cases. A typical example would be an RE tool and a SysML modeling tool. The majority of professional RE tools support coverage and suspicious relationships. Modeling tools usually have a harder time with these topics, and the cheapest editions often have no, or only very rudimentary, support for coverage and change management. Coverage can usually be realized via corresponding filters, change management is probably also available, but I have not yet been able to test it in practice (e.g.  supports Magicdraw since 18.3 "Suspect Links").

However, the important point is: Before use cases can be realized across tools, they should be solved in the respective tool. However, there is one exception to this rule.

Traceability in a separate tool?

There are also tools that "outsource" traceability. This has two advantages: Firstly, you are suddenly no longer reliant on the tool's capabilities. And secondly, traceability is then realized consistently and independently of the tool. This even makes it possible to include data formats that do not have any traceability at all, such as Word or even PDF. Representatives of this category are Reqtify or SmartFacts. However, the disadvantages are also obvious: the quality of integration plays a major role in day-to-day usability, and this is not adequate with some solutions. For example, in which tool is the traceability created? There is also the question of how exactly changes are recognized and how they are handled.

But to come back to the topic: If you opt for such a solution, you no longer have to worry - in theory - about cross-tool traceability. Of course, the traceability tool must be configured for the individual trace sources, which can be very time-consuming.

In my experience, this solution only makes sense with a very extensive tool landscape and a competent IT department that configures the whole thing and keeps it running.

And now: cross-tool traceability

For cross-tool traceability, there are, as already mentioned, essentially the referencing and synchronization approaches:

At the Referencing only an ID is saved with which the linked element can be found. This can be done manually or automatically. Modern tools often make it possible to reference an element via URL. Inserting the URL by hand is a simple implementation of referencing. It becomes interesting when a version is part of the URL. Without a reference to a specific version, it is difficult to deal with changes.

At the Synchronize the actual information is copied. This means that the information can become outdated and is dangerous without a functioning synchronization mechanism, as it is possible to accidentally work on outdated data.

What is perhaps already clear here: Both approaches solve the same problem in different ways. The dangers are simply slightly different. For example, with both approaches there is a risk of accidentally working with data that is too old - or too current.

However, I do see some advantages to synchronization that are not always easy to achieve with referencing. These include:

• The synchronization is a 1:1 relationshipwhich must be managed between the tools. In principle, this is simpler than a 1:n or n:m relationship.
• During synchronization, data can be in both directions can be moved. For example, a change to a requirement in the SysML tool can be synchronized back into the RE tool. During referencing, the requirement would be referenced in the RE tool and would also have to be changed there. Of course, it should be noted here that unidirectional synchronization is less prone to errors.
• The data is available in both tools for the Analysis in the corresponding tools available.

Conclusion

It is clear from the article that I tend to synchronize - of course only if the tools support this properly. The procedure has also proven itself for me in practice. However, I know enough competent colleagues who shy away from data duplication like the devil shuns water. In this respect, I don't see any great danger as long as the tools can handle it. But I'm also happy to be proven wrong.

Some colleagues shy away from data duplication like the devil shuns water. If the tools can handle it, I don't see a problem. [tweetthis]Some shy away from data duplication like the devil shuns water. I hardly see a problem[/tweetthis].

I recently worked on the data exchange between Jama (requirements) and MagicDraw (SysML) on behalf of Jama Software. So if you want to see a bidirectional synchronization between two tools, you can either use the Watch summary (5 minutes) or the Webinar (55 minutes).