Traceability Matrix

Requirement Identifiers Reqs Tested REQ1


UC

1.1 REQ1

UC

1.2 REQ1

UC

1.3 REQ1

UC

2.1 REQ1

UC

2.2 REQ1

UC

2.3.1 REQ1

UC

2.3.2 REQ1

UC

2.3.3 REQ1

UC

2.4 REQ1

UC

3.1 REQ1

UC

3.2 REQ1

TECH

1.1 REQ1

TECH

1.2 REQ1

TECH

1.3

Test Cases 321 3 2 3 1 1 1 1 1 1 2 3 1 1 1

Tested Implicitly 77

1.1.1 1 x

1.1.2 2 x x

1.1.3 2 x x

1.1.4 1 x

1.1.5 2 x x

1.1.6 1 x

1.1.7 1 x

1.2.1 2 x x

1.2.2 2 x x

1.2.3 2 x x

1.3.1 1 x

1.3.2 1 x

1.3.3 1 x

1.3.4 1 x

1.3.5 1 x

etc…

5.6.2 1 x

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases.

For instance a requirements traceability matrix is used to check to see if the current project requirements are being met, and to help in the creation of a Request for Proposal, various deliverable documents, and project plan tasks.[1]

Common usage is to take the identifier for each of the items of one document and place them in the left column. The identifiers for the other document are placed across the top row. When an item in the left column is related to an item across the top, a mark is placed in the intersecting cell. The number of relationships are added up for each row and each column. This value indicates the mapping of the two items. Zero values indicate that no relationship exists. It must be determined if one must be made. Large values imply that the relationship is too complex and should be simplified.

To ease the creation of traceability matrices, it is advisable to add the relationships to the source documents for both backward traceability and forward traceability. In other words, when an item is changed in one baselined document, it's easy to see what needs to be changed in the other.

Forward Traceability and Backward Traceability.

E.g. If a requirement is changed then related test case need to be changed.

Forward traceability means mapping requirements with test cases whereas backward traceability means mapping testcases with requirements.

Mapping take place from from requirements to end products is Forward Traceability

Mapping take place from end product back to requirements is Backward Traceability



Using both the Forward and Backward Traceability is called Bidirectional Traceability. When the requirements are managed well to testcases and testcases to defects and vice versa. This helps nothing is missed in testing process....Bidirectional traceability needs to be implemented both forward and backward i.e. from requirements to end