Traceability Matrix – A project savior

It has been a concern in IT industry that requirements used to change quite often. Some time, it is even hectic to map all requirements accordingly. For larger projects, a requirement changes/evolves in every new phase.  For developers and QA engineers, each and every requirement matters a lot as business may suffer due to any of missing requirement. Even if all requirements are implements, it is necessary to test all of these requirements and in agile, requirements can slip very easily on peak working days.

Solution?

Requirement Traceability Matrix provides this facility to keep all of the requirements on the track.  This document is used to check that either all of requirements have met or not? In whole development life cycle, this document is important to trace requirements. For each requirement, test cases are written and traced accordingly.

Types of Traceability : 

1. Forward traceability: This is traceability from requirements to test cases. This is actually depicting the overall progress of the project or a product. We can also check test case coverage very easily via forward traceability.

2. Backward traceability: From written test cases, this is traceability to requirements. It helps us to define our scope that we are currently in our scope and scope is baseline.

3. Bi Directional traceability: This is traceability from test cases to requirements and from requirements to test cases. This is basically for verification of the documents. For all type to missing requirement and missing test cases, we can use this tractability to overcome this issue in a single run.

Parameters for Requirement traceability matrix:

There are different parameters of a traceability matrix depending upon nature of the project. But here are some high level parameters that can be included in this matrix.

1. Requirement ID
2. Risks
3. Requirement Type and Description
4. Trace to design specification
5. Unit test cases
6. Integration test cases
7. System test cases
8. User acceptance test cases
9. Trace to test script - automation

Working Flow:

Working flow is very simple. For each requirement, ideally there should be a test scenario. For example there is a requirement related to login flow. Then we write a Requirement ID in front of this updated requirement. Then we populate other parameters. There might be different approaches to map with test cases but I would like to suggest a separate sheet or document. In this separate test case document, we can populate test scenario and test cases accordingly. For each test case scenario, we can map respective Requirement ID. Similarly, respective test scenario ID can be written in front of Requirement ID.

This will help all stake holders to clear missing requirements if any. Similarly, developers can estimate their tasks more effectively and QA engineers will validate all requirements with test cases. Managers will get a high level view of ongoing process very easily.

Happy working in the agile way