Professional Documents
Culture Documents
Design Rationale
Design Rationale
Design Rationale
Overview
A design rationale is the explicit listing of
decisions made during a design process, and
the reasons why those decisions were
A Decision Based Design Structure, which spans the areas
made.[2] Its primary goal is to support of engineering design, design rationale and decision
designers by providing a means to record and analysis.
communicate the argumentation and
reasoning behind the design process. [3] It
should therefore include:[4]
Several science areas are involved in the study of design rationales, such as computer science[2] cognitive
science,[3] artificial intelligence,[5] and knowledge management.[6] For supporting design rationale, various
frameworks have been proposed, such as QOC, DRCS, IBIS, and DRL.
History
While argumentation formats can be traced back to Stephen Toulmin's work in the 1950s[7] datums, claims,
warrants, backings and rebuttals, the origin of design rationale can be traced back to W.R. Kunz and Horst
Rittel's[1] development of the Issue-Based Information System (IBIS) notation in 1970. Several variants on
IBIS have since been proposed.
The first was Procedural Hierarchy of Issues (PHI), first described in Ray McCall's PhD
Dissertation[8] although not named at the time.
IBIS was also modified, in this case to support Software Engineering, by Potts & Bruns.[9]
The Potts & Bruns approach was then extended by the Decision Representation Language
(DRL).[10] which itself was extended by RATSpeak.[5]
Questions Options and Criteria (QOC), also known as Design Space Analysis[11][12] is an
alternative representation for argumentation-based rationale, as are Win-Win[13] and the
Decision Recommendation and Intent Model (DRIM).[14]
The first Rationale Management System (RMS) was PROTOCOL, which supported PHI, which was
followed by other PHI-based systems MIKROPOLIS and PHIDIAS. The first system providing IBIS
support was Hans Dehlinger's STIEC.[15] Rittel developed a small system in 1983 (also not published) and
the better known gIBIS (graphical IBIS) was developed in 1987.[16]
Not all successful DR approaches involve structured argumentation. For example, Carroll and Rosson's
Scenario-Claims Analysis approach[17] captures rationale in scenarios that describe how the system is used
and how well the system features support the user goals. Carroll and Rosson's approach to design rationale
is intended to help designers of computer software and hardware identify underlying design tradeoffs and
make inferences about the impact of potential design interventions.[18]
Rationale capture
Capture methods
A method called "Reconstruction"[4] captures rationales in a raw form such as video, and
then reconstruct them into a more structured form.[19] The advantage of Reconstruction
method is that rationales can be carefully captured and capturing process won't disrupt the
designer. But this method might result in high cost and biases of the person producing the
rationales
The "Record-and-replay"[4] method simply captures rationales as they unfold. Rationales
are synchronously captured in a video conference or asynchronously captured via bulletin
board or email-based discussion. If the system has informal and semi-formal representation,
the method will be helpful.
The "Methodological byproduct"[4] method captures rationales during the process of design
following a schema. But it's hard to design such a schema. The advantage of this method is
its low cost.
With a rich knowledge base (KB) created in advance, the "Apprentice"[4] method captures
rationales by asking questions when confusing or disagreeing with the designer's action.
This method benefits not only the user but the system.
In "Automatic Generation"[4] method, design rationales are automatically generated from an
execution history at low cost. It has the ability in maintaining consistent and up-to-date
rationales. But the cost of compiling the execution history is high due to the complexity and
difficulty of some machine-learning problems.
The "Historian"[20] method let a person or computer program watches all designer's actions
but does not make suggestions. Rationales are captured during the design process.[19]
Rationale representation
The choice of design rationale representation is very important to make sure that the rationales we capture is
what we desire and we can use efficiently. According to the degree of formality, the approaches that are
used to represent design rationale can be divided into three main categories: informal, semiformal, or
formal.[4] In the informal representation, rationales can be recorded and captured by just using our
traditionally accepted methods and media, such as word processors, audio and video records or even hand
writings. However, these descriptions make it hard for automatic interpretation or other computer-based
supports. In the formal representation, the rationale must be collected under a strict format so that the
rationale can be interpreted and understood by computers. However, due to the strict format of rationale
defined by formal representations, the contents can hardly be understood by human being and the process
of capturing design rationale will require more efforts to finish, and therefore becomes more intrusive.
Semiformal representations try to combine the advantages of informal and formal representations. On one
hand, the information captured should be able to be processed by computers so that more computer based
support can be provided. On the other hand, the procedure and method used to capture information of
design rationale should not be very intrusive. In the system with a semiformal representation, the
information expected is suggested and the users can capture rationale by following the instructions to either
fill out the attributes according to some templates or just type into natural language descriptions.[4]
Argumentation-based models
RATSpeak
Based on DRL, RATSpeak is developed and used as the representation language in
SEURAT (Software Engineering Using RATionale).[27] RATSpeak takes into account
requirements (functional and non-functional) as part of the arguments for alternatives to the
decision problems. SEURAT also includes an Argument Ontology which is a hierarchy of
argument types and includes the types of claims used in the system.
In the WinWin Spiral Model, the goals of each stakeholder are defined as Win conditions.
Once there is a conflict between win conditions, it is captured as an Issue. Then the
stakeholders invent Options and explore trade-offs to resolve the issue. When the issue is
solved, an Agreement which satisfies the win conditions of stakeholders and captures the
agreed option is achieved. Design rationale behind the decisions is captured during the
process of the WinWin model and will be used by stakeholders and the designers to
improve their later decision making.[28] The WinWin Spiral model reduces the overheads
of the capture of design rationale by providing stakeholders a well-defined process to
negotiate. In[30] an ontology of decision rationale is defined and their model utilizes the
ontology to address the problem of supporting decision maintenance in the WinWin
collaboration framework.
Applications
Design rationale has the potential to be used in many different ways. One set of uses, defined by Burge and
Brown (1998),[19] are:
Design verification — The design rationale can be used to verify if the design decisions and
the product itself are the reflection of what the designers and the users actually wanted.
Design evaluation — The design rationale is used to evaluate the various design
alternatives discussed during the design process.
Design maintenance — The design rationale helps to determine the changes that are
necessary to modify the design.
Design reuse — The design rationale is used to determine how the existing design could be
reused for a new requirement with or without any changes in it. If there is a need to modify
the design, then the DR also suggests what needs to be modified in the design.
Design teaching — The design rationale could be used as a resource to teach people who
are unfamiliar with the design and the system.
Design communication — The design rationale facilitates better communication among
people who are involved in the design process and thus helps to come up with a better
design.
Design assistance — The design rationale could be used to verify the design decisions
made during the design process.
Design documentation — The design rationale is used to document the entire design
process which involves the meeting room deliberations, alternatives discussed, reasons
behind the design decisions and the product overview.
DR is used by research communities in software engineering, mechanical design, artificial intelligence, civil
engineering, and human-computer interaction research. In software engineering, it could be used to support
the designers ideas during requirement analysis, capturing and documenting design meetings and predicting
possible issues due to new design approach.[31] In software architecture and outsourcing solution design, it
can justify the outcome of architectural decisions and serve as a design guide.[32] In civil engineering, it
helps to coordinate the variety of work that the designers do at the same time in different areas of a
construction project. It also help the designers to understand and respect each other's ideas and resolve any
possible issues.[33]
The DR can also be used by the project managers to maintain their project plan and the project status up to
date. Also, the project team members who missed a design meeting can refer back the DR to learn what
was discussed on a particular topic. The unresolved issues captured in DR could be used to organize further
meetings on those topics.[31]
Design rationale helps the designers to avoid the same mistakes made in the previous design. This can also
be helpful to avoid duplication of work.[5] In some cases DR could save time and money when a software
system is upgraded from its previous versions.[2]
There are several books and articles that provide excellent surveys of rationale approaches applied to
HCI,[34] Engineering Design[4] and Software Engineering.[35]
See also
Goal structuring notation
IDEF6
Method engineering
Problem structuring methods
Theory of justification
References
1. Kunz, W.; Rittel, H. (1970), Issues as elements of information systems. Working Paper 131,
Center for Urban and Regional Development, University of California Berkeley
2. Jarczyk, Alex P.; Löffler, Peter; Shipman III, Frank M. (1992), "Design Rationale for Software
Engineering: A Survey", 25th Hawaii International Conference on System Sciences, 2, pp.
577-586
3. Horner, J.; Atwood, M.E. (2006), "Effective Design Rationale: Understanding the Barriers", in
Dutoit, A.H.; McCall, R.; Mistrík, I. et al., Rationale Management in Software Engineering,
Springer Berlin Heidelberg, pp. 73-90
4. Lee, J. (1997). "Design Rationale Systems: Understanding the Issues". IEEE Expert 12 (3):
78–85
5. Burge, J.E.; Brown, D.C. (2000), "Reasoning with Design Rationale", in Gero, J., Artificial
Intelligence in Design '00, Netherlands: Kluwer Academic Publ., pp. 611–629
6. Xin, W.; Guangleng, X. (2001), "Design Rationale as Part of Corporate Technical Memory",
Systems, Man and Cybernetics, pp. 1904 - 1908.
7. Stephen Toulmin (1958). The Uses of Argument. Cambridge: Cambridge University Press.
8. McCall, R. (1978), On the structure and use of issue systems in design, Doctoral
Dissertation, University of California, Berkeley, University Microfilms
9. Potts, C.; Burns, G. (1988), "Recording the reasons for design decisions", 10th International
Conference on Software Engineering (ICSE '1988), pp. 418-427
10. Lee, J. (1991), "Extending the Potts and Bruns model for recording design rationale",
Proceedings of the 13th International Conference on Software Engineering (ICSE '13), IEEE
Computer Society Press, Los Alamitos, CA, pp. 114-125
11. Maclean, A.; Young, RM.; Moran, T. (1989), "Design rationale: the argument behind the
artifact", SIGCHI Bull. 20, pp. 247-252114-125
12. Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Questions, Options, and Criteria:
Elements of Design Space Analysis", in Moran, T.; Carroll, J., Design Rationale Concepts,
Techniques, and Use, Lawrence Erlbaum Associates, pp. 53-106
13. Barry Boehm, Ross, R (1989). "Theory-W software project management: principles and
examples.". IEEE Transactions on Software Engineering 18 (7): 902-916.
14. Pena-Mora, F.; Sriram, D.; Logcher, R. (1993), "SHARED-DRIMS: SHARED Design
Recommendation-Intent Management System", Proceedings Enabling Technologies
Infrastructure for Collaborative Enterprise, IEEE Press, Morgantown, WV, pp. 213-221
15. Dehlinger, H. (1978), Project STIEC: Systems Analysis of the Generation and Dissemination
of Scientific and Technological Information in the European Community" Report No. 26:
Report on a Batch - Version of STIEC, Heidelberg/Stuttgart
16. Conklin, J.; YakemBegemanovic, M. (1988). "gIBIS: A hypertext tool for exploratory policy
discussion". ACM Transactions on Office Information Systems 6 (4): 303-331.
17. Carroll, JM; Rosson, M (1992). "Getting around the task-artifact cycle: how to make claims
and design by scenario". ACM Trans. Inf. Syst. 10 (2): 181-212
18. Carroll, J. M., & Rosson, M. B. (2003). Design rationale as theory. HCI models, theories, and
frameworks: toward a multidisciplinary science, 431-461.
19. Burge, J.; Brown, D.C. (1998), Design Rationale: Types and Tools, Technical Report (http://
web.cs.wpi.edu/Research/aidg/DR-Rpt98.html), Worcester Polytechnic Institute, Computer
Science Dept. (http://web.cs.wpi.edu/Research/aidg/DR-Rpt98.html), retrieved on 27 April
2007
20. Chen, A.; McGinnis, B.; Ullman, D.; Dietterich, T. (1990), "Design History Knowledge
Representation and Its Basic Computer Implementation", The 2nd International Conference
on Design Theory and Methodology, Chicago, IL, pp. 175-185
21. Reynolds, Chris (2000), What is the Toulmin Model? (http://www.concentric.net/~Creyn266/
COMM335/Toulmin.htm) Archived (https://web.archive.org/web/20070825191503/http://www.
concentric.net/~Creyn266/COMM335/Toulmin.htm) 2007-08-25 at the Wayback Machine
Paper at concentric.net.
22. Conklin, J.; Yakemovic, K. (1991). "A Process-Oriented Approach to Design Rationale".
Human-Computer Interaction 6 (3 & 4): 357–391.
23. Rittel, Horst W. J.; Noble, Douglas (January 1989). Issue-based information systems for
design (http://cumincad.architexturez.net/system/files/pdf/ca71.content.pdf) (PDF) (Technical
report). Berkeley, CA: Institute of Urban and Regional Development, University of California.
OCLC 20155825 (https://www.worldcat.org/oclc/20155825). 492.
24. McCall, R.J. (1991). "PHI: A Conceptual Foundation for Design Hypermedia". Design
Studies 12 (1): 30–41.
25. Maclean, A.; Young, RM.; Bellotti, VME.; Moran, T. (1996), "Questions, Options, and Criteria:
Elements of Design Space Analysis", in Moran, T.; Carroll, J., Design Rationale Concepts,
Techniques, and Use, Lawrence Erlbaum Associates, pp. 53-106
26. Lee, J. (1991), "Extending the Potts and Bruns model for recording design rationale",
Proceedings of the 13th International Conference on Software Engineering (ICSE '13), IEEE
Computer Society Press, Los Alamitos, CA, pp. 114-125
27. Burge, J. (2005), Software Engineering Using design RATionale (http://www.wpi.edu/Pubs/E
TD/Available/etd-050205-085625/), Worcester Polytechnic Institute, Computer Science Dept
28. Barry Boehm; Kitapci, H. (2006), "The WinWin Approach: Using a Requirement Negotiation
Tool for Rationale Capture and Use", in Dutoit, A.H.; McCall, R.; Mistrík, I. et al., Rationale
Management in Software Engineering, Springer Berlin Heidelberg, pp. 173-190
29. Barry Boehm (1998). "A spiral model of software development and enhancement" (http://ww
w.cs.usu.edu/~supratik/CS%205370/r5061.pdf). Computer 21 (5): 61–72
30. Bose, P. (1995). "A Model for Decision Maintenance in the WinWin Collaboration
Framework". Knowledge Based Software Engineering (KBSE '95).
31. Dutoit, A.; McCall, B.; Mistrik et al., eds. (2006), Rationale Management in Software
Engineering, Springer pp.1-48.
32. O. Zimmermann, C. Miksovic, J. Küster, Reference Architecture, Metamodel and Modeling
Principles for Architectural Knowledge Management in Information Technology Services (htt
p://soadecisions.org/download/SDA-JSS-SpecialIssueWICSA2011v16FinalAuthorsVersion.
pdf). Journal of Systems and Software, Elsevier. Vol. 85, Issue 9, Sept. 2012
33. Whelton, Michael; Ballard, Glenn; Tommelein, Iris (2007) Application Of Design Rationale
Systems To Project Definition – Establishing A Research Project. (http://www.leanconstructi
on.org/pdf/DesignRationaleSystemsandProjectDefinitionIGLC9.pdf) Archived (https://web.ar
chive.org/web/20070928113207/http://www.leanconstruction.org/pdf/DesignRationaleSyste
msandProjectDefinitionIGLC9.pdf) 2007-09-28 at the Wayback Machine Retrieved on 27
April 2007
34. Moran, T.; Carroll, J., eds. (1996), Design Rationale Concepts, Techniques, and Use,
Lawrence Erlbaum Associates,
35. Dutoit, Rationale Management in Software Engineering
Further reading
Books
Burge, JE; Carroll, JM; McCall R; Mistrík I (2008). Rationale-Based Software Engineering.
Heidelberg: Springer-Verlag.
Dutoit, AH; McCall R; Mistrík I; Paech B (2006). Rationale Management in Software
Engineering. Heidelberg: Springer-Verlag.
Conklin, J (2005). Dialogue Mapping. Weinheim: Wiley-VCH Verlag.
Kirschner, PA; Buckingham-Shum SJ; Carr CS (2003). Visualizing Argumentation: Software
Tools for Collaborative and Educational Sense-Making. London: Springer-Verlag.
Moran, T; Carroll J (1996). Design Rationale Concepts, Techniques, and Use. NJ: Lawrence
Erlbaum Associates.
Special Issues
Workshops
External links
Bcisive.austhink.com (http://bcisive.austhink.com): A commercial software package
designed for design rationale and decision rationale more broadly. Graphical interface,
sharing capabilities.
Compendium (https://web.archive.org/web/20110704173005/http://compendium.open.ac.uk/
institute/): A hypermedia tool that provides visual knowledge management capabilities
based around IBIS. Free Java application, binary and source, with an active user community
who meet annually.
designVUE (http://www3.imperial.ac.uk/designengineering/tools/designvue): A tool for visual
knowledge capture based on IBIS and other methods. Free Java application.
SEURAT (http://www.users.miamioh.edu/burgeje/SEURAT): An Eclipse plug-in that
integrates rationale capture and use with a software development environment. SEURAT is
available as an open source project in GitHub ([1] (https://github.com/burgeje/SEURAT)).