Traceability Matrix

Traceability Matrix
A traceability matrix is a powerful tool. It can be of use to many regardless of the audience. It Clears confusion , settle disputes, shows coverage of requirements in specs, code, tests, etc. , it exposes gaps
shows real project progress, is a great tool in managing change, used to assist with project management
used to establish design/development/test priorities, used to identify risk areas, used to determine what if any 3rd party technologies are needed, used to determine tools needed for design, development and testing, etc.

NOTES!
This is just an illustration in an MS-Word document. Ideally one would assemble such a matrix in a spreadsheet or database to allow for querying. Custom views can be created to show only those columns that fit the specific needs of the user.
Simply stated - as in real life application of such a matrix, the white space represents work to be completed.
Examples within are at varying levels of requirement decomposition. This is intentional. It shows the need for more work - decomposition. It also demonstrates a common challenge to test engineering. The challenge is that some of the requirements are untestable. Ideally, those requirements would be decomposed to a state of testability.
Columns can be modified, added, or deleted/hidden to fit specific purposes.
Following ten columns will be the in Traceability matrix.
1.Requirement ID( the Requirement id provided in the SRS
document)
2.Requirements (Requirement Descrition)
3.High Level Design (document reference)
4.Implementation Design(implemented or not)
5.Source Code (Component/class Program Name)
6.User Documentation(preparation)
7.Unit Test Case Id(Unit test case ID's)
8.Integration Test Case Id (Integration test case ID's)
9.System Test Case Id (System Test case Id's)
10.Release / Build Number(build release number)
It will give coverage of Testcases at different levels of
Testing.