Skip to content

Using a Requirement Traceability Matrix to Improve Project Quality

The Requirement Traceability Matrix (RTM) is a planning tool to help ensure that a project’s scoperequirements, and deliverables remain “as is” when compared to the baseline.

Requirements Management Tools for the Services and Technology Industry
Traceability 1

What Is a Requirement Traceability Matrix?

It is a process of documenting the connection and relationships between the initial requirements of the product with the final product/service produced. The RTM traces the deliverables by establishing a thread for each requirement, from a project’s initiation to completion.
The Traceability Matrix is often used to:

  • Track requirements: are the original business objectives being met by the current process and design?
    1. to ensure that all requirements that are defined for a system, are tested in Test Protocols
    2. to help auditors in reviewing the validation documentation
  • Assist in creation of an RFP (request for proposal), project plan tasks, deliverable documents, and test scripts.
  • Form the basis of a projects SCOPE, by incorporating specific requirements and deliverables that will be produced.
Traceability 2

Requirements Traceability Matrix Formats

There are two ways to format/view a requirements Traceability Matrix

  1. Intersecting Matrix. The simple and most common of the Traceability matrices is a cross- reference chart between Test Cases (represented by test case Id’s) and Requirements (represented by Requirement ID’s), also known as the Intersecting Traceability Matrix.

2. You can also view your requirements in a horizontal matrix. This matrix maps Test cases with Requirements in a linear format and allows for easy identification of linked requirements by finding the specific Test Case.

What is a Test Case?

A test case is described as a set of conditions or variables that is believed to satisfy a set of linked requirements. The creation of multiple test cases can help identify errors and flaws in the designated requirements or the entirety of an application.

Test Suite ID

The ID of the test suite to which this test case belongs.

Test Case ID

The ID of the test case.

Test Case Summary

The summary / objective of the test case.

Related Requirement

The ID of the requirement this test case relates/traces to.

Prerequisites

Any prerequisites or preconditions that must be fulfilled prior to executing the test.

Test Procedure

Step-by-step procedure to execute the test.

Test Data

The test data, or links to the test data, that are to be used while conducting the test.

Expected Result

The expected result of the test.

Actual Result

The actual result of the test; to be filled after executing the test.

Status

Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not performed and ‘Blocked’ if testing is blocked.

Remarks

Any comments on the test case or test execution.

Created By

The name of the author of the test case.

Date of Creation

The date of creation of the test case.

Executed By

The name of the person who executed the test.

Date of Execution

The date of execution of the test.

Test Environment

The environment (Hardware/Software/Network) in which the test was executed.

Types of Traceability

Forward Traceability allows you to map requirements to test cases while ensuring that the desired project is progressing in the desired direction. In other words, forward traceability allows you to trace each project requirement forward into the design implemented by requirements, the code implemented by the design, and the tests that help with the validation of the project. This allows us to understand that we are building the right product. In forward traceability, each requirement is thoroughly tested with respect to test parameters and protocols.

Reverse Traceability allows you to map Test Cases to Requirements. Reversing the mapping of the two factors also allows you to ensure that your

project progress is being made in the right direction, and whether the final product has met the designated requirements or not. In today’s development phases, our end result is always changing and evolving to meet changing criteria. Reverse traceability helps ensure that the evolving product still satisfies the original requirements without expanding the scope of the project (adding code, design elements, and tests).

Reverse Traceability helps prevent “gold plating” – a term that describes a scenario where the marginal effort of changing a product is greater than the marginal value. This type of error occurs when a project manager or developer focuses on additional development of a product past the designated requirements, without realizing that the added value is less or can lower the overall value of the project. Any addition of code, design elements, and tests, increases the scope of the project and causes gold plating.

Bi-Directional Traceability describes the ability to combine forward and reverse traceability through a development life cycle. This type of traceability helps determine that all initial requirements have been met, that these requirements can be validated, and if there is a change, it analyzes the impact of the change in requirements.

A Matrix is considered to be bi-directional when it:

  • tracks the requirement “forward” by examining the output of deliverables
  • looks at the business requirement that was specified for a particular feature of product “backward”

Benefits of Using RTM

RTM is initially a planning tool that highlights any missing requirements or documentation inconsistencies, and when test cases are developed (validation begins), helps to determine scope of regression testing. Regression Testing is a type of software testing that ensures that previously developed and tested software still perform the same way after it is changed or interfaced with other software. (to confirm that change in Variable B has not negatively affected existing Variable A)

It also confirms 100% Test coverage, which is a measure of the proportion of the project exercised during testing. Test coverage gives us an objective score of a test case which, when below 100% coverage, is an inaccurate measure of identifying errors. Test coverage is basically a quality check on test cases, and we can increase our test coverage by creating additional useful test cases and omit unnecessary test cases.

RTM can help determine number of tests required, types of tests required, and whether these tests can be automated, done manually, or re-used. Once we figure these factors out, we can yield the best possible test case and help provide the overall defect status through logs of defects.

An RTM is also helpful in providing visual progression to ensure that no functions/requirements are missed when testing.

Lastly, RTM can help estimate the impact of reworking test cases, conducted by a QA team.

Validation

Once a project requirement has been identified and approved, it undergoes a validation and testing process to determine whether the initial requirements are satisfied. The validation process of requirements traceability has a huge impact on identifying defects. If a test case fails to satisfy a requirement, it is considered a defect, and needs to be fixed. After identification of a defect, it is then recommended to pinpoint the impact of the specific defect and address the impact so that the project continues to align with the initial requirements. The defect identifying process can be time consuming and tedious without automation from a requirements traceability matrix, as a matrix allows you to identify which tests need to be rerun.

An RTM is also helpful in providing visual progression to ensure that no functions/requirements are missed when testing.

Lastly, RTM can help estimate the impact of reworking test cases, conducted by a QA team.

Sources

Request a Demo!

Reduce UAT Efforts

50% Reduction in UAT efforts

Proven Time Saving

80% time saving on creating Trace Analysis

Streamline Approvals

Significant reduction in approval delays

Increase Performance

50% requirements productivity improvement

Reduce Rework

10-fold reduction in development rework

Simplify Compliance

40% reduction in compliance reporting efforts

Wait! Before you go:

Want to see how ModernRequirements4DevOps works?

We’ll give you a quick Demo!