General Navigation Buttons - Home | Search | Contact Us | Site Map | Whats New
products graphic
white space
products
Software Technology Roadmap
What's New
Background & Overview
Technology Descriptions
Defining Software Technology
Technology Categories
Template for Technology Descriptions
Taxonomies
Glossary & Indexes
Feedback & Participation
Software Engineering Information Repository (SEIR)
white space
About SEI|Mgt|Eng|Acq|Collaboration|Prod.& Services|Pubs
pixel
Rollover Popup Hints for Topic Navigation Buttons above
pixel
Argument-Based Design Rationale Capture Methods for Requirements Tracing


Status

Advanced

Note

We recommend Requirements Tracing--An Overview as prerequisite reading for this technology description.

Purpose and Origin

A design rationale is a representation of the reasoning behind the design of an artifact. The purpose of argument-based design rationale capturing methods is to track

  • the discussions and deliberations that occur during initial requirements analysis
  • the reasons behind design decisions
  • the changes in the system over the course of its life, whether they are changes in requirements, design, or code (i.e., any software artifact)
  • the reasons for and impact of the changes on the system
Replaying the history of design decisions facilitates the understanding of the evolution of the system, identifies decision points in the design phase where alternative decisions could lead to different solutions, and identifies dead-end solution paths. The captured knowledge should enhance the evolvability of the system.

The study of argument-based design rationale capture originated during the late 1950s and early 1960s with D. Englebart, who developed a conceptual framework called Humans Using Language, Artifacts, and Methodology in which they are Trained (H-LAM/T) and with Stephen Toulmin and his work concerning the representational form for arguments [Shum 94].

Technical Detail

There are two general approaches to argument-based design rationale capture, both of which are based upon the entity-relationship paradigm:

  1. The Issue Based Information Systems (IBIS) that deals with issues, positions, and arguments for which the emphasis is on recording the argumentation process for a single design [Ramesh 92].
  2. The Questions, Options, and Criteria (QOC) notation [Shum 94], for which assessments are relationships between options, and criteria and arguments are used to conduct debate about the status of the entities and relationships.
Decision Representation Language (DRL) combines and extends the two approaches to provide support for computational services like dependency management, precedence management, and plausibility management. All of the approaches provide mechanisms for a breadth-first analytic understanding of issues, thus setting the context for concrete refinement of the design.

All of the information gathered using the above mentioned methods/languages is generally called process knowledge. The process knowledge is cross-referenced to the requirements created during the requirements engineering phase. The entities and relationships provide for the structuring of design problems, and they provide a consistent mechanism for decision making and tracking and communication among team members.

Laboratory and small-scale field experiments have been conducted to determine the utility and effectiveness of design rationale capturing methods. Potential benefits include the following:

  • Revision becomes a natural process.
  • Design rationale capture methods can help to keep the design meetings on track and help maintain a shared awareness of the meeting's process.
  • The design rationale record can help identify interrelated issues that need to be resolved. Related arguments enable team members to prepare for the meeting and lead to a better solution.
  • The methods can help originators of ideas understand how they are understood by the rest of the team. Note: More analysis is required before the utility of the methods for communicating understandings is fully demonstrated.
The records can be a valuable resource when it becomes necessary to reanalyze a previous decision. Note: There is no data on how frequently the revisitation is necessary, therefore, the benefits may invalidate the effort necessary to capture the information.

Potential pitfalls include the following:

  • Care must be taken to avoid prolonged reflective processes and the extensive analysis of high-level or peripheral issues.
  • There may be inconsistencies in categorizing the design rationale information in the database because one person's assumptions may be another person's rationale and yet another person's decision.
  • Because of the nature of the semiformal language, the reader may need to be familiar with the design to understand the design rationale as represented.

Usage Considerations

The use of this technology requires the development of a shared, consistent, and coherent requirements traceability policy by a project team. Each of the team members must provide commitment to the policy and procedures. A procedure for overall coordination must be developed. To date, these procedures are project-dependent and there is no consistent policy. It will require effort to generate and maintain the entities and relationships in the design rationale database for a given system.

Maturity

To date, there is at least one commercially-available tool to support the IBIS notation. The vendor also provides training and support for their tool. Proprietary tools to support the IBIS method are being used on government projects (e.g., a database exists with over 100,000 requirements under management) [Ramesh 92]. Tools to support the other methods are in various prototype stages.

Costs and Limitations

Argument-based design rationale capture methods and supporting tools require additional time and effort throughout the software life cycle. Individuals must generate and maintain the entity relationship diagrams for any and all of the methods. Training is essential to make effective use of the methods.

Dependencies

This technology makes use of entity-relationship modeling as the basis for the methods.

Alternatives

There are several alternative approaches to requirements traceability methods. Examples include: Process Knowledge Method, an extension of the argument-based approach that includes a formal representation to provide two way traceability between requirements and artifacts and facilities for temporal reasoning (i.e., mechanisms to use the captured knowledge), and Feature-Based Design Rationale Capture Method for Requirements Tracing , an approach that is centered around the distinctive features of a system.

Index Categories

This technology is classified under the following categories. Select a category for a list of related topics.

Name of technology

 Argument-Based Design Rationale Capture Methods for Requirements Tracing

Application category

 Requirements Tracing (AP.1.2.3)

Quality measures category

 Completeness (QM.1.3.1)
Consistency (QM.1.3.2)
Traceability (QM.1.3.3)
Effectiveness (QM.1.1)
Reusability (QM.4.4)
Understandability (QM.3.2)
Maintainability (QM.3.1)

Computing Reviews Category

 Software Engineering Tools and Techniques (D.2.2)
Software Engineering Design (D.2.10)
Project and People Management (K.6.1)

References and Information Sources

[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-52.

Current Author/Maintainer

Liz Kean, Air Force Rome Laboratory

Modifications

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/argument_body.html
Last Modified: 11 January 2007