In this blogpost Iâll tell you what a requirements traceability matrix (RTM) is and how you can create it. If you are new to requirements traceability, here is a short recap to get you started.
This article is part 1 of our series about ârequirements traceabilityâ.
You should also pay attention to:
The term traceability is used in a large variety of different contexts, while this article only considers requirements traceability. It is basically defined as the ability to track each requirement from its origin through the entire development to its validation on each level.
The graphic above shows a very simple representation of a traceability graph on an abstract level. The blue nodes represent different development artifact types. The green nodes are the validations that ensure the quality and proper implementation of the artifact. Direct connections are referred to as links, while link chains are called traces.
The structure and the level of detail that is appropriate for your traceability graph, obviously depends on your product and the process you are following. When developing a website for a local tailor, it looks different as if youâre building safety relevant car parts or medical equipment. However, introducing traceability and using it for analysing your project, is beneficial in any case. Learn more about the benefits of requirements traceability in software projects.
Traceability can be evaluated in different directions. There is forward traceability (e.g. requirement to validation) and backward traceability (validation to requirement). Each direction allows to assess different aspects of the project state and will be most beneficial for different roles in the project team. Clearly the goal is to establish forward and backward traceability, which is consequently referred to as bidirectional traceability. This is where the traceability matrix comes into play.
A requirements traceability matrix (RTM) is a simple and effective tool that allows to establish and maintain bidirectional traceability for your project.
As the name suggests a RTM is nothing more than a table that displays the relation between different development artifacts. Due to its simplicity it can be created with the most basic tool â for example with excel. It sometimes even makes sense to draw it on a white board to make it visible to everyone on the team. Depending on the purpose you are creating the RTM for, it can visualize direct links between âlinkedâ artifacts, shows cumulated views on entire âtracesâ.
Please keep in mind that a requirements traceability matrix can be useful for setting up your project traceability in some cases, but you should be aware of its limits. Read up more on that in our blog article âWhy a requirements traceability matrix is not enoughâ.
Here is a very simple example of a requirements traceability matrix that represents a cumulated view of an entire trace graph from âRequirementâ to âValidationâand can be maintained in any basic spreadsheet tool.
Note that it does not contain the concrete development artifacts, but references them by an unique ID. Although there are good arguments to include more detailed information about the artifacts this would reduce the simplicity and make the information more difficult to access and less easy to comprehend. Traceability is only useful if itâs maintained properly, and itâs only maintained when itâs as simple as possible.
The example represents a compressed representation of the project state. Showing the relations between requirements (Req. 1-15) and validations (Val 1-13), in many to many cardinality. Whenever a requirement is traceable to a validation itâs marked with an âxâ.
In the sense of forward traceability you can see at a glimpse that Req. 10, Req. 11, Req. 13 are not validated properly. When flipping the reading direction (backward traceability) it is obvious that Val. 9 validates no requirement. At this point itâs important to understand that the RTM for its own canât tell you what and why thereâs a problem, but itâs extremely efficient in identifying problems and where to look for them.
In a future article weâll shed some additional light on how to exploit all the information thatâs contained in a RTM, but for now let's concentrate on how establish detailed traceability for an entire project.
There are only three mandatory steps required to establish traceability for your project. If youâre willing to go the extra mile and take a fourth step youâll be able to boost your benefits even further. Letâs get started. Feel free to have a look at the attached example and adapt it to your needs.
First of all you need to find out which types of artifacts are involved in your project. What do you want to keep track of? Whatâs relevant and useful for your team? Whatâs required by the customer or other authorities? Make sure each artifact can be identified by a unique ID later.
For the purpose of this example we chose 4 artifact types Customer Requirements, Internal Requirements, Implementation and Test Cases.
Other examples for artifact types are:
The next step is to define how the artifacts should be linked to each other. You should only consider direct links. The example contains three link types Customer Requirements to Internal Requirements, Internal Requirements to Implementation and Implementation to Test Case.
Other link examples are:
When creating your links make sure that each artifact type can be traced back to a requirement. It often helps to draw a sketch of your traceability graph to visualize it. If you end up with artifacts types that are not (at least transitive) connected to a requirement you either missed a link type or itâs arguably not important for your project at all.
Finally we need to create one traceability matrix for each link type. List one link participant on one axis, the other one on the other. Use the sketch from the previous step to ensure that you did not miss any links. It is a good idea to include a status field for each artifact, to increase the accuracy of the reflected project state. For example it is possible that an artifact is created, but still under development. In the example we flagged such artifacts as not realized.
After we created the entire set of traceability matrices, we are ready to go and have established bidirectional traceability for our project. In order to follow a trace in any direction you have to combine the matrices belonging to that trace just like you would arrange domino stones (see example).
In addition to the possibility to maintain and evaluate direct links, it is possible to use the RTM to create accumulated view for entire traces. To do so, you simply combine the information from multiple matrices into a single one in order to make important information more accessible.
In the attached example you find a combined view, showing the relation from Customer Requirements to Test Case, which immediately reveals that only 47% of the Customer Requirements are covered by a test.
Please feel free to download the example and use it as a template for your own project. If you want to learn more about the benefits of a requirements traceability matrix check our following blog post.