Design Rationale

In the survey on design rationale (DR) for software engineering [Jarczyk, Loffler & Shipman, Design Rationale for Software Engineering: A Survey] the authors give a very clear definition to design rationale, it is “the explicit listing of decisions made during a design process and the reasons why those decisions were made.” Later on, in Jintae Lee’s paper [Lee, Design Rationale Systems: Understanding the Issues] , he described the major features that should be included in a design rationale system: “they can include not only the reasons behind a design decision but also the justification for it, the other alternatives considered, the trade offs evaluated, and the argumentation that led to the decision.” However, John Horner and Michael E. Atwood complemented the above definitions in their paper [ Horner&Atwood, Effective Design Rationale] by asserting the primary goal of design rationale, that is “to support designers by providing a means to record and communicate the argumentation and reasoning behind the design process."In supporting the vision of design rationale, a lot of frameworks proposed, such as QOC, DRCS, IBIS, and DRL. Since design rationale system is used to support people to make design decisions, many other science areas and computer science fields are involved. In Horner & Atwood [ Horner&Atwood, Effective Design Rationale] , many cognitive issues are discussed, such as “wicked problems, group thinking, and situated action”. Design rationale system can strongly influence designers’ cognitive actions during the design process.Furthermore, design rationale is also related to Artificial Intelligence, in Burge and Brown’s paper [Burge & Brown, Reasoning with Design Rationale] a rationale inferencing system InfoRat is proposed. It is “a system that inferences over a design’s rationale in order to detect inconsistencies and to assess the impact of changes.” In addition, design rationale is involved in knowledge management as well. In Wang and Guangleng [Wang & Guangleng, Design Rationale as Part of Corporate Technical Memory] it is written that “Thus knowledge management has attracted attention of both companies and academia. Corporate memory is the computer systems to support enterprise knowledge management activities (identification, acquisition, storage, usage, communication, and development). Design rationale is a kind of knowledge which affects the core competence of manufacturing enterprises."

Background

While argumentation formats can be traced back to Stephen Toulmin's [Stephen Toulmin, The Uses of Argument, Cambridge, 1958 ] datums, claims, warrants, backings and rebuttals, the origin of design rationale can be traced back to Kunz and Rittel's [Kunz and Rittel, Issues as elements of information systems] development of the Issue Based Information Systems (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 [McCall, On the structure and use of issue systems in design] (although not named at the time). IBIS was also modified, in this case to support Software Engineering, by Potts & Bruns [Potts and Burns, Recording the reasons for design decisions] . The Potts & Bruns approach was then extended by the Decision Representation Language (DRL) [Lee, Extending the Potts and Bruns model for recording design rationale] which itself was extended by RATSpeak [Burge and Brown, Rationale support for maintenance of large scale systems] . Questions Options and Criteria (QOC), also known as Design Space Analysis [Mclean, Young, and Moran, Design rationale: the argument behind the artifact] [Maclean, Young and Bellotti, Questions, Options, and Criteria: Elements of Design Space Analysis] is an alternative representation for argumentation-based rationale, as are Win-Win [Boehm and Ross, Theory-W software project management: principles and examples] and the Decision Recommendation and Intent Model (DRIM) [Pena-Mora, Sriram and Logcher, SHARED-DRIMS: SHARED Design Recommendation-Intent Management System] .

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 [Dehlinger, Project STIEC: Systems Analysis of the Generation and Dissemination of Scientific and Technological Information in the European Community] . Rittel developed a small system in 1983 (also not published) and the better known gIBIS (graphical IBIS) was developed in 1987 [Conklin and Begeman, gIBIS: A hypertext tool for exploratory policy discussion] .

Not all successful DR approaches involve structured argumentation. Jack Carroll’s Scenario-Claims Analysis approach [Carroll and Rosson, Getting around the task-artifact cycle: how to make claims and design by scenario] captures rationale in scenarios that describe how the system is used and how well the system features support the user goals.

Note: most of the background information comes from e-mail messages received from Ray McCall, May 2007.

Key Concepts in Design Rationale

There are a number of ways to characterize DR approaches. Some key distinguishing features are how it is captured, how it is represented, and how it can be used.

Rationale Capture

Rationale Capture is the process of acquiring rationale information to a rationale management system.

Capture Methods
* A method called “Reconstruction” [Lee, Design Rationale Systems: Understanding the Issues] captures rationales in a raw form such as video, and then reconstruct them into a more structured form [Lee, Design Rationale Systems: Understanding the Issues] [Burge, Design Rationale, Technical Report] . 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 [Lee, Design Rationale Systems: Understanding the Issues] .
* The “Record-and-replay” [Lee, Design Rationale Systems: Understanding the Issues] 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” [Lee, Design Rationale Systems: Understanding the Issues] 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” [Lee, Design Rationale Systems: Understanding the Issues] 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” [Lee, Design Rationale Systems: Understanding the Issues] method, design rationales are automatically generated from an execution history at low cost [Lee, Design Rationale Systems: Understanding the Issues] [Burge, Design Rationale, Technical Report] . 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” [Chen, Design History Knowledge Representation and Its Basic Computer Implementation] method let a person or computer program watches all designer's actions but does not make suggestions. Rationales are captured during the design process. [Burge, Design Rationale, Technical Report] [Chen, Design History Knowledge Representation and Its Basic Computer Implementation]

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 [Lee, Design Rationale Systems: Understanding the Issues] . 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 [Lee, Design Rationale Systems: Understanding the Issues] .

One commonly accepted way for semiformal Design Rationale representation is structuring Design Rationale as argumentation [Burge and Brown, Reasoning with Design Rationale] . The earliest argumentation-based model used by many design rationale systems is the Toulmin model [Toulmin, The Uses of Argument] . The Toulmin model defines the rules of design rationale argumentation with six steps [Reynolds, What is the Toulmin Model?] : (1) Claim is made; (2) Supporting data are provided; (3) Warrant provides evidence to the existing relations; (4) Warrant can be supported by a backing; (5) model qualifiers(some, many, most, etc) are provided; (6) possible rebuttals are also considered. One advantage of Toulmin model is that it uses words and concepts which can be easily understood by most people. Another important approach to argumentation of Design Rationale is Rittel and Kunz’s IBIS (Issue-Based Information System) [Kunz and Rittel, Issues as elements of information systems] , which is actually not a software system but an argumentative notation. It is used and developed by gIBIS (graphical IBIS) and itIBIS (test-based IBIS) [Conklin and Yakemovic, A Process-Oriented Approach to Design Rationale] . IBIS uses some rationale elements (denoted as nodes) such as issues, positions, arguments, resolutions and several relationships such as more general than, logical successor to, temporal successor to, replaces and similar to, to link the issue discussions. PHI (Procedural Hierarchy of Issues) [McCall, PHI: A Conceptual Foundation for Design Hypermedia] extended IBIS to noncontroversial issues and redefined the relationships. PHI adds the subissue relationship which means one issue’s resolution depends on the resolution of another issue. QOC (Questions, Options, and Criteria) [Maclean, Young and Bellotti, Questions, Options, and Criteria: Elements of Design Space Analysis] is used for design space analysis. Similar to IBIS, QOC identifies the key design problems as questions and possible answers to questions as options. In addition, QOC uses criteria to explicitly describe the methods to evaluate the options, such as the requirements to be satisfied or the properties desired. The options are linked with criteria positively or negatively and these links are defined as assessments. DRL (Decision Representation Language) [Lee, Extending the Potts and Bruns model for recording design rationale] extends the Potts and Bruns model of DR [Potts and Burns, Recording the reasons for design decisions] and defines the primary elements as decision problems, alternatives, goals, claims and groups. In [Lee, Extending the Potts and Bruns model for recording design rationale] , the authors argues that DRL is more expressive than other languages. DRL focuses more on the representation of decision making and its rationale instead of on design rationale. Based on DRL, RATSpeak is developed and used as the representation language in SEURAT (Software Engineering Using RATionale) [Burge, Software Engineering Using design RATionale] . RATSpeak takes into account requirements (functional and non-functional) as part of the arguments for alternatives to the decision problems. And there is an Argument Ontology which is a hierarchy of argument types and includes the types of claims used in the system. The WinWin Spiral Model, which is used in the WinWin approach [Boehm and Kitapci, The WinWin Approach: Using a Requirement Negotiation Tool for Rationale Capture and Use] , adds the WinWin negotiation activities, including identifying key stakeholders of the systems, and identifying the win conditions of each stakeholder and negotiation, into the front of each cycle of the spiral software development model [Boehm, A spiral model of software development and enhancement] in order to achieve a mutually satisfactory (winwin) agreement for all stakeholders of the project. 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 [Boehm and Kitapci, The WinWin Approach: Using a Requirement Negotiation Tool for Rationale Capture and Use] . The WinWin Spiral model reduces the overheads of the capture of Design Rationale by providing stakeholders a well-defined process to negotiate. In [Bose, A Model for Decision Maintenance in the WinWin Collaboration Framework] , 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. DRIM (Design Recommendation and Intent Model) is used in SHARED-DRIM [Pena-Mora, Sriram and Logcher, SHARED-DRIMS: SHARED Design Recommendation-Intent Management System] . The main structure of DRIM is a proposal which consists of the intents of each designer, the recommendations that satisfy the intents and the justifications of the recommendations. Negotiations are also needed when conflicts exist between the intents of different designers. The recommendation accepted becomes a design decision, and the rationale of the unaccepted but proposed recommendations are also recorded during this process, which can be useful during the iterative design and/or system maintenance.

Rationale Uses

Design rationale has the potential to be used in many different ways. One set of uses, defined by Burge and Brown (1998) [Burge, Design Rationale] , 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 [Dutoit,Rationale Management in Software Engineering,1-48] . 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 [Whelton,Application Of Design Rationale Systems To Project Definition – Establishing A Research Project] .

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 [Dutoit,Rationale Management in Software Engineering,1-48] .

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 [Burge,Reasoning with Design Rationale,611-629] . In some cases DR could save time and money when a software system is upgraded from its previous versions [Jarczyk,Design Rationale for Software Engineering: A Survey,577 - 586] .

Rationale Approaches

There are several books and articles that provide excellent surveys of rationale approaches applied to HCI [Moran, Design Rationale Concepts] , Engineering Design [ Lee, Design Rationale Systems, 78-85 ] , and Software Engineering [Dutoit, Rationale Management in Software Engineering ] .

Notes

References

cite journal | last = Bose | first = P.
title = A Model for Decision Maintenance in the WinWin Collaboration Framework
journal = Knowledge Based Software Engineering (KBSE '95) | date = 1995

cite journal | last = Boehm | first = B.
title = A spiral model of software development and enhancement
journal = Computer | volume = 21 | issue = 5 | pages = 61–72 | date = 1998
doi = 10.1109/2.59

cite journal | last = Boehm | first = B. | last2 = Ross | first2 = R
title = Theory-W software project management: principles and examples.
journal = IEEE Transactions on Software Engineering | volume = 18 | issue = 7 | pages = 902-916 | date = 1989

Citation
first = B. | last = Boehm
first2 = H. | last2 = Kitapci
editor-last = Dutoit | editor-first = A.H.
editor2-last = McCall | editor2-first = R.
editor3-last = Mistrík | editor3-first = I.
editor4-last = Paech | editor4-first = B.
contribution = The WinWin Approach: Using a Requirement Negotiation Tool for Rationale Capture and Use
title = Rationale Management in Software Engineering
year = 2006 | pages = 173-190 | publisher = Springer Berlin Heidelberg

Citation
last = Burge
first = J.
first2 = D.C. | last2 = Brown
title =Design Rationale: Types and Tools, Technical Report
location = Worchester Polytechnic Institute, Computer Science Dept.,
year = 1998
url = http://web.cs.wpi.edu/Research/aidg/DR-Rpt98.html
accessdate = 2007-04-27

Citation
first = J.E. | last = Burge
first2 = D.C. | last2 = Brown
editor-last = Gero | editor-first = J.
contribution = Reasoning with Design Rationale
title = Artificial Intelligence in Design '00
pages = 611–629
publisher = Kluwer Academic Publ.
location = Netherlands
year = 2000

Citation
first = J. | last = Burge
first2 = D.C. | last2 = Brown
contribution = Integrating Design Rationale with a Process Model
title = Workshop on Design Process Modeling,Artificial Intelligence in Design '02
location = Cambridge, UK
year = 2002

Citation
first = J. | last = Burge
first2 = D.C. | last2 = Brown
contribution = Rationale Support for Maintenance of Large Scale Systems
title = Workshop on Evolution of Large-Scale Industrial Software Applications (ELISA), ICSM '03
location = Amsterdam, NL
year = 2003

Citation
last = Burge
first = J.
title = Software Engineering Using design RATionale
location = Worchester Polytechnic Institute, Computer Science Dept.,
year = 2005
url = http://www.wpi.edu/Pubs/ETD/Available/etd-050205-085625/

cite journal | last = Carroll | first = JM | last2 = Rosson | first2 = M
title = Getting around the task-artifact cycle: how to make claims and design by scenario
journal = ACM Trans. Inf. Syst. | volume = 10 | issue = 2 | pages = 181-212 | date = 1992

Citation
first = A. | last = Chen
first2 = B. | last2 = McGinnis
first3 = D. | last3 = Ullman
first4 = T. | last4 = Dietterich
contribution = Design History Knowledge Representation and Its Basic Computer Implementation
title = The 2nd International Conference on Design Theory and Methodology
location = Chicago, IL
year = 1990
pages = 175-185

cite journal | last = Conklin | first = J. | first2 = M. | last2 = YakemBegemanovic
title = gIBIS: A hypertext tool for exploratory policy discussion
journal = ACM Transactions on Office Information Systems | volume = 6 | issue = 4 | pages = 303-331
date = 1988

cite journal | last = Conklin | first = J. | first2 = K. | last2 = Yakemovic
title = A Process-Oriented Approach to Design Rationale
journal = Human-Computer Interaction | volume = 6 | issue = 3 & 4 | pages = 357–391 | date = 1991
doi = 10.1207/s15327051hci0603&4_6

Citation
last = Dehlinger
first = H.
title = 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
location = Heidelberg/Stuttgart
year = 1978

Citation
first = A.H. | last = Dutoit
first2 = R. | last2 = McCall
first3 = I. | last3 = Mistrík
first4 = B. | last4 = Paech
editor-last = Dutoit | editor-first = A.H.
editor2-last = McCall | editor2-first = R.
editor3-last = Mistrík | editor3-first = I.
editor4-last = Paech | editor4-first = B.
contribution =Rationale Management in Software Engineering: Concepts and Techniques
title = Rationale Management in Software Engineering
year = 2006 | pages =1-48 | publisher = Springer Berlin Heidelberg

Citation
editor-last = Dutoit | editor-first = A.
editor2-last = McCall | editor2-first = R.
editor3-last = Mistrik | editor2-first = I.
editor4-last = Paech | editor2-first = B.
title =Rationale Management in Software Engineering
year = 2006 | publisher = Springer

Citation
first = G. | last = Fischer
first2 = A. | last2 = Lemke
first3 = R. | last3 = McCall
first4 = A. | last4 = Morch
editor-last = Moran | editor-first = T.
editor2-last = Carroll | editor2-first = J.
contribution = Making Argumentation Serve Design
title =Design Rationale Concepts, Techniques, and Use
year = 1996 | pages =267-293 | publisher = Lawrence Erlbaum Associates

Citation
first = J. | last = Horner
first2 = M.E. | last2 = Atwood
editor-last = Dutoit | editor-first = A.H.
editor2-last = McCall | editor2-first = R.
editor3-last = Mistrík | editor3-first = I.
editor4-last = Paech | editor4-first = B.
contribution =Effective Design Rationale: Understanding the Barriers
title = Rationale Management in Software Engineering
year = 2006 | pages =73-90 | publisher = Springer Berlin Heidelberg

Citation
last = Jarczyk
first = Alex P.
last2 = Löffler
first2 = Peter
last3 = Shipman III
first3 = Frank M.
contribution = Design Rationale for Software Engineering: A Survey
title = 25th Hawaii International Conference on System Sciences
volume = 2
pages = 577-586
year = 1992

Citation
last = Kunz
first = W.
first2 = H. | last2 = Rittel
title =Issues as elements of information systems. Working Paper 131
location = Center for Urban and Regional Development, University of California Berkley
year = 1970

Citation
first = J. | last = Lee
contribution = Extending the Potts and Bruns model for recording design rationale
title = Proceedings of the 13th International Conference on Software Engineering (ICSE '13)
year = 1991 | pages = 114-125 | publisher = IEEE Computer Society Press, Los Alamitos, CA

cite journal | last = Lee | first = J.
title = Design Rationale Systems: Understanding the Issues
journal = IEEE Expert | volume = 12 | issue = 3 | pages = 78–85 | date = 1997
doi = 10.1109/64.592267

Citation
first = A. | last = Maclean
first2 = RM. | last2 = Young
first3 = T. | last3 = Moran
contribution = Design rationale: the argument behind the artifact
title = SIGCHI Bull. 20
year = 1989 | pages = 247-252114-125

Citation
first = A. | last = Maclean
first2 = RM. | last2 = Young
first3 = VME. | last3 = Bellotti
first4 = T. | last4 = Moran
editor-last = Moran | editor-first = T.
editor2-last = Carroll | editor2-first = J.
contribution = Questions, Options, and Criteria: Elements of Design Space Analysis
title =Design Rationale Concepts, Techniques, and Use
year = 1996 | pages = 53-106 | publisher = Lawrence Erlbaum Associates

cite journal | last = McCall | first = R.J.
title = PHI: A Conceptual Foundation for Design Hypermedia
journal = Design Studies | volume = 12 | issue = 1 | pages = 30–41 | date = 1991
doi = 10.1016/0142-694X(91)90006-I

Citation
last = McCall
first = R.
title = On the structure and use of issue systems in design, Doctoral Dissertation
location = University of California, Berkeley, University Microfilms
year = 1978 Citation
editor-last = Moran | editor-first = T.
editor2-last = Carroll | editor2-first = J.
title =Design Rationale Concepts, Techniques, and Use
year = 1996 | publisher = Lawrence Erlbaum Associates

Citation
first = F. | last = Pena-Mora
first2 = D. | last2 = Sriram
first3 = R. | last3 = Logcher
contribution = SHARED-DRIMS: SHARED Design Recommendation-Intent Management System
title = Proceedings Enabling Technologies Infrastructure for Collaborative Enterprise
year = 1993 | pages = 213-221 | publisher = IEEE Press, Morgantown, WV

Citation
first = C. | last = Potts
first2 = G. | last2 = Burns
contribution = Recording the reasons for design decisions
title = 10th International Conference on Software Engineering (ICSE '1988)
year = 1988
pages = 418-427

Citation
last = Reynolds
first = Chris
title = What is the Toulmin Model?
year = 2000
url = http://www.concentric.net/~Creyn266/COMM335/Toulmin.htm

cite journal | last = Rittel | first = H.W.J.
title = On the planning crisis: Systems analysis of the first and second generations
journal = Bedriftsokonomen | volume = 8 | pages = 390–396 | date = 1972

cite book
last = Toulmin | first = S. | title = The Uses of Argument
publisher = Cambridge University Press | date = 1958 | location = Cambridge

citation | last1 = Xin | first1 = W.
last2 = Guangleng | first2 = X.
contribution = Design Rationale as Part of Corporate Technical Memory
title = Systems, Man and Cybernetics | pages = 1904 - 1908 | date = 2001

Citation
last1 = Whelton | first1 = Michael
last2 = Ballard | first2 = Glenn
last3 = Tommelein | first3 = Iris
title = Application Of Design Rationale Systems To Project Definition – Establishing A Research Project
url = http://www.leanconstruction.org/pdf/DesignRationaleSystemsandProjectDefinitionIGLC9.pdf
accessdate = 2007-04-27

Further reading

Books

Special Issues

Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM),Special Issue: Fall 2008, Vol.22 No.4 Design Rationale http://web.cs.wpi.edu/~aiedam/SpecialIssues/Burge-Bracewell.html

Artificial Intelligence for Engineering Design, Analysis and Manufacturing (AIEDAM),Special Issue on Representing and Using Design Rationale, 1997, Vol.11 No.2, Cambridge University Press

Workshops

Second Workshop on SHAring and Reusing architectural Knowledge - Architecture, rationale, and Design Intent (SHARK/ADI 2007) [http://www.cs.rug.nl/~paris/SHARK-ADI2007] , as part of the 29th Int. Conf. on Software Engineering (ICSE 2007) [http://web4.cs.ucl.ac.uk/icse07]

Workshop on Design Rationale: Problems and Progress [http://www.users.muohio.edu/burgeje/DRWorkshopDCC06.html] Workshop Chairs: Janet Burge and Rob Bracewell Held 9 July 2006 in conjunction with Design, Computing, and Cognition '06. Eindhoven [http://wwwfaculty.arch.usyd.edu.au/kcdc/conferences/dcc06/] , Netherlands

External links

Rationale Systems

[http://bcisive.austhink.com bCisive] : A commercial software package designed for design rationale and decision rationale more broadly. Graphical interface, sharing capabilities.

[http://compendiuminstitute.org Compendium] : 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.

[http://www.users.muohio.edu/burgeje/SEURAT SEURAT] : An Eclipse plug-in that integrates rationale capture and use with a software development environment.