Checklist: Requirements Traceability |
Relationships
Related Elements | Requirements Requirements Traceability
Main Description
This checklist provides questions to use to define traceability, and to create and populate traceability matrices. It helps verify that the artifacts that are dependent upon each other have been linked in a consistent and complete manner. Every project needs to consider maintaining some minimal amount of traceability to support consistency checking and change impact analysis. Traceabilities that are commonly defined as part of the requirements practice include (but are not limited to) business objectives to features, and features to use cases.
Check Items
Have all the necessary traceabilityes been defined and has a marix been created to represent each one?
The amount of traceability required to support the project needs to be defined up-front. The optimal amount of traceability varies by organization, and even by project within an organization. A traceability matrix must be created for each traceability that is defined.
Do all the traceabilities and supporting matrices which have been defined provide value for the project?
Maintaining traceabilities can lead to unnecessary overhead if they convey information that has limited or no value to the project team. For example, one could trace every term in a use case to its glossary definition, but few projects would benefit from such tracing.
Do traceabiltiy matrices keep row or column artifact types consistent?
If the matrix mixes row artifact types or column artifact types, rework it so that all of the artifacts in each row are of the same type. For instance: each row is a use case, and no row is anything else but a use case; each column is a business rule, and no column is anything else but a business rule.
Do empty rows on the trace matrix correctly reflect the status of the project?
For each empty row in the matrix, one of the following must be true: The artifact in that row is not needed, because it does not trace to any column artifacts. The artifact in that row is needed, and it traces to one or more existing column artifacts, which have not yet been associated with it. The artifact in that row is needed, and it traces to one or more new column artifacts. In rare cases, you would not set traceability when an artifact in a row would trace to every artifact in the columns, or vice versa (for example, a global non-functional requirement that traced to all use cases).
Do empty columns on the trace matrix correctly reflect the status of the project?
For each empty column in the matrix, one of the following must be true: The artifact in that column is not needed, because it does not trace to any row artifacts. The artifact in that column is needed, and it traces to one or more existing row artifacts, which have not yet been associated with it. The artifact in that column is needed, and it traces to one or more new row artifacts. In rare cases, you would not set traceability when an artifact in a column would trace to every artifact in the rows, or vice versa (for example, a global non-functional requirement that traced to all use cases).
Do rows or columns with many interactions correctly reflect the status of hte project?
When a row artifact interacts with lots of column artifacts or vice versa, one of the following must be true: The content of the artifact that has a lot of interaction is very important, and deserves special attention (such as extra testing or approval, or a dedicated group to work on it). If the content of an artifact has a lot of interactions, it could be more complex than it needs to be. If so, it must be refactored into two or more artifacts.
If the matrix is supported by an automated tool, is all of the tracing either from row to column or column to row but not mixed?
"Mixed" means tracing from row to column and column to row in the same matrix. Automated tools usually support one-way traceability to avoid circular references in transitive tracings. (Transitive Tracing means if A traces to B and B traces to C, then A traces to C.) If tracing from rows to columns as well as columns to rows is included in the same matrix within an automated tool, rework it so that the tracing is one-way to support transitivity. The direction for one way tracing is specified as part of the traceability definition, or within the Requirement Management Plan, if one was created.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.