As the name suggests, this matrix is used to track and check whether the current project requirements are met. A document used to co-relate any two-baseline documents, requiring many-to-many relationships, for checking the completeness of that relationship is called a requirements traceability matrix.
Requirements Traceability Matrix (RTM)
A document that captures all the requirements proposed by the client and traces the requirements in a single document by mapping and tracking test cases with user requirements is called a requirements traceability matrix.
Requirements Traceability matrix document is delivered at the end of the Software Development Life Cycle.
The documents’ primary purpose is to verify that all the user requirements are checked using the test cases and that no functionality is unchecked during software testing.
The 100 %test coverage should be the focus of any testing engagement, i.e., everything that needs to be tested should be tested.
Types of Requirements Traceability Matrix
The Requirement Traceability can be broadly classified into three major components. They are:
1. Forward Traceability
This matrix makes sure that every requirement is applied to the product and is tested thoroughly.
It also checks the product’s direction and ensures that it progresses in the desired direction for the right software/product.
The requirements get mapped to the test cases.
2. Backward or Reverse Traceability
This matrix verifies that the testers do not expand the project’s scope by adding code, tests, design elements, or other unnecessary work that isn’t predefined in the user requirements.
It also makes sure that the current product stays on the right track.
The test cases are mapped to the requirements.
3. Bi-directional or Forward and Backward Traceability
It ensures that all the user requirements are covered under all the test cases and analyses the changes in user requirements caused by the defects in a product and vice versa.
Parameters Included in Requirements Traceability Matrix
The testing team developing the Requirements Traceability Matrix can opt for available Test Management Tools apart from maintaining an excel sheet separately.
Three parameters are included in the excel sheet of RTM:
- Requirement ID
- Requirement Type and Description
- Test Cases with Status
Apart from the above, the requirements traceability matrix can also contain:
- The requirement is covered according to the number of test cases.
- User Acceptance Test status, if done by the user.
- Design and execution status for specific test cases.
- Related defects and current state are mentioned.
It wouldn’t be wrong to say, RTM is a One-Stop-Shop for all test activities.
Importance of Requirements Traceability Matrix
User requirement thorough analysis and generating positive and negative test cases should be assured by considering all the possible scenarios or test cases.
So, how can one ensure that no requirement has been left out during testing?
The simplest way will be to trace requirements and their corresponding test cases and test scenarios in a simplified manner.
Every tester must ensure that the product being delivered should be defect-free and fulfill all the user’s requirements.
For achieving this goal, the QA testers should understand the requirements thoroughly and be able to split the requirements into various scenarios and then create test cases on those scenarios.
Once the test cases are done, they need to be executed individually, and success and failure reports should also be generated.
Here, the Requirements Traceability Matrix comes into view.
The matrix is nothing but a typical worksheet containing the user requirements and all possible test scenarios, test cases, and their respective current states of success or failure.
Using RTM, the testing team will better understand and trace the various testing activities that need to be done for the software or product.
Example of Requirements Traceability Matrix
Let us consider an example of a user requirement specification requiring a “Set Reminder” in a Task Manager software.
Thus, the Business Requirement (BR1) will be: Set a Reminder button should be available.
The test scenario (TS1) for the requirement will be: Set Reminder button is provided.
There will be two test cases under this scenario:
- Test Case 1 (TS1.TC1): Set reminder option has been enabled and is working successfully.
- Test Case 2 (TS1.TC2): Set reminder option has been disabled successfully.
Once the above test cases are implemented, they might succeed or fail.
In case of failure, the defects found can also be listed and mapped alongside the business requirement, test scenario, and test cases.
Suppose, TS1.TC1 fails, i.e., the user cannot set a reminder for daily tasks even though the option is enabled. In such a case, the defect can be logged in the Requirement Traceability Matrix.
Suppose the defect ID is D1. Then, this will also be mapped with BR1, TS1, and TS1.TC1.
In a tabular format, the RTM will look somewhat like this:
|Business Requirement||Test Scenario||Test Case||Defects|
Similarly, other rows for other business requirements, BR2, BR3, and others, can be added along with their test cases, test scenarios, and defects mapped.
Test coverage is a term that defines which user requirements are to be tested and verified once the testing starts.
It checks whether the test cases are correctly executed or not, to ensure the software application completeness with minimal or NIL defects.
The 100% test coverage can be achieved by using Requirement Traceability as follows:
The internal defects should be mapped to the test cases designed.
The Customer Reported Defects (CRD) should be mapped to the individual test cases.
Requirement Specification Types
1. Software Requirements Specification Document (SRS)
It is a detailed document containing all the details about the client or stakeholders’ functional and non-functional requirements.
SRS is the baseline document for the design and development of software applications.
2. Use Case Document
The Use Case Document helps in the design and implementation of the software according to business needs.
It shows a detailed workflow of how each task needs to be performed.
The interactions between the system and the user are mapped in the Use Case Document using actors and events needed to be performed to achieve the required goal.
3. Business Requirements
The Business Requirements Document (BRS) is a high-level requirement list that minutely contains the actual customers’ requirements after a brief customer interaction.
A Business Analyst or Project Architect is the one to usually form this document. SRS is derived from BRS.
4. User Stories
In the case of the Agile development method, the user story is used to describe various software features from an end users’ perspective.
These stories simplify the user’s requirements by defining the various types of users and their requirements for what feature and why.
User Stories and Agile development is the new trend in the software industry, and they are shifting towards them and the corresponding software tools required for recording the user requirements.
5. Project Requirement Documents (PRD)
A reference document created for the entire project team telling each member about products’ working is PRD.
There are four sections:
- Purpose of the product
- Product Features
- Release Criteria
- Budgeting & Schedule of the project
6. Defect Verification Document
The testing team maintains a document containing defect-related details for fixing and retesting the defects.
This Defect Verification Document verifies whether the defects have been fixed or not; they are retested on different OS or devices or with different system configurations.
If the project has a reliable defect fixing and verification phase, the Defect Verification Document is essential and useful.
The usefulness of Requirements Traceability Matrix Using an Example
Considering the previous “set notification in task manager software,” let us see how the requirement traceability matrix can help.
Requirement: Implement the “Set Notification” button in the task manager application.
Implementation: Once the user is logged in, the set notification icon should be visible and accessible on the dashboard.
2. Is the requirement necessary?
Requirement: Implement the “Set Notification” button for specific users only.
Implementation: The user can choose whether or not they want to enable notification for their tasks automatically or manually or not at all.
3. Interpreting the requirement
Requirement: “Set Notification” button contains the date and time for the notification to be set.
Implementation: When a user clicks on the Set Notification icon/button, which shall be available?
- Select the task for which a reminder needs to be set.
- Date and time can be set as per the users’ requirements.
4. Design decisions after implementation of the requirement
Requirement: Tasks, delete, edit, new, settings, set notification, should be visible and accessible.
Implementation: All items that need to be visible should be arranged according to the frame in a tabular format.
5. All requirements allocated
Requirement: ‘Mute Notification’ option should be provided.
Implementation: If the ‘Set Notification option is available, then ‘Mute Notification should also be available and work accurately. If the ‘mute notification’ option works correctly, all the set notifications can be easily reset or muted once the tasks are completed or upon users’ requirements.
Advantages of Test Coverage and RTM
- Requirements Traceability Matrix highlights the missing requirements and inconsistencies in the document. The user should get what he asked for without any less or additional functionalities.
- The overall defects, execution, and status are shown from a business requirement perspective.
- 100% test coverage is confirmed.
- The impact of revisiting and re-working the test cases on the QA team’s work is analyzed and estimated using RTM.
- Implementing user requirements as per priority is essential. The top-priority requirements should be implemented first so that the end product can be shipped with top-priority requirements and on Schedule.
- The test plans and test cases are written accurately to verify that all the application requirements are met.
- In the case of a client’s change request, all the related functionalities can be modified accordingly without anything getting overlooked.
Challenges to Test Coverage
In case of any changes requested by the stakeholders, they should be communicated immediately to the development and testing teams during the development and testing cycle’s earlier phases. If delayed, unnecessary time and effort are required, which will delay the project and increase the cost.
Prioritizing Test Scenarios
The test scenarios should be prioritized according to user requirements and delivered as such to avoid any delay. It is impossible to implement all test scenarios, so it must be decided which test scenarios need to be tested and in which order.
Effective Test Strategy
The effective strategy for implementation of Test Coverage is the one that ensures a good quality of the application, which will be maintained over some time
The factors like team skills, organizational structures and processes followed, past experiences, technical infrastructure, implementation, time and resources, project estimations related to cost, and the team’s location according to time zones should be considered while defining the testing process.
In this way, the team can ensure that the process runs smoothly, and every individual in the project remains on the same page.
Availability of Resources
Skilled-domain specific testers and testing tools used by the testers are the two types of resources required to write and implement compelling test scenarios and scripts.
These resources can ensure on-time delivery and adequate implementation of the application for the user.
RTM or Requirement Traceability Matrix is a single document whose primary purpose is to ensure that no test cases and test scenarios are omitted. Every functionality is successfully tested and covered. For this purpose, the client’s requirements are mapped and traced in the document.
The defect count determines the kind of testing that is being done. If the count is high, it signifies a useful quality testing, and a low count indicates inadequate quality testing.
When done thoroughly by planning ahead of time, Test Coverage results in less repetitive tasks and defects in the testing phases resulting in a low defect count.
Thus, software or product is useful if the defect is minimized, and test coverage is maximized.