Rationale1 is the justification behind decisions. It is captured and used in many different forms during software engineering (SE). The availability of rationale increases the developers’ understanding of the system, making it easier to adapt or maintain. Being able to explain past decisions also facilitates the training of new members in a development team. However, rationale is often only captured partially and informally, often as natural language in design documents and in communication artifacts, making it difficult to access and maintain. In the 1980s, the SE community, along with several others, started using 1 Historically, much research about rationale focuses on design and, hence, the term design rationale is most often used in the literature. In Sects. 1.1–1.5, which cover fundamentals of rationale management, we use the term design rationale. However, in Sects. 1.6–1.8, we use the term software engineering rationale to emphasize that rationale models are used during all activities of development, including requirements engineering, architectural design, implementation, testing, and system deployment. rationale approaches. Process-based approaches, such as the use of Issue Based Information System (IBIS) described by Conklin and Burgess- Yakemovic [9], represent rationale as decision-making steps, capturing the argumentation behind designs as it occurs. Structural approaches, such as Questions, Options, and Criteria (QOC) [38], represent rationale as a space of alternatives and evaluation criteria, reconstructing rationale after decisions are made. In both cases, capturing rationale entails the elicitation and formalization of tacit knowledge, potentially introducing much overhead and disruption in the development process [4]. Rationale also features many elements and interdependencies, making it often difficult to keep up to date. A rationale management system (RMS) is one that aims to address the above-stated issues. RMSs enable the capturing and accessing of rationale. The potential benefits of employing the services of an RMS include the following:

−Providing greater support to project management

−Improving dependency management

−Providing greater design support

−Helping support collaboration

−Supporting downstream users of design

−Allowing more detailed documentation

−Helping in requirements engineering

−Aiding in design reuse and ultimately provide a learning tool for evaluating design The complete rationale for even a small system is impossible to represent; consequently, developers are faced with selecting which rationale to represent in an RMS. Other implementation issues raised by researchers [46] are the formality (or informality) of the design rationale (DR) representation [21], and the approach to capturing rationale (e.g., reconstruction, apprentice shadowing, automatic generation). An RMS also aims to address the disruption caused by capturing rationale, recording rationale as a side effect of other activities, such as requirements elaboration, risk management, or process enactment. The goal of this chapter is to review the current state-of-the art of rationale management approaches and tool support in SE, and map future research directions. Section 1.2 defines DR concepts. Section 1.3 discusses the fundamental DR approaches, such as IBIS, DRL, and QOC, from a historical perspective. Section 1.4 identifies and categorizes uses of design rationale. Section 1.5 identifies inherent limitations of DR approaches and proposes possible remedies. Section 1.6 discusses rationale in the specific context of SE, in terms of opportunities and a survey of the current state of the art. In Sect. 1.7 we synthesize our observations of Sect.


Leave a Reply

Your email address will not be published.