Requirements Traceability Matrix-Software Testing

Disadvantages of not using Traceability Matrix
What happens if the Traceability factor is not considered while developing the software?
a) The system that is built may not have the necessary functionality to meet the customers and users needs and expectations
b) If there are modifications in the design specifications, there is no means of tracking the changes
c) If there is no mapping of test cases to the requirements, it may result in missing a major defect in the system
d) The completed system may have “Extra” functionality that may have not been specified in the design specification , resulting in wastage of manpower, time and effort.
e) If the code component that constitutes the customer’s high priority requirements is not known, then the areas that need to be worked first may not be known thereby decreasing the chances of shipping a useful product on schedule
f) A seemingly simple request might involve changes to several parts of the system and if proper Traceability process is not followed, the evaluation of the work that may be needed to satisfy the request may not be correctly evaluated

Where can a Traceability Matrix be used?
Is the Traceability Matrix applicable only for big projects?
The Traceability Matrix is an essential part of any Software development process, and hence irrespective of the size of the project, whenever there is a requirement to build a Software this concept comes into focus.
The biggest advantage of Traceability Matrix is backward and forward traceability. (i.e) At any point of time in the development life cycle the status of the project and the modules that have been tested could be easily determined thereby reducing the possibility of speculations about the status of the project.

Developing a Traceability Matrix
How is the Traceability Matrix developed?

In the diagram, based on the requirements the design is carried out and based on the design, the codes are developed. Finally, based on these the tests are created. At any point of time , there is always the provision for checking which test case was developed for which design and for which requirement that design was carried out. Such a kind of Traceability in the form of a matrix is the Traceability Matrix.

In the design document, if there is a Design description A, which can be traced back to the Requirement Specification A, implying that the design A takes care of Requirement A. Similarly in the test plan, Test Case A takes care of testing the Design A, which in turn takes care of Requirement A and so on.

There has to be references from Design document back to Requirement document, from Test plan back to Design document and so on.

Usually Unit test cases will have Traceability to Design Specification and System test cases /Acceptance Test cases will have Traceability to Requirement Specification. This helps to ensure that no requirement is left uncovered (either un-designed / un-tested).

Requirements Traceability enhances project control and quality. It is a process of documenting the links between user requirements for a system and the work products developed to implement and verify those requirements. It is a technique to support an objective of requirements management, to make certain that the application will meet end-users needs.

Traceability Matrix in testing
Where exactly does the Traceability Matrix gets involved in the broader picture of Testing?
The Traceability Matrix is created even before any test cases are written, because it is a complete list indicating what has to be tested. Sometimes there is one test case for each requirement or several requirements can be validated by one test scenario. This purely depends on the kind of application that is available for testing.
Creating a Traceability Matrix
Traceability Matrix gives a cross-reference between a test case document and the Functional/design specification document. This document helps to identify, if the Test case document contains tests for all the identified unit functions from the design specification. From this matrix we can collect the percentage of test coverage taking into account the percentage of functionalities to the total tested and not tested.

According to the above table, the requirement specifications are clearly spelt out in the requirementcolumn. The functional specification notified as BRD section 6.5.8 tells about the requirement that has been specified in the Requirement document (i.e it tells about the requirement to which a test case is designed). With the help of the Design Specification, it is possible to drill down to the level of identifying the Low Level Design for the Requirement specified.
Based on the requirements, code is developed. At any point of time, the program corresponding to a particular requirement could be easily traced back. The test cases corresponding to the requirements are available in the Test Case column.