Requirement Traceability Matrix (RTM)

What is Requirement Traceability Matrix (RTM) ?

Requirement Traceability matrix is a document, usually in the form of a table. It maps each and every requirement stated in Business Requirement Document (BRD) or Software Requirement Specification (SRS) to corresponding design specifications and then to the test procedures.

(Requirement ↔ Design ↔ Test cases)

Thus it “traces” the deliverables by creating a thread for each requirement – right from the beginning of the project till its completion.

As per Wikipedia Requirement Traceability defined as “the ability to describe and follow the life of a requirement in both forwards and backwards direction(i.e, from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)”.

Traceability in general shows the relationship between each product – level requirement and the corresponding down stream work products. For example, a single requirement might trace to one ore more design elements, code units, tests and user documentation topics . However, if you look at RTM in a pure testing point of view, it is more or less like Test Case Coverage checklist . That implies each requirement must be mapped with an associated test case in order to have complete test coverage.

What are the various kinds of Traceabilty Matrix ?Which one is better ?

There are mainly three types of traceability.

  • Forward Traceability

  • Backward Traceability

  • Bi-Directional Traceability

Forward Traceability:

Forward Traceability is tracing each unique requirement forward into the design that implements that requirement, then the code that implements that design and the tests that validate that requirement and so on. The objective is to ensure that each requirement is implemented in the product and that each requirement is thoroughly tested.

Backward Traceability:

It is tracing each unique work product (e.g., design element, code unit, test) back to its associated requirement. Backward traceability can verify that the requirements have been kept current with the design, code, and tests.

Bi-Directional Traceability:

Bi-Directional Traceability allows both forward and backward traceability. Good traceability practices allow bi-directional traceability. Through this approach, we can explain both of these questions such as “Are we building the right product?” and “Are we building the product right?”

How to create a Traceability Matrix?

In order to construct a traceability matrix, we need to have unique identifier for all the requirements and the downstream work products that can be used as reference in the table.Lets look at the sample traceability matrix representation below:

Requirement Traceability Matrix

Requirement Traceability Matrix

BRD – Business Requirement Document ;HLD – High Level Design Document;LLD – Low Level Design Document

In the above table, A specific business rule defined in the Business Requirement Document mapped with corresponding design element in HLD and LLD documents, then to the unit and integration tests (pertaining to the specified requirement) and to the user manual section.This achieves bi-directional traceability by being a single repository for all the documents.

Note:The above described documents such as BRD, HLD, LLD could vary across organisations depending upon the processes defined for the model used in their software development.The one which is represented above is a very basic treaceability template.We can customize it by adding more details and make it more effective.

Modern test management tools such as HPQC (HP Quality Center) having this treaceability as built-in feature and treats as an integral part of the test management activities.Even tools like this provides only partial traceability support.But, if the project is not using any commercial test tools,then we could use a simple Microsoft Excel spreadsheet for RTM.

Who is responsible for creation and maintenance of RTM?

Creation and maintenance of RTM requires cross-functional team of participants such as Business Analysts, Design Engineers, Developers, Testing team etc.

However in some companies this is owned by test team. In this cases test team will be using RTM for Test Coverage Identification and defect tracing.

Why traceability is important ?

Software development standards such as CMMI and ISO 9001:2000 impose requirement traceability on Software Development process.Various research in this area have shown that inadequate traceability is an important factor in contributing to software project failures and budget overruns.As a result of this, many organisations having been striving to improve their traceability practices.There are numerous advantages for this practice.

  • Helps in identifying the costs and risks associated with certain change proposals by analyzing the traceability links in RTM

  • Increases the process visibility to all project participants by understanding where a requirement came from, its importance, implementation and how the same has been tested.

  • Also increases the customer satisfaction and confidence in the project.

  • It helps to determine that the system has been fully validated and verified

Why Software Requirement traceability remains a challenge?

There are numerous challenges that makes it difficult to achieve successful traceability in practice.This includes communication between project stakeholders, cost in terms of time and effort, poor tool support and change management etc.

As software grows in size and complexity, creating and maintaining thousands of interrelated and relatively brittle traceability links becomes expensive.The cost in terms of time and effort is more for the projects implementing RTM verses the projects which doesn’t implement RTM. But the RTM reduce the number of failures by early detection of problems when they are easier and cheaper to correct.In certain cases experts even suggest Value-based requirement tracing(Requirement Prioritization) instead of full tracing.

Managing traceability through change is another significant challenge.This requires the project team to update RTM whenever a new change request comes.This also contributes to more time and effort.As I mentioned in the previous post, creation of RTM usually comes in the first stage of STLC (Exit Criteria of Requirement Gathering phase).However updation of the RTM required throughout the life cycle.

If an organization has clear traceability policies in place and provides training on how to comply with these policies, it is likely that traceability will be implemented in a thorough manner consistent with policy.

A good tool support reduce considerable time and effort overhead with respect to traceability. Multiple studies have found the level of commercial traceability tool adoption is very less throughout industry.This is mainly due to the licensing fees and maintenance fees of these commercial tools.Most of these companies utilize manual methods (such as manually created traceability matrices for implementing traceability), and a small percentage develop their own in-house traceability tools . But most of the times the manual methods are error prone.In larger projects,Most of the times these errors remain undetected .

As a result of these challenges,many organisations struggle to implement and maintain wide and complex traceability links, even though it is broadly recognized as a critical element of the software development life cycle.

I’d be really interested to know how you have done Requirement Traceability Matrix in your project? Which tool you prefer to use?Did you face any other problem which I haven’t covered here ?

Please leave a comment and let me know if this post help you to understand Requirement Traceability Matrix and its importance.