5 reasons why a requirements traceability matrix is not enough

Information: YAKINDU Traceability Is Now itemis ANALYZE

In order to satisfy a project’s quality management, many organizations require to have traceability measures in place. Whether you have already come across this approach in your projects or are planning to get started on this: The most popular approach for many projects is quite likely the use of a requirements traceability matrix (RTM). Its purpose is to track the product requirements from conception to delivery by validating that all requirements are linked to downstream work artifacts. In our blog article “How to create an RTM”, we have illustrated this approach.

However, looking at the large amount of information that has to be included in a requirements traceability matrix, it’s no surprise that many project managers experience that their teams are struggling to maintain the RTM over the course of a project. Especially in large projects with various tools and work artifacts, it seems quite cumbersome to maintain the requirements traceability matrix.

In addition, the RTM is not an end in itself. And while it is becoming more and more time-consuming to protect a complex RTM from becoming obsolete, it is also becoming more demanding to maintain the complex implementation according to the requirements.

In this article, we want to dive deeper into the real efforts behind maintaining an RTM and raise possible alternatives.

Requirements traceability – a curse or a blessing?

The aspiration to implement requirements traceability grows out of various reasons such as need for certification, demand of customers, or simply out of a legal requirement.

However, all these efforts will often lead to numerous advantages for the software development project, above all: increased quality.

Requirements traceability is supposed to assist you with managing and controlling progress and evolution of your project. In order to understand the origins of a requirement and to determine how a requirement has been materialized in specific artifacts in, e.g., design, code, or test cases, it is necessary to follow its lifecycle in both forward and backward direction.

Developers are required to show not only that each requirement is fully and correctly implemented, but also that no additional and untraceable code exists, which does not fulfill any requirement.

Various standards in different industries dictate traceability, such as

• ISO-26262 for automotive,
• DO-178 for aviation,
• IEC-62061 for safety of machinery,
• EN-50128 for railway and SPICE.

Although traceability is required by law in most safety-critical software projects and often is even a core part of company initiatives to improve project efficiency and tooling methods, implementing it cost-efficiently is a well-known and common struggle.

While a requirements traceability matrix seems to be a low-cost traceability approach and is relatively easy to set up initially, many users later find that it is hardly sustainable over the course of the project.

Why a requirements traceability matrix is not enough

The perception is that the effort required to maintain a “just-enough” RTM is excessive in comparison to its benefits. Therefore, despite its usefulness in some cases, many organizations fail to implement traceability practices effectively this way. We are going to discuss now various explanations of why manual requirements traceability methods fall short.

1. Manual requirements traceability methods are limited as you integrate more tools
   

   There might be a multitude of tools within your project. For example, there is everyone's individual preference to work with their favorite tool. Or there is a specific tool that is best suited for a specific application or use case. Scenarios like this will always be part of project reality.

   But especially if a product has a lot of requirements, hierarchical connections, or artifacts linked across multiple different tools, the use of a requirements traceability matrix becomes limited very quickly.

   It is possible to trace information in other tools by means of unique identifiers, but you will not be able to navigate or recognize any additions, changes, or deletions.

   Keeping your traceability synchronized will remain a manual task. Even with only 100 work items this already becomes painful.

2. Manual requirements traceability methods are labor-intensive and error-prone

   The manual work necessary to construct, maintain and analyze trace links creates so much overhead to the change process itself, that each changing requirement will make it increasingly tough to keep implementation, documentation, as well as architectural and design documents, as well as everything else synchronized.

   Also, your team members will not be able to work on a requirements traceability matrix simultaneously. Instead, they will have to integrate fragmented data manually, a procedure that will quite likely lead to incorrect data.

   Abstract Link Derivation

   Many organizations investing in traceability processes tend to create basic links between different types of artifacts. Tracing at a low level of granularity supports a much more precise form of traceability, but it can lead to an excessive amount of work.

   A tool-assisted way of handling traceability data seems to be a much easier way. In our blog article “Automated link derivation”, we explain which ways exist to create and maintain traces deep down in the traceability hierarchy.

3. A requirements traceability matrix doesn’t scale or age well

   Many RTMs that have been created with enthusiasm and hard work during early phases of the product development lifecycle, slowly deteriorate and become inaccurate as the system grows and changes over the course of months and years.

   To make matters worse, it is not uncommon that certain traces are created unnecessarily and that it is almost impossible to accurately maintain and understand them.

   Regardless, traceability has to be established in projects of all sizes, and you don’t always have a choice. With growing project size, traceability efforts increase, and manual traceability practices scale poorly.

4. It is time-consuming to make sense of the information

   Finding just those pieces of information in an RTM which are relevant for the next development phase, proves to be a real problem. How much better would it be to find all such information quickly in an aggregated view or dashboard, so that you could focus on your deliverables?

5. Manual requirements traceability methods do not fit an agile team

   With companies becoming more and more agile, they are adjusting to increasingly shorter innovation and production cycles. In an agile environment, it is important to be able to react flexibly to frequently changing conditions, constraints and requirements.

   It’s absolutely necessary to aggregate your traceability data, but with a requirements traceability matrix you will never be able to manually keep up with ever-changing user stories. We have gone more into detail on this in our blog post “Establishing traceability in agile projects”.

Traceability with a dedicated tool

A traceability tool would not only automatize all that manual work, it would also open the door to further advantages, like compliance verification, impact analysis, or requirements validation. These benefits would be next to impossible without higher levels of tool assistance.

Most importantly, the base for a reliable and trusted traceability analysis is consistent trace data, collected from all tools and sources within your project, producing a true reflection of the development lifecycle.

Information is stored in a way that it can be accessed from anywhere, making it a real asset of your development project. With a holistic process in place, control over your project, quality, and stakeholder acceptance will rise.

Information: YAKINDU Traceability Is Now itemis ANALYZE