Visions, requirements, and reasons for them first appear in the earliest project phase. Communication in this phase is typically based on informal meetings, slide presentations, and oral discussions. After a while, more formal requirements engineering takes over.
Design decisions are mainly discussed by technical experts and architects during the design phase. Decisions are made by groups and by individuals. They are typically communicated through overview charts, architecture sketches, and oral explanations.
Prototypes are often used to decide between design alternatives. Different kinds of prototypes were differentiated by Lichter et al. [12]. The types of information provided by those prototttypes have also been analyzed [16]. Prototypes spark insights that add to the rationale for technical decisions. Demonstration prototypes elicit customer requirements and rationale.
During the entire project, requirements are further negotiated, priori-tized, and rearranged [1]. Some of these activities will require initial design proposals or prototypes. Reducing project risks is a constant task in project management. Identified risks may cause design decisions. Different stakeholders may disagree on requirements or risks – probably disagreeing on deeper assumptions and rationale as well. Compromises must be found that will be accompanied by rationale. Much of the above-mentioned rationale resides in the heads of project participants. Rationale is seldom documented.
Documenting rationale in a systematic way has long been an issue in software engineering. The Potts and Bruns model [15] was used by Lee [11] to describe rationale. The result resemmbles a specific kind of “seman-tic web” with qualified relationships, similar to ontologies [20]. However, a sophisticated (and maybe “intrusive”) representation calls for effort, time, and resources to build and to maintain. This chapter advocates a very different approach. In analogy to agile methods in software engineering [2,3], light-weight approaches to rationale capturing were studied and adopted. Light-weightt indicates a clear priority to save time and effort from the perspective of bearers of rationale. This reduction of effort is afforded by sophisticated preparation and tools: tailor-made recording software is used, and masses of data are recorded just to capture some of the above-mentioned valuable rationale. The trick is to pick the right occasion and the right indexing-mechanism (“paths”) for each specific activity observed.
