Traceability Matrix?

This post  is prepared with the intention of providing an insight into the important concept in the life cycle of Software called Traceability Matrix:

 

Automation requirement in an organization initiates it to go for custom built Software. The client who had ordered for the product specifies his requirements to the development Team and the process of Software Development gets started.

 

In addition to the requirements specified by the client, the development team may also propose various value added suggestions that could be added on to the software. But maintaining a track of all the requirements specified in the requirement document and checking whether all the requirements have been met by the end product is a cumbersome and a laborious process. But if high priority is not provided to this aspect of Software development cycle, it may result in a lot of confusion and arguments between the development team and the client once the product is built.

 

              The remedy for this problem is the Traceability Matrix

 

What is Traceability Matrix?

 Requirements tracing is the process of documenting the links between the user requirements for the system you’re building and the work products developed to implement and verify those requirements. These work products include Software requirements, design specifications, Software code, test plans and other artifacts of the systems development process. Requirements tracing helps the project team to understand which parts of the design and code implement the user’s requirements, and which tests are necessary to verify that the user’s requirements have been implemented correctly.

 

  



 

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.

Benefits of Using Traceability Matrix

• Make obvious to the client that the software is being developed as per the requirements.


• To make sure that all requirements included in the test cases


• To make sure that developers are not creating features that no one has requested


• Easy to identify the missing functionalities.


• If there is a change request for a requirement, then we can easily find out which test cases need to update.


• 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.
 
Disadvantages of Not Using Traceability Matrix [Some Possible (Seen) Impact
 
• Poor or unknown test coverage, more defects found in production 
• It will lead to miss some bugs in earlier test cycles which may arise in later test cycles. Then a lot of discussions arguments with other teams and managers before release.
• Difficult project planning and tracking, misunderstandings between different teams over project dependencies, delays, etc

Steps to Create Traceability Matrix

1. Make use of excel to create Traceability Matrix:

2. Define following columns:
Base Specification/Requirement ID (If any)
Requirement ID
Requirement description

TC 001 TC 002 TC 003... So on.

3. Identify all the testable requirements in granular level from requirement document. Typical requirements you need to capture are as follows:

Used cases (all the flows are captured)

Error Messages

Business rules

Functional rules

SRS

FRS

So on…

4. Identity all the test scenarios and test flows.
5. Map Requirement IDs to the test cases. Assume (as per below table), Test case “TC 001” is your one flow/scenario. Now in this scenario, Requirements SR-1.1 and SR-1.2 are covered. So mark “x” for these requirements.

Now from below table you can conclude –

Requirement SR-1.1 is covered in TC 001 Requirement SR-1.2 is covered in TC 001

Requirement SR-1.5 is covered in TC 001, TC 003 [Now it is easy to identify, which test cases need to be updated if there is any change request].
TC 001 Covers SR-1.1, SR, 1.2 [we can easily identify that test cases covers which requirements].
TC 002 covers SR-1.3.. So on..

This is a very basic traceability matrix format. You can add more following columns and make it more effective:

ID, Assoc ID, Technical Assumption(s) and/or Customer Need(s), Functional Requirement, Status, Architectural/Design Document, Technical Specification, System Component(s), Software Module(s), Test Case Number, Tested In, Implemented In, Verification, Additional Comments,