A Traceability Matrix should be created once the requirements have been baselined and updated throughout the project. Commonly this would appear as a table cross-referencing the requirements against the Functional Specification, Application, Infrastructure and Component Design documents, and the unit, component-integration and system testing conditions and Test Scripts. These could appear as columns in the matrix as follows.
Section No.
Section Heading Name
Description
Information Source
1
Unique Row Number
To aid identification of each cross reference
2
Requirement Reference
Taken from the Requirements Specification
3
Requirement description
A brief description of the business requirement
4
Business Priority
5
Change Request Number
Usually the Change Number in the log
6
Functional Specification Reference
Usually a unique number from the Functional Specification bearing some relationship to the Requirements Reference Number, and a brief description of the relevant functionality. For non-functional requirements this may be marked N/A (not applicable)
7
Application Design Reference
Usually a unique number from the Application Design bearing some relationship to the Requirements Reference Number, and a brief description of the relevant design feature
8
Infrastructure Design Reference
Usually a unique number from the Infrastructure Design bearing some relationship to the Requirements Reference Number, and a brief description of the relevant design feature
9
Component Design Reference
Usually a unique number from the Component Design bearing some relationship to the Requirements Reference Number, and a brief description of the relevant design feature
10
A relevant Test Condition ID and Test Script ID
ID's taken from the Test Plan for each of the following levels of testing:
Unit
Component-Integration
System, which is subdivided into:
Implementation
User Requirement
Performance
User Acceptance
Operational Acceptance
11
Test Result for that particular test
This column can be used to indicate whether the test is still to be done, has failed, has been passed or is not required. This provides a means of checking that all requirements have been addressed, i.e. that testing is complete.
12
Comments
Any comments that will help clarify the meaning of any line
RequsitePro is an excellent tool for Requirements Traceability but a spreadsheet along the lines above can work just as well although it can be a lot of work to maintain in an up to date form. It really is a living document and lasts for the lifetime of the project.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: