|
Advanced
The development and use of requirements tracing techniques originated in the
early 1970s to influence the
completeness,
consistency, and
traceability of the requirements of a system. They provide an answer to the following questions:
- What mission need is addressed by a requirement?
- Where is a requirement implemented?
- Is this requirement necessary?
- How do I interpret this requirement?
- What design decisions affect the implementation of a requirement?
- Are all requirements allocated?
- Why is the design implemented this way and what were the other alternatives?
- Is this design element necessary?
- Is the implementation compliant with the requirements?
- What acceptance test will be used to verify a requirement?
- Are we done?
- What is the impact of changing a requirement
[SPS
94]?
The purpose of this technology description is to introduce the key concepts of requirements tracing. Detailed discussions of the individual technologies can be found in the referenced technology descriptions.
Requirements traceability is defined as the ability to describe and follow the
life of a requirement, in both a forward and backward direction (i.e., from
its origins, through its development and specification, to its subsequent
deployment and use, and through periods of ongoing refinement and iteration in
any of these phases)
[Gotel 95]. It can be achieved by using one or more of the following techniques:
- Cross referencing. This involves embedding phrases like "see section x" throughout the project documentation (e.g., tagging, numbering, or indexing of requirements, and specialized tables or matrices that track the cross references).
- Specialized templates and integration or transformation
documents. These are used to store links between documents created in different phases of development.
- Restructuring. The documentation is restructured in terms of an underlying network or graph
to keep track of requirements changes (e.g., assumption-based truth
maintenance networks, chaining mechanisms, constraint networks, and
propagation)
[Gotel 95].
For any given project, a key milestone (or step) is to determine and agree upon requirements traceability details. Initially, three important questions need to be answered before embarking on any particular requirements traceability approach:
- What needs to be traceable?
- What linkages need to be made?
- How, when, and who should establish and maintain the resulting database?
Once the questions are answered, then selection of an approach can be
made. One approach could be the structured use of general-purpose tools (e.g.,
hypertext editors, word processors, and spreadsheets) configured to support
cross-referencing between documents. For large software development projects,
an alternative approach could be the use of a dedicated workbench centered
around a database management system providing tools for documenting, parsing,
editing, decomposing, grouping, linking, organizing, partitioning, and
managing requirements. Table 9 describes the strengths
and weaknesses of each of the approaches.
Table 9: Comparing Requirements Tracing Approaches
|
Approaches
|
Strengths
|
Weaknesses
|
General
purpose tools
|
· readily available
· flexible
· good for small projects
|
· need to be configured to support Requirements Traceability (RT)
· potential high RT maintenance cost
· limited control over RT information
· potential limited integration with other software development tools
|
|
Workbenches
|
· fine-grained forward, backward, horizontal, and vertical RT
· RT results may facilitate later development activities (i.e., testing)
· suitable for large projects
|
· depend upon stakeholder buy-in
· manual intervention may be required
· RT in later development phases may be difficult
|
Regardless of the approach taken, requirements tracing requires a combination of models (i.e., representation forms), methods (i.e., step by step processes), and/or languages (i.e., semiformal and formal) that incorporate the above techniques. Some examples of requirements tracing methods are discussed in the following technology descriptions:
Every major office tool manufacturer has spreadsheet and/or database
capabilities that can be configured to support requirements tracing. There are
at least ten commercial products that fall in the workbench category and
support some level of requirements traceability
[STSC
98].
At a minimum, they provide
- bidirectional requirement linking to system elements
- capture of allocation rationale, accountability, and test/validation
- identification of inconsistencies
- capabilities to view/trace links
- verification of requirements
- history of requirements changes.
Environments to support requirements traceability past the requirements engineering phase of the system/software life cycle are being researched. Areas include the development of a common language, method, model, and database repository structure, as well as mechanisms to provide data exchange between different tools in the environment. Prototypes exist and at least one commercial product provides support for data exchange through its object-oriented database facilities.
In general, the implementation of requirements tracing techniques within an
organization should facilitate reuse and maintainability of the
system. However, additional resources (time and manpower) to initially
implement traceability processes (i.e., definition of traceability
information, selection of automated tools, training, etc.) will be
required. One case study found that the cost was more than twice the normal
documentation cost associated with the development of a system of similar size
and complexity. However, this was determined to be a one-time cost and the
overall costs to maintain the software system are expected to be
reduced. Almost immediate return was observed in the reduced amount of time to
perform hardware upgrades
[Ramesh 95].
This technology is classified under the following categories. Select a
category for a list of related topics.
|
[Bailin 90]
|
Bailin, S., et al. "KAPTUR: Knowledge Acquisition for Preservation of
Tradeoffs and Underlying Rationale," 95-104. Proceedings of the 5th Annual
Knowledge-Based Software Assistant Conference. Liverpool, NY, September
24-28, 1990. Rome, NY: Rome Air Development Center, 1990.
|
|
[Gotel 95]
|
Gotel, Orlena. Contribution Structures for Requirements
Traceability. London, England: Imperial College, Department of Computing,
1995.
|
|
[Ramesh 92]
|
Ramesh, Balasubramaniam & Dhar, Vasant. "Supporting Systems Development by
Capturing Deliberations During Requirements Engineering." IEEE
Transactions on Software Engineering 18, 6 (June 1992): 498-510.
|
|
[Ramesh 95]
|
Ramesh, Bala; Stubbs, Lt Curtis; & Edwards, Michael. "Lessons Learned
from Implementing Requirements Traceability." Crosstalk, Journal of
Defense Software Engineering 8, 4 (April 1995): 11-15.
|
|
[Shum 94]
|
Shum, Buckingham Simon & Hammond, Nick. "Argumentation-Based Design
Rationale: What Use at What Cost?" International Journal of Human-Computer
Studies 40, 4 (April 1994): 603-652.
|
|
[SPS 94]
|
Analysis of Automated Requirements Management
Capabilities. Melbourne, FL: Software Productivity Solutions, 1994.
|
|
[STSC 98]
|
Software Technology Support Center.
Requirements Management Tools [online].
Available WWW
<URL:http://www.stsc.hill.af.mil/RED/LIST.HTML>
(1998).
|
Liz Kean, Air Force Rome Laboratory
Brian Gallagher, SEI
4 Feb 98: added reference for [STSC 98]
10 Jan 97 (original)
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2007
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/reqtracing_body.html
Last Modified: 11 January 2007
|
