We want to motivate that with traceability you can achieve much more than just to prove the standard compliance of your development process. This article explains what traceability is and how it can help you to survive complex projects.
Literally, traceability is the ability to follow a trace. In software development or systems engineering, a “trace” is the relationship between two development work items, also known as artifacts. In these areas, traceability is the ability to manage relations between artifacts. Artifacts can be, for example, requirements, test cases, elements of the system or software model, a document, part of the code, etc. Common examples of artifacts and their relationships are "a requirement is verified by a test case" or "a requirement is fulfilled by a component".
To make such relations traceable, you simply have to create links between pairs of artifacts. These links are meant to be “semantically directed”. In the examples above, these semantics are expressed by the phrases “is verified by” and “is fulfilled by”. Despite the semantic direction, the links should also be bidirectionally analyzable: For the relation "is verified by", it can be checked in one direction whether a test case exists for a requirement. The justification for a test case can be checked by evaluating the same link in the opposite direction.
The best known way to establish traceability is to define a traceability matrix. A Requirements Traceability Matrix (RTM) is a widely used term and particularly useful for requirements management. Much has been written about RTMs - for example on Wikipedia and here in our blog (with a downloadable example). To show this in practice, I will only use a self-explanatory example of the relationship "is verified by" between requirements and test cases.
Fig.1: A simple example of an traceability matrix (Articles: "Traceability Matrix" wikipedia.org)
Traceability helps you to structure the project data - in the form of semantic relationships between your artifacts.
At first glance, traceability data answers two simple questions:
First question: Which artifacts are linked?
Tracing existing links- either direct links, as shown in the traceability matrix, or even chains of links - is called impact analysis. The impact analysis looks at individual artifacts and their connections. It helps you to answer questions such as "Which parts of the system are affected by a change request?" or "A test fails. Which requirements are not met correctly?".
Second question: Which artifacts are not (yet) linked?
Missing links are an indicator that certain work steps in the project are still open. If a requirement is not linked to a test case, it has probably not been tested - or even not yet implemented. Of course it is also possible that everything is fine and only a link between them is missing. The analysis of link existence is called coverage analysis: A requirement is "covered by a test case" if it is linked - either directly or indirectly - to a test case. The degree of coverage can be a good indicator for your project progress.
Coverage and impact analysis are essentially based on the evaluation of the mere existence (or absence) of links. In particular, the semantics of linking are not taken into account. If these semantics and also the status or other attributes of the artifacts are included in the evaluation, a powerful tool can be created that allows far-reaching evaluations. The following example shall illustrate this potential.
In the section above, we have already hinted at the rough idea that coverage analyses can be used to analyze the progress of a project. This example will be discussed in more detail here:
Let us imagine the following scenario:
On this basis, you can now not only measure the project progress on the requirements level, but also directly calculate the remaining effort. This provides a reliable indicator of whether, for example, the next milestone can be met.
We already learnt that the best decisions are based on the right information - and this indicator is based on your original data and not on assumptions.
The necessary prerequisite for traceability is that artifacts must be clearly identifiable. If this prerequisite is met, a graph with artifacts as nodes and their relationships as edges is created by linking. These connections or links can be used - similar to hyperlinks in the browser - for navigation across tool boundaries. The following image illustrates this. It shows the navigation based on traceability links from C code in an IDE via the model elements in MATLAB Simulink to the requirements in IBM DOORS.
Fig.2: Navigation across tools - in this case from IDE to requirements management tool
The purpose of traceability is to structure projects and thereby gain fact-based insights on the basis of which large and complex projects can be better evaluated and controlled.
The need for this is being driven by the current situation in the field of software development and systems engineering:
In short, the challenge for traceability is to help you manage complex and extensive projects. These advantages go beyond "gaining knowledge from data analysis". An example of such a benefit - cross-tool navigation - was shown above. Here are more examples of such benefits - their implementation is a challenge:
Fig.3: Fast and secure linking with YAKINDU Traceabilities Bulk link creation editor
Traceability helps to structure and analyze your projects data - and this across tools. This is especially useful for heterogeneous tool landscapes. The rapidly increasing project sizes and the sometimes insufficient interoperability of the tools are challenging.