Rationale is an asset in software engineering.

Rationale is among the most importantt information a software project produces. It is important to know why a decision has been made and why one design or solution has been preferred over another. Later decisions are facilitated by knowing why earlier decisions have been made. During maintenance, documented rationale can save a large percentage of effort. Chapter 1 introduced many important aspects of when and how to use rationale.

However, capturing rationale is not straightforward. The most productive project phases in terms of decisions and concepts are the least likely to accommodate opportunities for documenting rationale. Exactly at the point in projects where most design decisions are made, documentation is often not a high priority. All available resources and time slots are devoted to the product but none is devoted to (or “wasted on”) documentation or rationale.

Capturing “rationale as a by-product” takes those constraints into account. A number of principles describe the core of this approach. Selected human interactions are recorded in several modes in parallel: In addition to audio or video recording, specific “paths” are recorded and reused to index the large amount of audio/video data. A path is a time-indexed sequence of elements (e.g. code modules) visited during the human interaction. For example, the sequence of all modules explained by an expert is logged as one such path.

In Sect. 4.2, some situations are described in which rationale is built and communicated. The Rationale Paradox describes the phenomenon that usually none of the surfaced rationale gets captured where it occurs. Section 4.3 defines what is meant by the “Rationale as a By-Product Approach.” There is a general definition and explanations of the principles that make up the approach. Related work is mentioned in this context. Two instantiations of the approach are introduced as examples: Sect. 4.4 addresses software prototypes, and Sect. 4.5 is devoted to risk management. The approach is discussed in Sect. 4.6. Section 4.7 concludes.