Three Studies of Design Rationale as Explanation

This transfer among different stakeholders in a systems development project. DR is about helping to make explicit much of the assumed, tacit knowl-edge that underlies shared understanding between stakeholders in the same and in different roles. The studies reported here describe three example “use cases” of DR as explanation.

DR as explanation is both a descriptive and a prescriptive thesis. DR is about capturing and communicating the “why” underlying the structure and behavior of a system. DR as explanation is therefore a descriptive idea; it is the essence of the rationale-centric approach to the thinking about the design knowledge. To really leverage the potential power of these explanations, however, requires acknowledging the communicatory power and value of rationales. Explanations are pervasive in the use of DR. Whether among designers or between designers and other project stakeholders, explanations based on the underlying rationale of particular design are the means by which systems are comprehended, adopted, used effectively, enhanced, reused in new settings, and so on. Software engineering is a team-oriented and knowledge-intensive enterprise; DR is the currency that facilitates exchange of knowledge among the project team members.

The chapter first explores complex system explanations and frames these relative to the capabilities provided by access to DR. Prior research in knowledge-based systems and in software engineering has suggested a role for DR as the basis for system explanations, and this work is reviewed in support of the chapter’s main arguments. Section 2.2 describes three specific cases of DR as explanation. In the first of these, the Questions–Options–Criteria (QOC, [17]) approach was employed to support development of the system help content. In the second, scenarios and claims analysis [7,8,9] are being used to construct a technology transfer package designed to assist potential technology adopters in comprehending the technology and how it might fit with their own organizational objectives and priorities. In the third, scenarios and claims were again employed, this time as a means for evaluating a collaborative system in the field. This last case shows how evaluation results can be transformed into retrospective DR, and how these can be used to develop new design meta-criteria for fu-ture system developers examines the relationship between the rationale that emerges in the systems design and development context and the explanations constructed in the context of system development, evolution, and use. Motivating this work is the proposition that as systems become more pervasive, complex, and intelligent, better means of explaining their structure and behavior will be required to ensure adoption and effective use. The use of design rationale (DR) as the basis for system explanations is an important part of the DR value equation. Justifying the cost and effort of DR capture involves developing ways to use the products of these efforts more effectively. Access to DR may be particularly important in more complex systems, intelligent, distributed systems, for example, because of the degree of understanding and trust required between these systems and their users as they work together in a problem domain.

DR captures the intentions underlying creation of a system artifact, and the issues, questions, argumentation, and decisions made in the process of navigating a given design space. The knowledge base represented by DR provides the raw material for active construction of system explanations in these contexts. As Dutoit et al. ([12], Chap. 1 in this book) point out there is a range of different uses for DRR including, importantly, knowledg