Design Rationale Fundamentals

Systematic documentation of rationale for practical decisions began more than 35 years ago with work on rationale for design [30], in particular, design of buildings and cities. In the 1980s, interest in rationale spread to other fields involved with design, including SE and mechanical engineering. In recent years, researchers in SE have begun to look at rationale for activities other than design, and we argue later that this is an essential trend for the future of the field. Nevertheless, rationale for design remains the dominant theme in rationale research in SE. To understand the history and current state of the field, it is essential to understand the work done on design rationale. This section therefore defines the term design rationale Our definitions are meant to accommodate many points of view about DR. The definitions we have chosen are similar to those given by MacLean et al.

1. We start by defining a design process as one that aims at devising an appropriate design for an artifact. A design we define as an artifact description that is detailed enough for use in implementing (constructing) that artifact. We consider a design appropriate if the artifact described would satisfy requirements while not being unacceptable in other ways, e.g., by producing an unacceptable set of side- and after-effects. Two major categories of artifacts are

(1) physical artifacts, such as buildings, cities and computer hardware,

(2) cognitive artifacts, such as notation systems and software.

2. We define a designer to be anyone participating in a design process. This definition depends on how the term participating is defined and leaves open the possibility that users and clients could be designers.

3. Design rationale (DR) is the reasoning that goes into determining the design of the artifact. It can include not only direct discussion of artifact properties but also any other reasoning influencing design of the artifact. Note that our definitions do not imply that design starts only after requirements have been fully determined. During requirements specification many design decisions are made and these are relevant for design rationale. Similarly, design does not stop before

implementation begins. Feedback from implementation and testing could be part of the design rationale.and introduces fundamental characteristics of DR approaches.