Requirements traceability - benefits and challenges
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.
What is traceability
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.
What is linked?
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.
What else can we learn from traceability data?
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:
- The requirements are linked to the system that contains the effort estimates for implementation and testing. This could be a project management tool or a bug tracker, for example.
- From the above coverage analysis we already know which requirements are untested. Similarly, coverage analysis can be used to determine which requirements have been implemented.
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.
Which benefits are there besides getting insights from data analyses?
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
Challenges in the field of traceability
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:
- Project complexity grows ... fast!
The main reason for the increasing complexity is that more and more systems are becoming intelligent - and these intelligent systems work together. This means that systems contain more complex software and provide more external interfaces. This observation was already proven in this empirical study in 2013. Since then, the situation has aggravated.
- Project size grows … fast!
The project size (measured by the number of artifacts) is growing. System become not only intelligent, but even autonomous. Deep learning and neural networks require many accompanying artifacts (learning data, test cases). In the automotive industry, projects in the field of autonomous driving are 100 times larger than, for example, projects for intelligent electronic control units.
- Standards are getting increasingly important
Maturity models and similar standards are getting more and more important. They not only help to improve processes - they also help to demonstrate the maturity of the own development process, for example to customers. Certified standards convince customers that one is prepared for the above-mentioned challenges.
Because traceability helps precisely in this respect, it is a mandatory component of fulfilling many of these standards.
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:
- Synchronization of data between different tools
The following scenario illustrates the benefits of synchronization:
Based on traceability data, requirements can be displayed in the modeling tool to link them. The requirements can even be edited in the modeling tool and fed back into the requirements management tool.
- Create a history of your artifacts and their relations.
Based on the traceability data, both comparisons of individual artifacts (for example: requirement 345 had a text change, the delta is <...>) and comparisons of aggregated data are possible (for example: since last week we have 23 new requirements, but the test coverage has increased from 83% to 92%).
- Meaningful reports with drill-down functionality
Drill downs (the navigation from the aggregate to the details) help to master the complexity of the project - immensely. For the above example with the test coverage of 92%, a conceivable drill down would be about:
- Test coverage is 92%.
- List of the number of uncovered requirements per subsystem
- List of requirements not covered for subsystem A
- Support for fast and secure linking of artifacts
In situations where the automated derivation of links is not possible, links must be created manually. The number of links to be generated is large. Based on traceability data, editors can be built that allow the artifacts to be linked quickly and yet consistently.
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.