[raw]
Software development projects have multiple phases: Feasibility, Requirements, Design, Coding, Test, Implementation, and Maintenance. All projects, whether large or small, generate documentation in the form of business requirements, design documents, test plans, and system operating instructions. In small projects the documents can be minimal and easy to manage. But in a large project the documents can be so extensive that management can become nearly impossible. However, there is a tool that can help project leaders keep control over the documents, and it is called a Requirements Traceability Matrix (RTM). There are two types of traceability matrixes, and each one has a specific purpose.
Types of Requirements Traceability Matrixes (RTM)
 
RTM for Project Documents
This type serves as a master document for all the documents created in a software release. Its basic function is to identify and link the various documents that are created during the project phases. It is considered a requirements traceability matrix because all development begins with requirements gathering and documentation. This matrix also records Change Requests and is linked to the original requirements documents and other phase documents that are impacted and need to be updated. The following is an example of the RTM.
|
Project: Spring Software Release for Corporate Office |
|||||||
|
Feasibility ID |
Business Req. ID |
General Design ID |
Detailed Design ID |
Coding Doc. ID |
Test Case ID |
Operating Doc. ID |
Change Req. ID |
|
F-SP2012 |
BR-1 |
GD-1 |
DD-2012-1 |
CD-3 |
TC-2033 |
OP-1410 |
CR-100 |
|
|
BR-2 |
GD-2 |
DD-2012-1 |
CD-3 |
TC-2033 |
OP-1410 |
Cancelled |
|
|
BR-3 |
GD-3 |
DD-2012-4 |
CD-3 |
TC-2034 |
OP-1410 |
|
|
|
BR-4 |
GD-4 |
DD-2012-8 |
CD-5 |
TC-2033 |
OP-1410 |
CR-101 |
|
|
BR-5 |
GD-5 |
DD-2012-9 |
CD-8 |
TC-2033 |
OP-1410 |
|
|
|
BR-6 |
GD-6 |
DD-2012-9 |
CD-8 |
TC-2035 |
OP-1410 |
|
In the previous table, the relationship between documents is not a one-to-one relationship. Sometimes the documents created in subsequent phases are a combination of multiple requirements because there was a dependent relationship between them. The relationship between the documents is bi-directional, or two-way. Each document can relate to one or more other documents created in preceding or subsequent phases.
Example: A customer makes a Change Request for BR-4. If the change is approved, all of the previously created documents will need to be revised to reflect the change. By referring to the matrix, it is easy to determine which documents needed to be revised. In this case, CR-101 requires a revision to BR-4, GD-4, DD-2012-8, CD-5, TC-2033, and OP-1410.
RTM for Test Cases
The second type of RTM traces the relationship of each business requirement to the test cases. This matrix is created after the Test Plan is finished. It contains the Business Requirements ID and the relevant Test Case ID in a column format. The following table is a simple example:
|
Test Case# Bus Req. ID |
TC-1 |
TC-2 |
TC-3 |
TC-4 |
TC-4 |
TC-5 |
TC-6 |
TC-7 |
|
BR-1 |
x |
|
|
|
|
|
|
|
|
BR-2 |
|
x |
|
|
|
|
|
|
|
BR-3 |
|
|
x |
|
|
|
|
|
|
BR-4 |
|
|
x |
x |
|
|
|
|
|
BR-5 |
|
|
|
|
x |
x |
x |
|
|
BR-6 |
|
|
|
|
|
|
x |
x |
This matrix insures that all requirements are tested and that nothing is overlooked before the software is implemented. On occasion, testing may uncover a defect that originated in the Business Requirements document and was overlooked during review and customer sign-off. Using the matrix, project leaders can easily trace the Test Case back to the Business Requirements document that needs updating.
Requirements Traceability Matrix Templates and Requirements Traceability Matrix Samples are often used to promote consistency and professionalism within an organization.
[/raw]