5 + 1 Questions a Requirements Traceability Matrix Answers

In the previous part we had a short introduction to requirements traceability and took a look at how to create a requirements traceability matrix. Now it is time to see how we can harness the information it contains and use it to answer five important questions in day-to-day project work.

To have a simple example at hand, we will assume the traceability graph shown in the header image of this article, where we trace from “Customer Requirements” to “Tests”.

From this graph we derive a set of traceability matrices that are kept intentionally simple for this post:

For each link in our trace graph we created a matrix containing the existing artifacts and how they are linked. We also added a fourth matrix that condenses the other three into a single view.

Question #1: Are you building the product correctly?

This is the classic example of forward traceability. Customers or stakeholders usually accept a product only if it fulfils all the requirements that have been specified. With proper traceability in place, you can verify that you have built exactly what has been agreed upon. Use the set of traceability matrices to determine whether each requirement is covered by a test case and to ensure that these tests have been executed successfully.

Sometimes a requirement can only be tested meaningfully by testing its derived development artifacts. The minimalistic approach is to analyse the coverage by following the traces from each requirement to its implementation and from the implementation to the test case that confirms it is working as specified. In the example above, you could follow the trace from “CustReq. 1” → “IntReq. 1” → “Impl. 1” → “Test case 1”.

If all of your requirements are linked to test specifications that are linked to successful tests, your work is done. You have created what has been specified and — more importantly — you are able to prove that it works as intended.

In the example above, however, there is still quite some work to be done: no trace exists from customer requirements 2 and 3 to any test case that confirms their fulfilment.

Question #2: Are you building the right product?

Backward traceability allows you to find validations or development artifacts that are not derived from any requirement. There should be a trace from each test and each development artifact back to a top-level requirement. The rationale is that projects are usually short on time and budget, so it is crucial to assign available resources only to what has been required.

Whenever you find features or other development artifacts in your product that cannot be traced back to a requirement, you either have a visionary on your team who can predict the next feature request — or you are wasting valuable resources. This is especially problematic if agreed-upon requirements are not being worked on.

For example, look at “TestCase 2”: it is linked to “Impl. 2”, which makes sense, however “Impl. 2” is not connected to any internal requirement and thus cannot be traced to any customer requirement. The feature “Impl. 2” has never been requested by a customer. From the perspective of building only what has been specified, this feature is obsolete.

Be aware, though, that not all such findings are “useless”. Your findings might also indicate that your requirements are incomplete — important aspects of the product may have been overlooked or underestimated when engineering the requirements.

Question #3: What is the impact of a change?

In most cases requirements are not set in stone. Sometimes customers change their minds, the market situation changes, or new legislation has to be considered.

No matter the reason, requirements will change over time. And whenever this happens, it raises important questions:

1. How long will it take to implement the change?
2. How expensive will it be?
3. Do I still have the right development resources?

To answer these questions, you first have to find all artifacts related to the changed requirements. Especially in large projects with tens of thousands of requirements and artifacts, it is nearly impossible to take everything into account without a traceability tool.

With a set of requirements traceability matrices, all links from the changed requirements down to the last line of code are captured. Take the example: assume “CustReq. 1” has changed. You can easily derive that this impacts “IntReq. 1” and “IntReq. 3”, both of which are linked to tested implementations. So in total six development artifacts are affected by the change of a single requirement.

While you still need to analyse the impact on each individual artifact, you can be sure that you are always looking at the complete picture.

Question #4: What is the status of the project?

Customers and stakeholders want to be informed on progress — and they won’t settle for “it is coming along fine” without data to back it up. The traceability data contains exactly the information needed to quickly access the current project state. How many requirements are there in total? How many have been implemented and tested successfully? Just iterate along the traces in your RTMs and you will have the answers.

At the current state of the example, “CustReq. 1” is fully implemented and tested, for “CustReq. 2” at least internal requirements have been derived, and “CustReq. 3” has not been touched at all. The RTM provides reliable project status information at any time.

If you save the metrics regularly, it is easy to monitor progress — or lack thereof — over time.

Question #5: What to do next?

One of the challenges in project management is determining when to do what. One important aspect is knowing how different development artifacts are related to each other and which dependencies exist among them. The combination of priority and traceability gives you a thread to follow.

Looking at the example, you can derive the following tasks:

Clarify inconsistencies (backward traceability):

• “Impl. 2” and “Impl. 5” are not linked to any internal requirement. What is their purpose? → Fix it.
• “IntReq. 4” is not linked to any customer requirement. What is its purpose? → Fix it.

Work towards completion according to priorities (forward traceability):

• Create implementation for “IntReq. 2”, then link suitable test cases.
• Create internal requirements for “CustReq. 3”, then link suitable implementation and test cases.

+1: Can you maintain traceability long-term?

This is a tiny example by far not comparable to any real-world project. Still it shows how a simple tool like a requirements traceability matrix maintained in Excel can help you gain a better understanding of complex relationships in your project, distribute work more efficiently, and assess the impact of change with confidence.

But make no mistake: traceability is only of use if it is maintained continuously. It takes effort that dramatically increases with the size of your project. When done with discipline, this effort pays off — as research by Prof. Dr. Mäder shows. Therefore it is crucial to have a tool that makes maintaining traceability as convenient and simple as possible: a traceability tool that scales with your project.

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 →