The biggest challenge in the field of traceability is to
find a suitable approach for your project. The main driver is the complexity of your project(s), i.e. the number of artifacts, traceability links, artifact types, and link types.
As a rule of thumb (and completely ignoring other aspects such as reporting, which are considered below), we have the following:
| project complexity [no. of artifacts] | Traceability approach |
|---|---|
| ~ 150 | conventions, brains |
| ~ 1,500 | requirements traceability matrix |
| ~ 150,000 | tool-based approach |
| ~ 1,150,000 | custom solution |
For small projects, traceability can be implemented by naming conventions (e.g. test case TC-72 verifies use case UC-72).
With rising project complexity, you may want to utilize a spreadsheet tool to manage your traceability data – most likely in the form of a requirements traceability matrix (RTM). An RTM is said to be
one of the most valuable things people almost never do.
If your project is too complex for manual approaches you should consider a professional tool to manage your traceability data. Such tools bridge traceability gaps even across engineering tools and support e.g. traces from a requirements management tool via a modeling tool to test benches, software repositories, etc. This covers not only data analysis but also navigation across tools. You may e.g. navigate from a model element (in a modeling tool) to the belonging software unit (in an IDE). Technically, these tools are often based on manual data exchange (i.e. im- and exports) or by generic data crawlers or extractors. In either case, the challenge here is to synchronize data that resides in different sources. An aggravating aspect is the conflictual relation of concurrent changes and data synchronization – imagine a tester who just specified a test for a requirement which in parallel had been changed.
If it happens that even a generic off-the-shelf tool cannot cope with your project’s complexity, you might consider building a custom solution. This is e.g. the case for complex systems engineering projects, e.g. in the field of autonomous driving with tens of millions of artifacts.
If you want to track the history of your artifacts and their relations, you can even get more insights – e.g. from an automated project progress report. In this case, you need to set up a data storage that supports these temporal aspects.
Another key challenge – especially if your projects are big – is to set a meaningful reporting both on a high level and on a detail level. Imagine a project progress metric that does not look well: Not only should the project lead be able to figure out the actual bottlenecks – i.e. the affected parts/components of your project, but also the responsible engineer should get information about the actual reasons – e.g. which test cases are failing.
The level of tool integration is another success factor for traceability. If your tools are integrated well, a developer may e.g. have access to the requirements specification from inside his IDE.
We just named the important challenges in the field of traceability. At itemis, our challenge and our aspiration are to provide the maximum benefits of traceability for you – either in the
form of
itemis ANALYZE or a custom solution.