A survey of architecture design rationale

2005

Many claims have been made about the problems caused by not documenting design rationale. The general perception is that designers and architects usually do not fully understand the critical role of systematic use and capture of design rationale. However, there is to date little empirical evidence available on what design rationale mean to practitioners, how valuable they consider them, and how they use and document design rationale during the design process. This paper reports an empirical study that surveyed practitioners to probe their perception of the value of design rationale and how they use and document background knowledge related to their design decisions. Based on eighty-one valid responses, this study has discovered that practitioners recognize the importance of documenting design rationale and frequently use them to reason about their design choices. However, they have indicated barriers to the use and documentation of design rationale. Based on the findings, we conclude that much research is needed to develop methodology and tool support for design rationale capture and usage. Furthermore, we put forward some research questions that would benefit from further investigation into design rationale in order to support practice in industry. Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) 0-7695-2548-2/05 $20.00 © 2005 IEEE Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) 0-7695-2548-2/05 $20.00 © 2005 IEEE

Rationale Management in Software Engineering, 2006

One goal of design rationale systems is to support designers by providing a means to record and communicate the argumentation and reasoning behind the design process. However, there are several inherent limitations to developing systems that effectively capture and utilize design rationale. The dynamic and contextual nature of design and our inability to exhaustively analyze all possible design issues results in cognitive, capture, retrieval, and usage limitations. In this chapter we analyze these issues in terms of current perspectives in design theory, and describe the implications to design research. We discuss the barriers to effective design rationale in terms of three major goals: reflection, communication, and analysis of design processes. We then suggest alternate means to achieve these goals that can be used with or instead of design rationale systems.

Ai Magazine, 1993

The 1992 Workshop on Design Rationale Capture and Use took place on 15 July in San Jose, California. The goal of the workshop was to bring together people interested in design rationale management and promote interaction among them. Participants were selected from different parts of academia (computer science, human-computer interaction, management, civil engineering, mechanical engineering) as well as from industry. This article summarizes the issues that were raised and discussed during the workshop, categorized under these headings: the nature of design rationale, services: what good are design rationales, representation: what information is worth capturing and reusing, production of rationales, semiformal approaches, and future collaboration.

Proceedings of the 4th Nordic conference on Human-computer interaction changing roles - NordiCHI '06, 2006

One goal of design rationale systems is to support designers by providing a means to record and communicate the argumentation and reasoning behind the design process. However, there are several inherent limitations to developing systems that effectively capture and utilize design rationale. The dynamic and contextual nature of design and our inability to exhaustively analyze all possible design issues results in cognitive, capture, retrieval, and usage limitations. In addition, there are the organizational limitations that ensue when systems are deployed. In this paper we analyze these issues in terms of current perspectives in design theory and describe the implications to design research. We discuss the barriers to effective design rationale in terms of three major goals: reflection, communication, and analysis of design processes. We then suggest alternate means to achieve these goals that can be used with or instead of design rationale systems.

Lecture Notes in Computer Science, 2007

One goal of design rationale systems is to support designers by providing a means to record and communicate the argumentation and reasoning behind the design process. However, there are several inherent limitations to developing systems that effectively capture and utilize design rationale. The dynamic and contextual nature of design and our inability to exhaustively analyze all possible design issues results in cognitive, capture, retrieval, and usage limitations. In addition, there are the organizational limitations that ensue when systems are deployed. In this paper we analyze the essential problems that prevent the successful development and use of design rationale systems. We argue that useful and effective design rationale systems cannot be built unless we carefully redefine the goal of design rationale systems.

IEEE Expert / IEEE Intelligent Systems, 1997

Better design support. Well-structured design rationales can help designers track the issues and alternatives being explored and their evaluations. This, in turn, clarifies the overall structure of the reasoning process and supports decision making. In some cases, of course, all this information can actually hinder design activities by imposing unnecessary overhead or breaking the natural flow

ACM Transactions on Software Engineering and Methodology, 2013

A complete and detailed (full) Design Rationale Documentation (DRD) could support many software development activities, such as an impact analysis or a major redesign. However, this is typically too onerous for systematic industrial use as it is not cost effective to write, maintain, or read. The key idea investigated in this article is that DRD should be developed only to the extent required to support activities particularly difficult to execute or in need of significant improvement in a particular context. The aim of this article is to empirically investigate the customization of the DRD by documenting only the information items that will probably be required for executing an activity. This customization strategy relies on the hypothesis that the value of a specific DRD information item depends on its category (e.g., assumptions, related requirements, etc.) and on the activity it is meant to support. We investigate this hypothesis through two controlled experiments involving a total of 75 master students as experimental subjects. Results show that the value of a DRD information item significantly depends on its category and, within a given category, on the activity it supports. Furthermore, on average among activities, documenting only the information items that have been required at least half of the time (i.e., the information that will probably be required in the future) leads to a customized DRD containing about half the information items of a full documentation. We expect that such a significant reduction in DRD information should mitigate the effects of some inhibitors that currently prevent practitioners from documenting design decision rationale.

Journal of Architectural Engineering, 2011

Consistent, Credible, Certain, and Correct. Using RCF, we observed and documented the rationale clarity of decisions on an industry case project. We then implemented a decision assistance methodology, called MACDADI that seeks to clarify rationale, and observed costs and benefits from each team member's perspective. We identify future work that can lower costs and increase benefits of clarifying rationale.

Human-Computer Interaction INTERACT ’97, 1997

Many positive claims have been made about the benefits of Design Rationale (DR). MacLean et aI., (1991) argue that an explicit design rationale can be a useful tool in the design process in a variety of ways: from reasoning and reviewing to managing, documenting, and communicating. Design rationale is the notion that goes beyond merely accurate descriptions of artifacts, such as specifications, and articulates and represents the reasons and reasoning process behind the design and specification of artifacts (Moran & Carroll, 1996). QOC (Questions, Options, Criteria) is a straightforward notation for representing design rationale (MacLean et aI., 1991). In this paper we present the results of a study investigating the usability and efficiency of DRlQOC as a design support tool, and provide an analysis of the designers' reflections on the role ofDRlQOC in the design process.

2006

Design decisions crucially influence the success of every software project. While the resulting design is typically documented quite well, the situation is usually different for the underlying rationale and decision-making process. Despite being recognized as a helpful approach in general, the explicit documentation of Design Decision Rationale is not yet largely utilized due to some inhibitors (e.g., additional documentation effort). Experience with other qualities, e.g. software reusability, evidently shows that an improvement of these qualities only pays off on a large scale and therefore has to be pursued in a strategic, pre-planned, and carefully focused way. In this paper we argue that this also has to be considered for documenting DDR. To this end the paper presents: (i) the Decision, Goal, and Alternatives (DGA) DDR framework, (ii) experience in dealing with DGA, (iii) motivators and inhibitors of using DDR, and (iv) an approach for systematic DDR use that follows value-based software engineering principles.