Traceability matrix
Encyclopedia
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 requirement
s (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 case
s.
A requirements traceability matrix may be 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.
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.
Baseline (configuration management)
Configuration management is the process of managing change in hardware, software, firmware, documentation, measurements, etc. As change requires an initial state and next state, the marking of significant states within a series of several changes becomes important...
that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirement
Requirement
In engineering, a requirement is a singular documented physical and functional need that a particular product or service must be or perform. It is most commonly used in a formal sense in systems engineering, software engineering, or enterprise engineering...
s (these often consist of marketing requirements) and detailed requirements of the software product to the matching parts of high-level design
High-level design
A high-level design provides an overview of a solution, platform, system, product, service, or process.Such an overview is important in a multi-project development to make sure that each supporting component design will be compatible with its neighbouring designs and with the big picture.The...
, detailed design, test plan
Test plan
A test plan is a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.-Test plans:...
, and test case
Test case
A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test...
s.
A requirements traceability matrix may be used to check to see if the current project requirements are being met, and to help in the creation of a Request for Proposal
Request for Proposal
A request for proposal is issued at an early stage in a procurement process, where an invitation is presented for suppliers, often through a bidding process, to submit a proposal on a specific commodity or service. The RFP process brings structure to the procurement decision and is meant to...
, various deliverable documents, and project plan tasks.
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.
Sample 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 |
External links
- Bidirectional Requirements Traceability by Linda Westfall
- Requirements Traceability Neville Turbit
- Software Development Life Cycles: Outline for Developing a Traceability Matrix by Diana Baldwin
- StickyMinds article: Traceability Matrix by Karthikeyan V
- Why Software Requirements Traceability Remains a Challenge by Andrew Kannenberg and Dr. Hossein Saiedian