Feature-Based Design Rationale Capture Method for Requirements Tracing

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)

Feature-Based Design Rationale Capture Method for Requirements Tracing

Note

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

A design rationale is a representation of the reasoning behind the design of an artifact. The purpose of a feature-based design rationale capturing method is to provide mechanisms to track for each feature of the system; the description of the engineering decision that the feature represents includes

the summary of the tradeoffs that were considered in arriving at the decision
the ultimate rationale for the decision

The idea for feature-based design rationale capture originated during the performance of domain analysis in a software development project [Bailin 90]. The need to reverse engineer the rationales for various decisions suggested that a reuse environment should not simply present to the developer a set of alternative architectures that have been used on previous systems. It is necessary to present the rationales and issues involved in choosing among the alternatives. The feature-based approach evolved from the argumentation-based design rationale capture methods (see Argument-Based Design Rationale Capture Methods for Requirements Tracing). The major difference between the approaches is that the knowledge is organized around distinctive features of a system (feature-based) rather than around issues raised during the development process (argument-based).

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 and the reusability of components in the system.

Technical Detail

In the feature-based design rationale capture method, a feature is any distinctive or unusual aspect of a system, or a manifestation of a key engineering decision [Bailin 90]. (Note: The definition of a feature in this context is different from a feature in Feature-Oriented Domain Analysis(FODA) , in which a feature is a user-visible aspect or characteristic of the domain [Kang 90].) The features in a system make this system different from any other system in the domain. Examples of categories of features are: operational, interface, functional, performance, development methodology, design, and implementation. Each feature has a list of tradeoffs and rationale associated with it. Representations of the set of features may be entity relationship, dataflow, object communication, assembly, classification, stimulus-response, and state transition diagrams. The purpose of the multiple representations or views is to add flexibility in responding to evolving design paradigms, life cycle models, etc. A new way of looking at a system can be represented by adding a new view or way of looking at the features of the system. This provides a uniqueness and strength to this method that does not exist in other design rationale capturing methods. This approach makes the software engineering process become a process of answering questions about the features of a system rather than a cookbook-like procedure defined by a particular development method.

Usage Considerations

The use of this technology is oriented toward the entire organization, rather than single projects, because the big payoff occurs when a substantial database of corporate knowledge is organized and maintained. If an organization builds the same types of systems, the knowledge acquired in previous developments can be reused. Since the organization of information is around the features of a system as opposed to the issues that arise during a development project, only the issues that observably affect the content of the resulting system are saved.

The use of this technology requires the development of a shared, consistent, and coherent policy by a project team. A procedure for overall coordination must be developed.

Maturity

To date, there is at least one commercially-available tool to support the feature-based design rationale capture method. It is not a highly automated tool, but rather a bookkeeper to support an experience-based, learning-based development process. The commercial tool is based upon a prototype that has been used in laboratory experiments. The feature-based design rational capture method was used on the Software Technology for Adaptable, Reliable Systems (STARS) program to support the Organization Domain Modeling (ODM) process [Lettes 96].

Costs and Limitations

Feature-based design rationale capture methods and supporting tools require additional time and effort throughout the software life cycle. The system is described using multiple views that must be generated and maintained throughout the life of the project. Depending upon the size of the system, the number of views could be large. There is no integrated view of the system and this must be accomplished either mentally by the engineers on the project or through the use of an additional tool/technique. Training for the project team as well as the potential reuser is essential to make effective use of the method.

Alternatives

There are several alternative approaches to requirements traceability methods. Examples include Argument-Based Design Rationale Capture Methods for Requirements Tracing, an approach centered around the debate process (i.e., arguments and their resolution) that occurs during requirements analysis, and the 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).

Index Categories

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

Name of technology

Feature-Based Design Rationale Capture Method for Requirements Tracing

Application category

Requirements Tracing (AP.1.2.3)
Domain Engineering (AP.1.2.4)

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)

References and Information Sources

[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.
[Kang 90]	Kang, K., et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study (CMU/SEI-90-TR-21, ADA 235785). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990.
[Lettes 96]	Lettes, Judith A. & Wilson, John. Army STARS Demonstration Project Experience Report (STARS-VC-A011/003/02). Manassas, VA: Loral Defense Systems-East, 1996.
[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.
[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.

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

Status