Traceability is the ability to trace a project element to other related project elements, especially those related to
requirements. Project elements involved in traceability are called traceability items. Typical traceability items include different Types of Requirements, analysis and design model elements, test work products, and
end-user support documentation and training material, as shown in the figure below.
The traceability hierarchy.
Each traceability item has its own unique set of associated attributes (See: Requirement Attributes), which is useful for tracking the status,
benefit, risk, etc. associated with each item.
The purpose of establishing traceability is to help:
-
Understand the source of requirements
-
Manage the scope of the project
-
Manage changes to requirements
-
Assess the project impact of a change in a requirement
-
Assess the impact of a failure of a test on requirements (i.e. test failure may mean the requirement is not
satisfied)
-
Verify that all requirements of the system are fulfilled by the implementation.
-
Verify that the application does only what it was intended to do.
Traceability helps you understand and manage how input to the requirements, such as Business
Rules and Stakeholder Requests, are translated into a set of key
stakeholder/user needs and system features, as specified in the Vision
document. The Use-Case Model, in turn, outlines the how these features are
translated to the functionality of the system. The details of how the system interacts with the outside world are
captured in Use Cases, with other important requirements such as non-functional
requirements, and design constraints in the Supplementary Specifications. Traceability allows you to also follow
how these detailed specifications are translated into a design, how it is tested, and how it is documented for the
user. For a large system, Use
Cases and Supplementary Specifications may be packaged together to define a Software Requirements Specification (SRS) for a particular "feature"
or other subsystem grouping.
A key concept in helping to manage changes in requirements is that of a "suspect" traceability link. When a
requirement (or other traceability item) changes at either end of a traceability link, all links associated with that
requirement are marked as "suspect". This flags the responsible role to review the change and determine if the
associated items will need to change also. This concept also helps in analyzing the impact of potential changes.
Traceabilities may be set up to help answer the following sample set of queries:
-
Show me user needs that are not linked to product features.
-
Show me the status of tests on all use cases in iteration #n.
-
Show me all supplementary requirements linked to tests whose status is untested.
-
Show me the results of all tests that failed, in order of criticality.
-
Show me the features scheduled for this release, which user needs they satisfy, and their status.
Example:
For a Recycling Machine system, the Vision document specifies the following feature:
This feature is traced to a use case "Add New Bottle Type":
This traceability helps us verify that all features have been accounted for in use cases and supplementary
specifications.
The most important traceability items are:
Other elements, such as Business Rules and Issues may also be useful to trace.
A typical traceability is shown in the following diagram:
This diagram only shows traceability to requirements. Other traceability may exist as well, but is not shown on
this diagram: design elements trace down to implementation elements, there are test cases for design and
implementation, etc.
|