Requirement traceability matrix constructing

Requirement Traceability Matrix is ​​a document that displays and tracks user requirements using test cases. It captures all the requirements proposed by the client and enables requirements tracking in a single document that is delivered at the end of the software development life cycle. The main purpose of the requirements compliance matrix is ​​to confirm that all requirements are verified using test cases so that each functionality is tested during software testing.

What are the requirements compliance matrices built for?

Each tester must understand the client's requirements and be convinced that the output product must be defect-free. For this, you need to be able to create positive and negative tests well.

This would mean that the software requirements provided by the client should be further broken down into different scenarios and further converted into test cases. Each of these cases must be considered individually. This begs the question, how do you ensure that the requirement is tested against all possible scenarios/cases? How do you ensure that no requirement is left out of the test cycle?

A simple way is to trace the requirement with its corresponding test scenarios and test cases. This method is called the «Requirement Compliance Matrix».

A compliance matrix contains requirements with all possible test scenarios and cases and their current state. This helps the testing team understand the level of testing of a particular product.

What parameters should be included in the compliance matrix?

1. Requirement ID.
2. Type and description of the requirement.
3. Test cases with status.

Above is a simplified example of a requirements compliance matrix.

But in a typical software testing project, the matrix will have more parameters.

As shown above, a requirements compliance matrix can:

• show coverage of requirements in the number of tests;
• show the design status, as well as the execution status for a specific test;
• if users have to perform any acceptance test, then the UAT status can also be recorded in the same matrix;
• relevant defects and current status may also be mentioned.

Such a matrix will provide a «single window» for all types of testing.

In addition to using an Excel spreadsheet, the testing team can also choose available test management tools to track requirements.

Types of requirements matrices

In software development, matrices can be divided into three main components:

1. Forward traceability: this matrix is ​​used to check whether the project is moving in the desired direction. Ensures that each requirement is applied to the product and thoroughly tested. The matrix displays the requirements for the test cases.
2. Backward or reverse traceability: used to ensure that the current product remains on track. The purpose of this type of tracking is to ensure that we do not expand the scope of the project by adding code, design elements, testing, or other work that is not specified in the requirements. This matrix maps test cases to requirements.
3. Bi-directional traceability (Forward+Backward): This matrix ensures that all requirements are covered by test cases, and analyzes the impact of changing requirements that are affected by a defect in the working product, and vice versa.

How to make a compliance matrix

Let's have a look at a simple example of creating a requirements compliance matrix.

Based on the Business Requirement Document (BRD) and Technical Requirement Document (TRD), testers create test cases.

For example, a business requirement:

B1 – The customer should be able to log in to the website with the correct password and user ID, while the manager should be able to log in to the website via the customer's login page.

The Technical Requirements Document (TRD) states the following:

T22 – The «UserID» field must not be empty.

T23 – The «Password» field must not be empty.

T24 – The user is successfully logged in if valid data is entered in the «UserID» and «Password» fields.

Step 1. We create a test case.

Step 2. Define the technical requirement (TR) that this test checks. For our test case, the technical requirement T24 is checked.

Step 3. Define the Business Requirements (BR) for this technical requirement. In our case, it is B1.

Step 4. We add information about technical and business requirements to our test case.

Step 5. Perform the following actions for all test cases. Thus, the data from the first three columns will be the matrix of compliance with the requirements.

The above document establishes the tracing between BR, TR, and test scenarios. By creating a document like this, we make sure that all aspects of the initial requirements have been taken into account by the testing team to create their test suites.

Generally, any empty spaces in the matrix are potential areas for exploration.

The advantage of the compliance matrix

• confirms 100% test coverage;
• highlights any missing requirements or document inconsistencies;
• shows common defects or performance status with an emphasis on business requirements;
• helps analyze or evaluate the impact on the QA team's work of revising or reworking test cases.

It is worth mentioning that the way the compliance matrix is ​​maintained and updated determines the effectiveness of its use. If a tool is not updated frequently or updated incorrectly, then it becomes a burden rather than a tool.