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 scope, requirements, and deliverables remain “as is” when compared to the baseline.
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?
- to ensure that all requirements that are defined for a system, are tested in Test Protocols
- 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.
Requirements Traceability Matrix Formats
There are two ways to format/view a requirements Traceability Matrix
- 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
http://www.ofnisystems.com/services/validation/traceability-matrix/
https://project-management.com/requirements-traceability-matrix-rtm/
http://modernrec.wpengine.com/creating-horizontal-traceability-matrix/
https://www.softwaretestingmaterial.com/requirements-traceability-matrix/
http://softwaretestingfundamentals.com/test-case/
https://economictimes.indiatimes.com/definition/requirement-traceability-matrix
https://www.educba.com/defect-life-cycle/
https://www.guru99.com/regression-testing.html
http://www.qualitytesting.info/forum/topics/what-is-forward-and-reverse-traceability-matrix
https://en.wikipedia.org/wiki/Gold_plating_(software_engineering)
https://sqa.stackexchange.com/questions/15845/what-is-bi-directional-traceability-matrix/16023
https://www.guru99.com/traceability-matrix.html
http://www.softwaretestingclass.com/test-coverage-in-software-testing/
https://www.seguetech.com/traceability-can-help-track-quality-software-development/
https://reqtest.com/testing-blog/5-key-benefits-of-using-a-traceability-matrix-to-stay-on-top-and-in- control-of-your-project/
Author: Bob Savelson
Time to Read: 10 minutes
Related Articles
Request a Demo!
- Schedule a demo with one of our trained product experts.
- Receive a personalized demo that mimics your team's process
- Engage our experts on topics such as workflow or best practices.
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
