Requirements Traceability Matrix

There are many important documents created during the software testing process such as Test cases, Test scenarios, Test plans, etc. Another one of the very major documents, which at times get neglected, is RTM or “Requirements Traceability Matrix”. 

What is Requirement Traceability Matrix?

Requirements Traceability Matrix is a document that links system requirements with the test cases. It traces the requirements given by the client to the test cases developed to test these requirements. 

Usually, a Business Analyst or a Project Manager writes Software Requirements Specification, Use case, Business Requirements, and/or Project Requirements documents that list all the use cases or requirements of a system and any or all of these documents work as a baseline for Requirements Traceability Matrix. These requirements are matched with test cases written by the testing team. Each requirement/ sub-requirement is matched with the test case written for the related requirement/ sub-requirement. Requirements and test cases may have one-to-many, many-to-one or many-to-many relationships.

Before starting Requirements Traceability Matrix design, requirements documents (SRS, BRS, etc.) and testing documents (test scenarios, test cases) should have correct and unique IDs assigned to them.

Requirements Traceability Matrix is used to make sure that each requirement is covered in the testing process and related test cases have been developed.

Advantages of Requirements Traceability Matrix

As stated in the last section, the main goal of the Requirements Traceability Matrix is to check whether all the requirements given by the client have been tested. Requirements Traceability Matrix provides an assurance to the client and the testing team that all the use cases have been tested.

As Requirements Traceability Matrix can also include the priority of each requirement to be tested, the testing team can easily identify important requirements and manage their testing schedule, this is useful when the project has strict time and/or resource constraints.

Moreover, the Requirements Traceability Matrix also helps in identifying any missing requirements or test cases.

How is Requirement Traceability Matrix created?

The format or structure of the Requirements Traceability Matrix varies from organization to organization. But following are some important parameters which are used while creating Requirements Traceability Matrix-

• Requirement ID – Each requirement in the requirements document is assigned a unique ID. This ID can be further classified into the detailed ID for sub-requirements. For example, any Login module of a system can be a use case that can be given ID as ‘UC 1’. Now, this use case can be divided into sub-requirements for every step such as ‘User enters Username’ step can be given ID as ‘UC 1.1’, ‘User enters Password’ can be given ID as ‘UC 1.2’, and so on.
   
• Requirement Description – Description of the requirement associated with the ID. This is an optional column.
  
  
• Priority – Priority of the requirement to be tested.
  
  
• Test Scenario ID – Based on the requirements, test scenarios will be created. For example, for a login module, ‘User logs in the system’ can be one of the scenarios which can be given ID as ‘TS 1’.
  
  
• Test Scenario Description – Description of the test scenario associated with the ID. This is an optional column.
  
  
• Test Case ID – Based on the requirements and test scenarios, test cases will be developed. For example, in continuation of the above example, for a login module, ‘User enters only alphabets in Username field’ can be one of the test cases and can be given ID as ‘TS1_TC1’.
  
  
• Test Case Description – Description of the test case associated with the ID. This is an optional column.
  
  
• Test Case Development Status – Whether the test case has been developed or not. This can be an optional column.
  
  
• Test Designer – Name of the tester who designed the test case. Again, this is an optional column.
  
  
• Test Execution Environments – Here, this column can have sub-columns to see what all environments test case has been executed.
  
  
• Bug Status – It states whether the test case was passed or not.
  
  
• Bug ID – It is the ID of the bug reported by the testing team. This ID can be linked to the bug tracking tool used by the team.
  
  
• Comment – Any comments by the team members.
  
  

These parameters can be different for each organization, but these are the major and important parameters that give much-needed clarification on traceability.

Usually, this matrix is maintained in an excel sheet.

Types of Traceability Matrix

Traceability matrix can be divided into the following types-

• Forward Traceability – In the ‘Forward Traceability Matrix’, requirements are mapped to the test cases. It helps in making sure that each requirement is included in the testing process. Proper and thorough tracing of requirements is achieved through this type of matrix.
  This type of matrix makes it easy to track whether the right requirements are written for the system and the project is on the right path.
  
  
• Backward Traceability – Backward traceability is also known as reverse traceability. In this type of matrix, test cases are mapped to requirements as opposed to forward traceability where requirements are mapped to test cases.
  It helps in making sure that test cases are developed for each requirement and the developed system is on the right path.
  
  
• Bi-directional (Forward and Backward) Traceability – Bi-directional traceability matrix covers both forward and backward traceability. It makes sure that each requirement has a proper test case written and each test case can be traced back to the correct requirement.
  
  

Conclusion

Requirements Traceability Matrix is a document that traces client requirements with the test scenarios, test cases, and bugs. It helps in achieving 100% test coverage and helps in keeping track of each test case.

Moreover, the Requirements Traceability Matrix document is not only useful for the testing team but also for Business analysts and Project managers, anyone who is responsible for documenting the requirements.