How to Create a Requirements Traceability Matrix

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.

Traceability is used in a wide variety of contexts. In software engineering, requirements traceability is 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 simple representation of a traceability graph. 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 called links; chains of links are called traces.

The structure and level of detail appropriate for your traceability graph depends on your product and your process. When developing a website for a local tailor it looks different than when building safety-relevant car parts or medical equipment. Introducing traceability and using it to analyse your project is beneficial in any case.

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 you to assess different aspects of the project state. The goal is to establish both directions — bidirectional traceability — which is exactly what the traceability matrix enables.

What is a requirements traceability matrix?

A requirements traceability matrix (RTM) is a simple and effective tool that allows you to establish and maintain bidirectional traceability for your project.

As the name suggests, an 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 Excel. It sometimes even makes sense to draw it on a whiteboard to make it visible to everyone on the team.

Please keep in mind that an RTM can be useful for setting up project traceability, but you should be aware of its limits. There is a good reason why a traceability matrix is often not enough for complex projects.

Here is a simple example of an RTM showing a cumulated view of an entire trace from “Requirement” to “Validation”:

Note that it does not contain the concrete development artifacts, but references them by a unique ID. Although there are good arguments to include more detailed information about the artifacts, this would reduce simplicity and make the information harder to access and comprehend. Traceability is only useful if it is maintained properly, and it is only maintained when it is as simple as possible.

The example shows the relations between requirements (Req. 1–15) and validations (Val. 1–13) in a many-to-many cardinality. Whenever a requirement is traceable to a validation, it is marked with an “x”.

In the sense of forward traceability you can see at a glance 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. The RTM alone cannot tell you why there is a problem, but it is extremely efficient at identifying problems and pointing you to where to look for them.

How to create a traceability matrix

There are three mandatory steps to establish traceability for your project, plus an optional fourth step that boosts your benefits further.

Step 1: Identify your artifact types

Find out which types of artifacts are involved in your project. What do you want to keep track of? What is relevant and useful for your team? What is required by the customer or other authorities? Make sure each artifact can be identified by a unique ID.

For the purpose of this example we chose four artifact types: Customer Requirements, Internal Requirements, Implementation and Test Cases.

Other examples for artifact types are:

• Requirements (system, hardware, legal)
• UI design documents (paper prototypes, mock-ups, style guides, mood boards)
• Software architecture (component diagrams, statecharts, class diagrams)
• Implementation (interfaces, protocols)
• Tests (unit tests, manual tests)

Step 2: Define the relations between those artifacts

Define how the artifacts should be linked to each other — consider only direct links. The example contains three link types: Customer Requirements → Internal Requirements, Internal Requirements → Implementation and Implementation → Test Case.

Other common link types are:

• Customer requirement ↔ System requirement
• Software requirement ↔ Software architecture
• Software detailed design ↔ Implementation (code)
• Implementation (code) ↔ Unit test

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 first. If you end up with artifact types that are not (at least transitively) connected to a requirement, you have either missed a link type or that artifact type is arguably not important for your project.

Step 3: Create a traceability matrix for each link

Create one traceability matrix for each link type. List one link participant on one axis and the other on the other axis. Use the sketch from Step 2 to ensure you have not missed 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, an artifact may have been created but is still under development — in the example we flagged such artifacts as not realized.

After completing the full set of traceability matrices you have established bidirectional traceability for your project. To follow a trace in any direction you combine the matrices belonging to that trace, just like arranging dominoes.

Step 4 (optional): Create accumulated metrics

In addition to maintaining and evaluating direct links, you can use the RTM to create an accumulated view for entire traces. Simply combine the information from multiple matrices into a single one to make important information more accessible.

The combined view in the example shows the relation from Customer Requirements to Test Case, which immediately reveals that only 47% of customer requirements are covered by a test.

If you want to learn more about the benefits of a requirements traceability matrix, check out our follow-up article on the 5 + 1 questions an RTM answers.

Requirements traceability in practice — How end-to-end traceability works in regulated projects, which tools have proven themselves, and when the RTM approach reaches its limits: Requirements Traceability at itemis →