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:
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.
“The expertise in software architectures, the expertise in software development and the very flexible way of working were ideal for us.“
“I have been reading your blog for a long time with great pleasure. Systematically, to the point and appealing.”