There are various definitions for software traceability. However, they have a common ground: Traceability is achieved by linking individual artifacts such as requirements, source code, tests, etc... One of the best definitions for software traceability is the one from Gotel & Finkelstein.
The ability to describe and follow the life of a requirement, in both a forward and backward direction, e.g. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases.
Understanding and describing requirements and their relationships and links – sounds simple, but really is a major challenge. How does these necessary links look like and how can they be achieved?
In the simplest case, the link is achieved by using a 2-dimensional matrix, in which two artifacts are marked as "linked" by setting a cross in a certain column and row. These matrices, often implemented in Excel, are used in many projects. Since Excel is used in most companies, the implementation is very simple, but also involves enormous disadvantages:
To address these issues in larger projects a tool-based traceability is necessary, for example with tools that support the linkage of artifacts. Examples are IBM DOORS and PTC Integrity. These are requirements engineering tools and only able to link requirements. Artifacts like model elements, source code, test cases, etc. must be exported from their original tools first and imported into the requirements engineering tool to be linked. This procedure is complex and has a major drawback: Now the exported artifacts exist twice, namely in the original tool, for example Excel, and as a copy in the requirements engineering tool as well. Since most artifacts are constantly developed further in a project, a redundant data storage requires a regular synchronization which leads to a corresponding and long-termed process and is very cost-intensive. But if the synchronization is not carried out regularly the traceability data quickly does no longer represent the current project status and the traceability management has to be challenged itself.
So not only a tool-based, but also a tool-overarching traceability is necessary: artifacts should not be exported, but remain as originals in their tools and are also linked there. Regular synchronization is eliminated and the traceability data always represents the current project status.
YAKINDU Traceability is such a tool-overarching solution. Using its adapter architecture it can access many tools and the corresponding artifacts which are used in software projects. It supports non-invasive and invasive tracing. Non-invasive tracing means that link information are not stored in the linked artifacts themselves. On the other hand with invasive tracing link information are stored in the referenced artifacts – for example as an information in a comment section of a C file or in cells in an Excel sheet.
Both tracing variants can be used simultaneously. Which tools and artifacts are accessed, is configured individually for each project. YAKINDU Traceability can be adapted optimally to the prevailing tools and processes of the customer - it can be integrated easily into the existing tool chain, not vice versa. We want to ensure that YAKINDU Traceability always supports relevant customer tools. Due to the fact that these are changing very often, we develop the integration possibilities for YAKINDU Traceability further constantly – often while working in projects with our customers.
Of course YAKINDU Traceability offers other advantages for the traceability management, which we are looking forward to present personally.