What is a Traceability Matrix, how is it generated and which areas of application does it support?
Knowledge at a glance: The Traceability Matrix displays relationships between artifacts of the development process in a table. It is generated manually, automatically, or partially automatically.
Display artefacts with their relationships
The Traceability Matrix displays relationships between artefacts of the development process in a table. The ISO/IEC/IEEE24765:2017 defines traceability in the area of system and software engineering as “a distinguishable link between two or more logical entities such as requirements, system elements, verifications and tasks”. Traceability is therefore the ability to understand relationships between artefacts in the development process. The Traceability Matrix is a form of visualisation of relationships.
It could, for example, have the following structure:
The creation of a traceability matrix
There are basically three ways of creating a traceability matrix:
- automated or
- partially automated.
A manually created Traceability Matrix is not desirable for most system and software manufacturers. Those who operate with thousands or tens of thousands of requirements are simply not in a position to document all the relationships between all the artefacts and present them in a Traceability Matrix. The matrix would be too large to understand all contents, dependencies and relationships well and to keep them up to date.
Even the best database-driven tools might have difficulties with an automated creation of the Traceability Matrix to display the amount of information quickly.
The solution for many organisations is therefore: a partially automated Traceability Matrix. As with the automated approach, this requires that all artefacts of the development process are created and managed in a common system, or that the required information is accessed via defined interfaces to other systems. The result, however, is different: it does not show all information with all relationships, but, for example, a specific requirement with its relationships to other requirements, to test cases, to UML or SysML diagrams, etc. The result is that the information is not displayed in a single system. This form is also known as Lean Traceability. It mainly supports four basic analysis steps:
- Impact Analysis looks at which artefacts are affected by changes.
- The origin analysis explains the origin of a requirement.
- The coverage analysis examines the question of whether all artefacts have been considered for a solution.
- And the performance value analysis explains the progress of the implementation.
Here you will find additional information from our Smartpedia section: