Introduction

Traceability needs to be implemented throughout any development. This must include vertical traceability, between levels of abstraction (for example, from a system requirement to one or more stakeholder requirements) and horizontal traceability (for example from a test case to a system requirement).

Uses of Traceability

Traceability information is fundamental to impact analysis, particularly in assessing the impact of a proposed change.

It is also fundamental to coverage analysis, both in the sense of ensuring that all relevant items at one level of specification or development are adequately reflected at the next level, and also to assist in assessing test coverage.

For completeness, each requirement stated at one level of abstraction, must satisfy one or more requirements at the next higher level. Similarly, each requirement must be verified by at least one test.

Development Traceability

The following are some examples in this domain:

• Stakeholder Requirements--Trace->Use Case: shows that Stakeholder Requirements are derived from a Use Case (and the Vision).
• System Requirements--Trace->Use Case: shows that System Requirements are derived from a Use Case (and the Stakeholder Requirements). Each use cases groups a set of system requirements that support the capability described by the use case.
• Subsystem Requirements--Trace->System Architecture Model: shows that Subsystem Requirements are derived from the System Architecture Model (and the System Requirements).
• Trade Study--Trace-> (Executable) Use-Case Model: shows that the Trade Study needs to consider elements of the (Executable) Use-Case Model in assessing solution candidates. In particular, the key system functions identified in the trade study are related to the system functions (action nodes on activity diagrams and operations on use-case blocks) in the (Executable) Use-Case Model.
• System Architecture Model--Trace->Trade Study: shows that the contents of the System Architecture Model represent the successful solution candidates as determined by the Trade Study. In particular, the subsystems (system blocks) in the System Architecture Model are related to the winning solution candidates in the Trade Study.

Note, in some cases it is possible to reduce the amount of traceability information to manage by tracing only "higher-level" requirements. However, the cost of doing this is that the granularity of trace information does not permit detailed analysis and can become almost meaningless if taken over more than one level of requirement (for example, sub-system requirement -> system requirement -> stakeholder requirement).

Test Traceability

It is also necessary to be able to trace between test information and requirements.

Both Stakeholder and System Requirements link to Test Cases that reside in the Verification Plan. They may, indeed, share the same Test Cases. The relationships between Test Cases and the Use-Case Model and individual Use Cases reflect the fact that it is frequently valuable to test against high level scenarios and the structure of a Test Case may be informed by the structure of a Use Case.  

Work Item List Traceability

Work Items may also establish traceability between process tasks and artifacts to support tracking of work, support workflows and to provide auditability. For example, an work item references a use case and specifies that some work needs to be done on this use case. One or more changes sets will implement the work item and maintain traceability to the artifacts that are changed as a result of the work preformed. With appropriate tools this traceability can be completely automated.