Trace Ability Matrix
Trace Ability Matrix
TABLE OF CONTENT
1.INTRODUCTION 1
1.1 Overview 1
1.1 Overview
Automation requirement in an organization initiates it to go for a 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.
The concept of Traceability Matrix is very important from the Testing perspective. This
chapter discusses about the point where Traceability Matrix gets involved in Testing and the
means of developing it.
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.
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.
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).
Function Design
Requirement Source Code Files Test Cases
Specification Specification
Modification of BRD section LLD section 3.1 Test Case No.: 1 to
Auto Load SCW2FORCE.PRG 10 (Reference:
Process 6.5.8 1099_Reporting_
Test_Record.Doc)
Modification of BRD section LLD section 3.2 Test Case No.: 1 to
Force Balance W2FORCE.PRG 10 (Reference:
Process 6.5.8 1099_Reporting_
Test_Record.Doc
According to the above table, the requirement specifications are clearly spelt out in the
requirement column. 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.
Comment [j1]: code is
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.