A Survey of Design Rationale Systems: Approaches ... · A Survey of Design Rationale Systems 211...

Engineering with Computers (2000) 16: 209–235 2000 Springer-Verlag London Limited

A Survey of Design Rationale Systems: Approaches, Representation,Capture and Retrieval

W. C. Regli1, X. Hu2, M. Atwood3 and W. Sun21Geometric and Intelligent Computing Laboratory, Department of Mathematics and Computer Science, Drexel University.Philadelphia, PA, USA;2Rapid Product Development Center, Department of Mechanical Engineering and Mechanics, DrexelUniversity, Philadelphia, PA, USA;3College of Information Science and Technology, Drexel University, Philadelphia, PA, USA

Abstract. This paper provides a survey on recent researchin the area of design rationale. The study of design rationalespans a number of diverse disciplines, touching on conceptsfrom research communities in mechanical design, softwareengineering, artificial intelligence, civil engineering, com-puter-supported cooperative work, and human-factors andhuman-computer interaction research. We focus this surveyon prototype design rationale systems for these applicationdomains, and put forward several major criteria with whichto describe and classify design rationale systems, includingargumentation-based, descriptive, process-based approaches.Further, we attempt to abstract the place of systems andtools for design rationale capture and retrieval in the contextof contemporary knowledge-based engineering and Com-puter-Aided Design (CAD) tools. This survey is structuredaround classes of fundamentally different approaches, theirrepresentation schema, their capture methods and retrievaltechniques. A number of recent design rationale systems,including JANUS, COMET, ADD. REMAP, HOS, PHIDIAS,DRIVE and IBIS are analysed. We conclude with an assess-ment of current state-of-the-art and a discussion of criticalopen research issues.

Keywords. Design history; Design intent; Designrationale capture; Engineering design process;Knowledge management; Software design; Userinterface design

1. Introduction

Design rationale is an explanation of why an artifact,or some part of an artifact, is designed the way itis [1]. Design rationale includes all the backgroundknowledge such as deliberating, reasoning, trade-off

Correspondence and offprint requests to: Professor W. Regli,Department of Mathematics and Computer Science, Drexel Uni-versity, Korman Center, Rm 238, Philadelphia, PA 19104, USA.E.mail: regl:@drexel.edu

and decision-making in the design process of anartifact – information that can be valuable, evencritical, to various people who deal with the artifact[2–6]. These views are consistent across the wholespectrum of engineering design disciplines, frommechanical design and architecture-engineering-construction to software and user-interface design.

Usually a developed artifact is defined in termsof specifications and parameters to describe the wayit works, but does not include a description ofwhyit is designed the way it is. Design rationale isusually not documented completely, and the colla-borating work teams often need considerableamounts of communication to understand others’work [7]. Activities to maintain and redesign theartifact require much effort to understand the pre-vious work. Many believe that keeping track of thedesign rationale will provide a great aid to designers:it helps to structure design problems, and providesa basis for designers to explore more design options.Design rationale systems can be used as a basis todiscuss and reason among collaborating designers:to record the history of design process; to modifyand maintain existing designs, or design similarartifacts [8,9].

Much progress has been made on the developmentof design rationale approaches and tools since theearly 1980s. The research has ranged from basicobservations about the design process [10] to differ-ent approaches to capturing design rationale. In thisprevious work, basic concepts were discussed andframeworks for design rationale were proposed. Anumber of important prototypes have beendeveloped, but few design rationale systems havemade it into practical use in industry. To this end,the fundamental goal of this survey paper is toanswer the questions:

I If design rationale is useful (most agree on this

210 W. C. Regliet al.

point), why are design rationale systems not inwidespread use in industry?

I How can design rationale systems better supportengineering design?

I What are the major obstacles to the creation oftruly useful and usable design rationale systems?

For a more comprehensive background reference ofthe design rationale field, interested readers arereferred to the excellent 1996 edited collection byMoran and Carroll [11], as well as discipline-specificoverview papers [12,13]. Recent research has a tend-ency to combine design rationale systems with otherforms of design support tools [14,15]. Lee’s [12]recent article describes some of the major openissues in design rationale research. We present thispaper as a system-centred overview, with the goalof helping current and future builders of designrationale support environments sort through themany issues of system development. Furthermore,we put forth presently outstanding issues for designrationale research and practical system deploymentand use.

This survey is organised as follows. Section 2gives the framework of the survey, basic concepts ofdesign rationale are introduced and design rationalesystems or prototypes are reviewed in chronologicalorder and summarised. Section 3 describes basicapproaches to design rationale. Section 4 describesthe representation schema of design rationale sys-tems. Sections 5 and 6 describes the capture andretrieval of design rationale, respectively. Section 7touches on some of the related research areas thatsupport the study of design rationale. Section 8provides brief examples of several different usesand applications for design rationale systems. InSection 9, we summarise our review, and discussthe open research issues that must be addressedto advance the state-of-the-art in design rationalesystems.

2. A Framework for Design Rationale

The research on design rationale covers a largerange of topics; this survey focuses on the reviewand analysis of existing systems and prototypes. Inthis context, a design rationale system intends tolet designers think and discuss design within acertain knowledge representation framework.

Figure 1 illustrates how a prototypical designrationale system works. Based on arepresentationschema, the decisions and reasoningare eitherrecordedby designers themselves using documents,

Fig. 1. Flow of information in a design rationale system frame-work.

or capturedby a design rationale system’s monitor-ing module. The capture of design rationale canoccur from the design teams’ communications viaComputer-Supported Cooperative Work (CSCW)tools, such as electronic mail, phone conversions,and archived design meetings and designers’ note-books. The design knowledge captured is organisedby rules, which are primarily determined by arep-resentation schema, and stored into thedesignrationale sytemknowledge-base – to then be usedin later design activities. If a design is similar toan existing design, the design rationale for the for-

211A Survey of Design Rationale Systems

mer design can be retrieved from the design ration-ale database, providing the suggestions and ideasrelevant for the current design task. Some systems(e.g. the CRACK system [16]) also include critiqu-ing tools, which are based on domain knowledgeand can justify design decisions. Generally, a designrationale system is supported by knowledge-basedsystems and Computer-Aided Design and Manufac-turing (CAD/CAM) systems, opening up a widerange of possibilities in supporting design activities.

We break the core of our survey down based onmajor systems and prototypes, and examine the fourfollowing issues.

Approaches to developing design rationale systems.Since the first approach to design rationale wasproposed in 1970 [17], various other approacheshave been developed. The main approaches arepro-cess-orientedand feature-oriented. In fields with arelatively high degree of standardisation, the feature-oriented approach is frequently used. Feature-oriented approaches focus on the representation ofartifacts and the body of established rules governingthe design process. In dynamic design domains, inwhich accepted design principles may not be wellestablished, the process-oriented approach is oftenused to create a historical representation of thedesign process [2,3]. The integration of designrationale systems with other design support tools(knowledge-based, CAD and collaborative work)also influences the approach.

Representation schema for design rationale. Adesign rationale representation explicitly documentsthe reasoning and argumentation occurring in design[5]. The representation determines the methods usedto capture and retrieve the design rationale, so it isimportant to select an appropriate representationschema.

Argumentation-based design rationaleis a mainlyrepresentational approachwhich uses a semi-formalgraphical format [2] for laying out the structure ofarguments. It uses a node-and-link representation,which means it uses typed links to interconnecttyped nodes [18]. A node represents a component,while a link represents a relationship. With argumen-tation, designers can easily maintain consistency indecision-making, keep track of decisions, and com-municate about design reasoning with each other.The most common argument structures for selectingand organising information are IBIS, PHI, QOCand DRL.

Some systems use adescriptive approach[3] torepresent design rationale, which records the history

of design activities, work flow and communicationbetween designers [18]. More specifically, it recordswhat decisions are made, when they are made, whomade them, and why [18]. This approach is usedin dynamic design domains, in which the problemsare vague and the solution technology is poorlyunderstood, and therefore little or no standardisationof designed artifacts exists. The descriptive approachemphasises minimising the intrusion to designers bymaking design rationale capture as transparent aspossible. This makes re-usability of the designrationale incidental [3].

Capture of design rationale. In a design process,design rationale is captured by recording reasoning,decisions, options, trade-offs, etc., and constructinga formal [9] or semi-formal structure [2] so that thedesign rationale can be used in the decision-makingprocess during design.

Determining what information to capture duringdesign, and how to capture it, is a fundamentalproblem many have tried to address. Gruber [19]proposed that rationale support tools should focuson capturing the information that is used to answerdesigners’ questions, as well as data that might beused to infer answers to later questions. The depen-dency relations among the data and information arevery useful, and should be captured as well. In thisenvironment, rationale explanations are constructedin response to information requests, from back-ground knowledge and information captured duringdesign.

Applying this philosophy in a design environmentusing traditional CAD drawing tools, which arefocused on detailed design and only capture dataabout the physical or logical aspects of an artifact,the design rationale support tools should captureinformation such as the intended behaviour or func-tion of a device, and the justification for designdecisions [4].

The design rationale capture process generallyconsists of two steps:knowledge recordinganddesign rationale construction. The first involvescapturing as much raw information as possibleduring the design process. The second step is theextraction, organisation and storage of rationaleknowledge, which is based on the design rationalerepresentation schema and constraints in the designdomain. We observed that the recording and con-struction processes have been implemented indesign rationale systems through bothautomaticcaptureapproaches and those requiringuser-inter-vention (in which designers are required to input


or record the design discussions, decisions andreasonings themselves).

Retrieval of design rationale. The retrieval of designrationale is determined by the representation schemaand the requirements of the engineering domain forwhich the knowledge is being used. At each differ-ent design stage, there are various purposes foraccessing design rationale: to answer a user query,to show the logical aspects of an important issue,to monitor design process, or to get a documentabout the designed artifact [31,27,33]. Differentaccess strategies are needed to help users with differ-ent purposes. The retrieval of design rationale canbe active or passive. It is desirable that some designrationale retrieval be triggeredautomaticallyaccord-ing to the design context [24].

Given a representation schema, tools supportingfunctions such asnavigation by designers[16] andretrieval strategies[27] can be implemented. Theintegration of design rationale systems with otherdesign support systems can greatly improve theretrieval of design rationale. The retrieval of designrationale in such systems is usually involved in thedesign reasoning process, and supported byknowledge-bases in the design support systems.

A design rationale system is not effective as astandalone system. Together with other design sup-port systems, such as CAD or Computer-AidedSoftware Engineering (CASE) tools, it contributesto the design process by providing designers with aknowledge representation framework, as well astools to capture design rationale, design reasoningand communication during the design process. Ide-ally, such systems can transform raw design ration-ale and design history into knowledge for later re-use – providing facilities to retrieve design rationalewhen needed for review, maintenance or redesign.Figure 2 shows the architecture of a general designrationale system, generated from our survey by syn-thesising the functions of different systems. Thedesign rationale systems or prototypes that wereviewed generally did not include all of the featuresindicated in the diagram.

To provide a general view of the development ofthe research area, we list the design rationale sys-tems reviewed (in chronological order) according tothe catalogue described above in Table 1. Eachsystem is described in five dimensions:knowledgerepresentation, capture, retrieval, approachand theapplication domain. The following sections will con-centrate on a detailed discussion of the systems inthe table.

3. Approaches to Building DesignRationale Systems

At different stages of the design process of anartifact, design can be moreprocess-orientedormore feature-oriented. At the initial design stage, asthe design progresses from the requirements to aconceptual design, there are many discussions con-cerning the requirements (which may not be wellspecified), and much exploration of options andtrade-offs since there may be no fixed solution path[34]. This design process is more dynamic, withknowledge organised according to design progress,so the approach of design rationale at this stage ismore process-oriented. At the detailed design stageor in routine design, design process is more con-strained by the rules in the field or domain knowl-edge, since it is feature-oriented, [24,32], in whichfeatures could be function, performance, design,manufacture or implementation. These differences inthe characteristics of the two different phases ofdesign naturally lead to the two different approachesto design rationale.

3.1. Process-Oriented Approaches

Process-oriented design rationale systems emphasisethe design rationale as ahistory of the design pro-cess. Process-oriented design rationale has been mostoften used in domains where the problems arevague, the solution technology is poorly understood,or both, and in which there is little or no standardis-ation of designed artifacts [3]. Unlike feature-ori-ented systems, which construct design rationale asa logical structure, design rationale is merelydescriptive in a process-oriented system. Most exist-ing design rationale systems are process-oriented,with issues, options and arguments captured andorganised according to the design progress.

This approach originated from the Issue-BasedInformation System (IBIS) framework for argumen-tation [17]. A number of other frameworks havebeen developed since then, including DRL [1] andPHI [20].

The representation schema of this kind of ration-ale is generally graph-based, using nodes and links,with nodes indicating issues (questions), positions(options) and arguments, and links indicating therelationships among the nodes. This kind of rep-resentation schema provides a flexible structure andgreat convenience in recording design rationale fromcommunications of design progress. This isespecially true for multimedia communications, since


Fig. 2. The general architecture of a design rationale system.

multimedia nodes could be included as part of thedesign schema [26,18].

Figure 3 shows an example of the process-basedapproach to design rationale. In this example, amaterial handling system is being planned for amanufacturing plant in design. At this initial designstage, there is only a functional specification, withno restrictions on the step-by-step evolution of thedesign. With the process-based approach to designrationale, the step-by-step reasoning is captured andrepresented according to different tasks in the func-tional specification. An IBIS schema is used herefor design rationale representation.

The challenge with this approach is to convertthe captured information intostructured designrationale – to create links among nodes – to makethe information accessible. A number of approacheshave been used to create links among nodes: PHID-IAS [18] links the nodes by authoring and indexing;REMAP/MM [26] supports hyper-links amongdesign deliberation records and multimedia objects.This conversion process presents a large overheadto the design rationale maintainer (a smart computeror a patient human being). Another method toorganize the recorded information is incrementalformalisation, described in Shipman and McCall[35].

Once the nodes are linked, design rationale reusebecomes a matter of retrieval of the knowledge. The

rationale could be viewed by traversing from onenode to another by way of links, or be retrieved inresponse to queries. There are a number of tech-niques to deal with this; more detailed informationon retrieval is given in Section 6.

The process-oriented approach to design rationalehelps designers by providing descriptive historyinformation, to answer questions such as who, why,what and when. Currently, it is not easy to translatethis into representations that can be understood andprocessed by computers, so this approach providessupport to the design process only when designersaccess and understand it [21].

3.2. Feature-Oriented Approaches

A feature-orientedapproach starts from the designspace of an artifact, where the rules and knowledgein the specific domain must be considered in designdecision making. A design decision not supportedby the rules of knowledge needs to be confirmed, soit will cause a revision of the rules and knowledge inthe domain [24].

A feature-oriented system is usually developed ina task specific contextusing an empirical study.Some models are extended from genericDesignDecision Support(DDS) systems by adding primi-tives to explicitly represent design process. Gener-


Table 1. Table of prototype design rationale systems.

System Name Knowledge Knowledge Knowledge Approach Design Domain YearAcronym Representation Capture Retrieval

IBIS [17] Issue-based UI Navigate PO Generic 1970PHI [20] Extending IBIS UI Navigate PO Generic 1987QOC [5] Design Space Analysis UI Navigate PO Generic 1990DRL [1] Representing elements UI Navigate PO Generic 1991

of decision makingCRACK [16] N/A Auto Trigger FO Kitchen 1989VIEWPOINTS [16] IBIS N/A Navigate FO Kitchen 1989JANUS [21] PHI Auto Hybrid FO Kitchen 1989IBIS-style browser IBIS Auto Navigate PO Generic 1991[22]COMET [23] LOOM UI Navigate FO Sensor-based tracker 1992

softwareADD [24] Argumentation & UI Trigger FO HVAC 1992

Model-basedREMAP [25] IBIS UI Query PO Generic 1992REMAP/MM [26] IBIS Auto Query PO Generic 1995ADD1 [27] Rhetorical Structure UI Query PO HVAC 1997HOS [18] PHI Auto Trigger PO Generic 1997PHIDIAS [18] PHI Auto Trigger FO 2D, 3D 1997

POKBDS-IBIS [14,15] IBIS UI Query & FO Chemical Plant 1997

Navigate PODRIVE [28] PDN UI Query FO Building 1997DRARS [29] QOC N/A N/A FO Building 1995KRITIK [30,9] SBF UI Query FO Mechanical 1993IDIS [31] IBIS UI Navigate FO Chemical Plant 1998RCF [32] N/A Auto N/A PO N/A 1999

Capture Method: User-Intervention (UI) or Automatic (Auto)Representation Method: Feature-Oriented (FO) or Process-Oriented (PO)Retrieval Method: Navigate, Query, Trigger or Hybrid.

Fig. 3. An example of process-based approach: the planning ofa material handling system for a manufacturing plant.

ally, these kinds of systems contain domain knowl-edge-bases, which can be used to support automatedreasoning. CRACK is a typical feature-oriented sys-tem [16]; its detailed description can be found inthe following sections.

In a feature-oriented design rationale system,existing knowledge-bases usually support the gener-ation of design rationale, so representations of designrationale are usually more formal than in process-oriented systems. In some systems, the designrationale is represented with links to the existingknowledge-base. The retrieval and reuse of designrationale is very natural in the design process oflater artifacts. An example model is GTMD [36],which is used to structure the acquisition process

within DESIRE, a formal framework for compo-sitional modelling.

With this approach, design rationale systems areusually included in the design systems. This helpsdesigners by storing design rationale in a formalformat which can be processed automatically, so itcan provide active support to design or redesignprocesses such as the evaluation of design decisionsand conflict resolution [28].

While the feature-oriented design rationaleapproach provides active support to design activities,it has the limitation that only part of design rationale(i.e. how the artifact designed satisfies therequirements) can be handled: other parts (i.e.option-exploration, trade-off, who, when, why, etc.)cannot be handled with this approach [30].

Combinations of both of these approaches havebeen proposed to help overcome their individuallimitations. Systems with such a hybrid approachnot only provide logical structure for design ration-ale, but also record the history of the design process.KBDS-IBIS is such an example [14].


3.3. Integration with Other Design SupportSystems

A design rationale system is usually positioned asa technology to augment Computer Aided Design(CAD) and other engineering activities. In this way,it is not intended as a stand-alone system. Its smoothintegration with other design support systems affectsits effectiveness and efficiency. Figure 2 gives ageneral view of the integration of design rationalesystems with other systems.

There is a trend towards tight integration of designrationale tools with other design representations [2],with the design rationale system being treated as anextension of the design system. Design rationalesystems integrated with commercial CAD systemhave been extensively reported [14,31,32,27,24,37,26,18]. In some of these systems, the integrationwas achieved by the combination of design rationalesystem with knowledge-based design decision sup-port systems [31,27,37,26]. To integrate designrationale tools with design systems, there shouldbe an integration of representation schemas. Thisimproves the design system, makes the implemen-tation of design rationale easier [9], and makes thecapture and retrieval of design rationale driven byimplementation concerns. The integration of designrationale with Computer Supported CooperativeWork (CSCW) and telecommunications was reportedin PHIDIAS [26,18].

Sections 4–6 give a more detailed discussion onrepresentation schema, capture and retrieval.

4. Representation Schemas

Due to the increasing complexity of computer sys-tems and demand for higher reliability, there is agrowing interest in developing design systems tohelp designers record and re-use design rationale.Especially for the design and maintenance of largesystems (such as software systems), the capture andre-use of design rationale information system canbe essential over the life-span of the product.Designing an artifact involves considering manyalternatives – where one must address, evaluate, andultimately accept or reject each alternative. A designrationale system needs to record the analysis of thevarious alternatives so that designers can easilymake their decision; after designing, the rationalefor a design should be kept for future use. How toorganise this enormous amount of diverse material,and build it into a usable structure, is a criticalissue [2]. A goodrepresentation schemais vital to

enabling effective design and reuse. Much attentionhas been focused on developing methods, notationsand tools for recording rationales, the space orhistory of arguments surrounding the actual decisionmade as development progress is represented. Anoverview of some of the most prominent techniquesis given in the following sections.

4.1. The Issue-Based Information System(IBIS)

The Issue-Based Information System (IBIS) uses anissue-basedapproach that has been used in architec-tural design, city planning and public-policy dis-cussion. The key issues of IBIS are usually articu-lated as questions, with eachissue followed by oneor more positions that respond to the issue. Eachposition can potentiallyresolveor be rejected fromthe issue.Argumentseither support or object to aposition. Figure 4 shows the relationship amongthree elements in IBIS. An IBIS-style browser [22]is the implementation of a merged issue-based andtruth-maintenance[38] dependency structure. Suchbrowsers use a graphical shorthand to represent nodetypes and link types in a graph-based structure.Issues, positions and arguments are the main compo-nents captured in the graph. One characteristic ofsuch a system is that it can provide immediatefeedback to designers by indicating the belief statusof various issues (via colour or other notations onthe nodes).

The Representation and Maintenance of Processknowledge (REMAP) system [25] uses theTeloslanguage to represent knowledge, and is also basedon the Issue Based Information Systems (IBIS)method. The history about design decisions in thedevelopment life-cycle is calledprocess knowledge.Much of this knowledge, involving the deliberationon alternative requirements and design decision, is

Fig. 4. The relationship of issue, position and argument.


lost in the course of designing and changing suchsystems. REMAP records the argumentation relatedto deliberations and solves the process knowledgeloss problem. As the deliberation proceeds amongdesigners during the design process. REMAP listsvarious issues, such as a problem, a concern or aquestion that requires discussion for the problemsolving to progress; positions (alternatives) for solv-ing each issue are responded using a process modelwindow, each of these positions has different sup-porting arguments, each of which in turn is sup-ported by assumptions. Issues are resolved by mak-ing a decision to select a position, thereby leadingto a constraint that needs to be satisfied by designobjects. Therefore, process knowledge is related tothe objects that are created during the requirementsengineering process.

Researchers have recognised that an explicit rec-ord of design rationale is an important requirementfor effective design support. As computer systemssupporting all aspects of the design process evolved,many have pursued integrating the record of ration-ale with the history of the evolution of the designartifact [39,40]. An integration of these two disjointdata models could bring many benefits for design,such as improved documentation of the design pro-cess and the verification of the design methodologyand the resulting design artifact.

The Knowledge Based Design System-IBIS(KBDS-IBIS) [14] is the result of integrating arepresentation of design rationale (in the form ofIBIS networks) to the design alternative historymaintained by a design support system (KBDS).KBDS-IBIS has been used in chemical process plantdesign, and put forward some extensions to thestructure of standard IBIS networks. KBDS-IBISintroduced three new classes of object –artifacts,steps and tests. These integrate the representationof argumentationwith the design process history.KBDS-IBIS also can automatically generate twotypes of reports:step reports, which describe thedesign rationale for the evaluation of one designalternative relative to another;issues reports,describing the deliberation leading to a particulardesign. These record in a prescriptive fashion –allowing the design team to identify which partsmust be re-designed in the light of a change in theinternal assumptions, constraints or specification, ora change in any external factors affecting the design.In an integrated and prescriptive form, KBDS-IBISexplicitly maintains the history of the design goals,decisions, justifications and assumptions coupledwith the evolving description of a chemical processplant during its conceptual design.

Chung [31] described an Integrated Design Infor-mation System (IDIS) that supports the design ofchemical plants. This system also places particularemphasis on supporting the design process so thatthe recording of design rationale may be done easily.A commercial system from Enviros Software Sol-utions, DRAMA (Design RAtionale MAnagement),was based on the ideas of the KBDS prototype fromthe University of Edinburgh. It uses a graphical userinterface and an object-oriented database to storeand structure reasoning relating to design(http://www.enviros.com/drama/).

4.2. Procedural Hierarchy of Issues (PHI)

The Procedural Hierarchy of Issues (PHI) [20]extends IBIS by broadening the scope of the concept‘ issue’ and by altering the structure that relatesissues, answers and arguments. First, it simplifiesrelations among issues by using the ‘serve’ relation-ship only. Secondly it provides two methods to dealwith design issues: deliberation and decomposition(i.e. to give answers to the issue or to break downthe issue into a variety of subissues which in turncould be deliberated or decomposed). The primeissue is by definition the whole project. PHI avoidsraising irrelevant and trivial issues [20]. Anotheradvantage of PHI is that the issues, subissues,answers and arguments can be presented in theformat of outlines, as shown in Fig. 5. Comparedwith IBIS, PHI provides dependency relationshipsbetween issue resolutions and considers the pros andcons of alternative answers [41]. In addition, it morecompletely and accurately models the task structureof the design process and the information useful fortasks [21].

VIEWPOINTS [16] is a hypertext system forargumentative kitchen design based on the PHIdesign methodology. It is a a tool which supportsthe argumentative approach within the design pro-cess. The elements of VIEWPOINTS areissues,answers, argumentsand graphics. It provides agraphical interface to facilitate its use, enablingdesigners to do extensive browsing and makedecisions.

JANUS [21] is the integration of the CRACKand VIEWPOINTS systems. CRACK [16], anothercomputer-supported design rationale system, is aknowledge-based critic which has information abouthow kitchen appliances can be assembled into afunctional kitchen. JANUS allows architectural andinterior designers to graphically construct artifactsby direct manipulation, and at the same time receive


ISSUE:

What kind of conveyers should be used in material handling?

SUBISSUE:

1. What kind of conveyers should be used in bulk material handling?

%

2. What kind of conveyers should be used in unit material handling?

ANSWERS:

1. Gravity conveyers

SUBANSWERS:

1. chutes, skate wheel conveyers

2. roller conveyers

ARGUMENTS:

1. Its advantage is low cost, relatively low maintenance, and negli-

gible breakdown rate.

2. Its requirement is the ability to provide the necessary gradient in

the system configureation.

x%

2. Powered conveyers

%

3. Chain-driven conveyor

%

4. Power-and-free conveyers

%

Fig. 5. An example of PHI: select conveyers for material handling.

information useful to what they are doing fromhypertext activated by knowledge-based agents.From JANUS and its predecessors CRACK andVIEWPOINTS, we can see that integrated supportfor construction and argumentation is necessary forfull support of design.

PHIDIAS [18] is a hypermedia system which isbased on PHI; like other rationale representationschemes, it uses a graph-based node-link structure.PHIDIAS represents all of its knowledge, includingsemi-formal rationale as well as formal represen-tations of physical objects, facts and rules, in thisgraph-based format. In PHIDIAS’s graphs, bothnodes and links are first-class objects with prototype-based inheritance. Nodes can vary in size from asingle letter to a multi-page document, with most

rationale nodes corresponding to individual words,sentences, or paragraphs. The Hyper-Object Sub-strate (HOS) [18] is another hypermedia prototype. Itincludes a generic view containing an argumentationstructure, which uses a piece of the design andnearby discussion as an example in this structure.

4.3. Design Space Analysis

Design space analysisplaces an artifact in the spaceof possibilities and seeks to explain why the parti-cular artifact was chosen from these possibilities.The Question, Option and Criteria (QOC) [5] is onesemi-formal notation ofdesign space analysis, whichfocuses on the three basic concepts indicated in


its name. The QOC representation emphasises thesystematic development of a space of design optionsstructured by questions, which is different from theIBIS-derived systems and PHI, whose purpose is tocapture the history of design deliberation. QOCrepresents the design space using three components:questions identify key issues for structuring thespace of alternatives;options provide possibleanswers to thequestions; criteriaare the bases forevaluating and choosing from among theoptions.

Figure 6 presents an example of design spaceanalysis for displaying a scroll bar. The rationalerepresentation in QOC is created along with thedescriptive representation (specification) or the arti-fact itself (prototype). In aspects of innovation andreuse, QOC has many advantages. It is relativelyeasy for a maintainer to create a QOC to ‘reverseengineer’ a part of a system and preserve it forfuture use. QOC records the exploratory activity ofthe design team, such as what alternatives wereconsidered and what choices were made and why.QOC’s graphical argumentation notation lets teamusers actively manage QOC recording during work,and supports the transition from expression to docu-mentation, from informal, incomplete, private ration-ale to more formal, complete, and publicly intelli-gible rationale [42].

The Design Rationale Authoring and RetrievalSystem (DRARS) [29] is a system that uses avariation of QOC [29]. Views, goals, alternatives,claims, questions, answers and versions are theDRARS system’s objects. The human user is respon-sible for giving descriptive and useful names tothese objects.

Another way to record design rationale is bydescribing how an artifact serves or satisfiesexpected functionalities, using languages such asDecision Rationale Language (DRL) [1] or Function

Fig. 6. A QOC representation of the design space for displaying scroll bar [5].

Representation (FR) [30]. DRL is an expressivelanguage which represents the space arounddecisions, which can be maintained independentlyor integrated with traditional design representation.DRL was implemented in a system called SIBYL[43]. and is being used to explore various kinds ofcomputational service over DRL structures.

Also related to QOC, [44] describes a languagecalled TED used to represent the reasoning behindthe implementation of particular features.

4.4. Functional Representations

Functional Representation (FR) [30], a represen-tational scheme, describes how the device works (oris intended to work). In the functional representationscheme, design rationale is used as an account ofhow the designed artifact serves or satisfies expectedfunctionality. One can use FR to capture thecausalcomponents of design rationale. FR takes a top-down approach to represent a device: the overallfunction is described first, and the behaviour of eachcomponent is described in the context of this func-tion. FR encodes the designer’s account of the causalprocesses in the device that culminate in achievingits functions. Tasks that design rationale should beable to support are: control of distributed designactivity; reassessment of device functions; generationof diagnostic knowledge; simulation and design veri-fication; redesign; and case-based design. FR pro-vides a partial rationale for choices made aboutcomponents and their configuration; its limitation isthat FR only captures the causal knowledge aboutdevice operation.

The Structure, Behaviour and Function (SBF)model [37] is an approach for designing deviceswhich explicitly represents thefunctions of the


device (the problem), thestructure of the device(the solution) and the internal causalbehavioursofthe device. Function can be defined aswhat (anobject) does, behaviour ashow (it) does what(it)does, and structure aswhat (an object) is. Forexample, a clock’s function is to indicate to anobserver the time, its behaviour is that its hands goaround with a periodicity matching the elapsing oftime, and its structure is its composition of metal,plastic, glass, and so forth [45]. The structure of adevice in the SBF language is represented as aschema that specifies the input behavioural state ofthe device. The SBF model of a device also specifiesthe internal causal behaviours that compose the func-tions of device substructures into the functions ofthe device as a whole. The functional models rep-resent design casesfrom which adaptation spacesare generated for solving a new design problems.The designed products are represented using qualitat-ive models with the structure and behaviour ofthe artifact.

SBF models provide a powerful solution for adap-tation problems and for performing case-based andvariational design [46], in which old design cases areadapted to address new design challenges. KRITIK[37,47] is a system which uses a functional represen-tation scheme called Environmentally-bound Structure-Behaviour-Function (EBSF) to represent and organ-ise knowledge of the functioning of a device, includ-ing the role of its environmental interactions.

Rosenman [6] clarified the concepts ofpurpose,function, behaviour and structure. Purpose is theaction or fact of intending or meaning to do some-thing; function is ‘the action of performing’, ‘themode of action by which it fulfills its purpose’:behaviour is defined as how something acts inresponse to its environment; and structure is theorganisation of the constituents of the object. Therelationship between them is: structureexhibitsbehavioureffectsfunction enablespurpose: or, pur-pose enabled-by function achieved-by behaviourexhibited-bystructure. The process of interpretingrequired behaviour to arrive at a given structure isthe process of analysis, the interpretation of structureto determine behaviour and function is the processof synthesis. These processes are causative processeswithin the physical environment. The process ofinterpreting function for purpose is the process ofrealisation (of possible utility), whereas the processof interpreting required purposes as desired functionsis a process of problem formulation. These lattertwo processes provide the communication betweenthe human value system and the physical environ-ment, and teleological reasoning comes into play.

Purpose, function, behaviour and structure are gener-ally decomposed down to sub-functions, sub-behav-iours and sub-structures, so the problem is formu-lated by the relationship among groups of relatedfunctions, groups of related behaviours and groupsof related structure (see Fig. 7). Such a represen-tation can be easily mapped to a relational database,with each predicate being mapped to a table in theRelational Database System (RDBMS), or into anobject-oriented database, which has better capabili-ties of handling class-subclass relationships.

4.5. Other Representation Schema

In each different engineering domain, from mechan-ical design to software design, the design process hasits own unique features. According to the specificrequirements, various support systems have beendeveloped. One major challenge for software engin-eers is judging how a change in one software moduleeffects (and is affected by) the rest of the design.Mark [23] introduced the Comet system, which usesexplicit representation and reasoning with commit-ments to aid the software engineering and develop-ment process. The design knowledge managed byComet is in the form ofmodule descriptions: struc-ture and behaviour specifications of modules inter-related by commitment constraints. The underlyingrepresentation is LOOM [48], a language andenvironment for knowledge representation andreasoning. LOOM maintains a taxonomy of moduledescriptions based on the defined inter-relationshipof their constituent terms, and can automaticallydetermine modules’ relationships. Developers andsoftware engineers can examine the commitments

Fig. 7. Whole-component decomposition [6].


that must be met in order to include an existingmodule, and can explore how commitments changewhen modules are modified. Comet has been appliedto the domain of sensor-based tracker software [23].

Augmenting Design Documentation (ADD) [24]is an integrated computational model for assistingdesigners in documenting projects at design time.The model was developed based on observations ofdesigners developing Heating. Ventilation and AirConditioning (HVAC) systems and on observationsof documentation users accessing design documents.The ADD [24] model represents design rationale asa combination of argumentation-based and model-based rationale, and is good at both rationale acqui-sition and explanation. It works by documenting thecomplete design decision path associated with theartifact, as well as the rationale behind each decisionpresented by the user. This solution path representsthe designers’ strategy, in which each node is asequentially linked decision. Users can explore thedesign rationale in several ways: through the historytree, the dependency tree, annotations, and (mostimportantly) by asking direct questions. However,the ADD system only provides a one-paragraphanswer, without references to the relevant data inthe knowledge base.

More recently, Garcia proposed a system, calledADD1 [27], which includesrhetorical structuresinactive documents. ADD1 uses the same basic modelas ADD, but improves the system’s interactions withthe user. In ADD1, the wealth of knowledge keptin ADD’s knowledge base is organised into high-level Rhetorical Structure Theory(RST) [49]schema, and mapped onto input and output screenconfigurations that gear the interaction between sys-tems and users. Compared with ADD, ADD1 hasan explicit communicative model to convey mess-ages that reinforce the model’s usability.

Garza [28] discussed a design rationale system, apath-finder computer program called Design Ration-ale for the Information phase of Value Engineering(DRIVE), used as part of a much larger Computer-Aided Value Engineering (CAVE) system. It con-sists of two modules: a domain-dependent Knowl-edge Representation Module (KRM), which containsobjects and attributes representing building designinformation, and a domain-independent RationaleStorage Module (RSM), which contains all thedesign decisions made about the different perform-ance parameters of various design objects in theKRM. The depends-onand has-relationshipseman-tic net [50] links of of RSM generates the ParameterDependency Network, which can determine how thedesigners arrived at a particular design decision. It

also can determine how one object-parameter affectsother object-parameters and further affect otherobject-parameters.

Figure 8 shows an example of the PDN. TheRoom-Function object-parameter pair affects theRoom-Fire Resistance Ratingobject-parameter pair,which in turn affects theDoor-Fire Resistance Rat-ing, Wall-Fire Resistance Ratingand HVAC Equip-ment-Fire Resistance Ratingobject-parameter pairs.It uses Kappa-PC (an object-oriented expert systemprototyping environment and AutoCAD (a graphicalcomputer-aided design application). Compositionalmodelling is one other approach that has beentried [51,36].

5. Design Rationale Capture

How design rationale is captured is a critical elementin the development of a design rationale system:capture too little information (or the wronginformation), and it will be impossible to create arepresentation of rationale; capture information toointrusively and designers will not use the system.The primary requirement of the design knowledgecapture process is that it captures design descriptionsin a form that supports the communication and reuseof design knowledge. In particular, these capturetools should operate on representations that are use-ful for constructing design rationale explanations [4].

From the designer’s point of view, we can dividedesign rationale capture methods into two categories:those that requireuser-intervention, in which thedesigner must manually record the design infor-mation during the design process, and those thatare automatic, in which the capture is performedautomatically by the design rationale system.

5.1. User-Intervention-Based Capture

User-intervention-based rationale capture has oftenbeen approached by thedocumentation method.Documentation is intended to record the history ofdesign activities. More specifically, it records whatdecisions designers made, when they were made,who made them and why [18].

The form of documentation is areport, which iswritten by individual designers. The creation ofdocumentation tends to occur after the decision pro-cesses. Documentation therefore merely recordsdecisions, without influencing the designer’s thinkingprocesses leading to the decisions. Documentationhas some very useful functions [18]: it enables


Fig. 8. Parameter dependency network example [28].

people outside the project group to understand, orsupervise, the design process; and it can be used toidentify the intellectual property generated in a pro-ject for the purpose of obtaining or defending pat-ents.

Conklin [3] claimed that the documentationapproach to rationale capture has the followingdrawbacks:

I documentation requires manually writing downa design rationale, which is not executable oreven implementable;

I as documentation, a set of decisions is inherentlyunstable, especially if it is being written duringan exploratory process;

I in order to be updated, the design rationale docu-ment can grow into a huge bundle. In this case,there are many people involved in the develop-ment process, and issues may be repeatedlyrecorded, which may result in inconsistent infor-mation in the design rationale document;

I design is often marked by breakthroughs of under-standing, after which some previous decisions andassumptions may become incorrect or irrelevantafter conceptual restructuring. When this happens,the design rationale document must be rewritten.

Most of the design rationale systems are usingmechanisms that let designers provide their ownexpressions about design decisions and reasoningduring the design process. The REMAP model [25]supports the capture of design rationale knowledgeby providing a mechanism for the design team toconduct deliberations using the primitives (issues,positions and arguments) in the model. As intro-duced in Section 4.1, all these primitives are definedmanually by the designers during the design process.

The Comet system [23] uses explicit represen-

tation and reasoning with commitments to aidsoftware design. In terms of rationale capture, itrequires the user to introduce new module descrip-tions as specialisations of existing module descrip-tions, which limits the design flexibility. However,a crucial area in which Comet is particularly usefulis through its Design Memory window, which allowsdevelopers to trace the compatibility of the candidatemodules with the current design. This notion is veryimportant to the computational tractibility of thesystem’s reasoning process.

In Garcia’s [24] ADD system for HVAC, rationaleis captured by using the computer as a ‘designer’sapprentice’. ADD contains a predefined set ofrelationship between the various design parameters.These relationships allow the system to expect cer-tain values for the design parameters. If the designerproposes a value different from the expected value,the computer asks the designer for justificationregarding the differences. The justification is inputby the designer and recorded in the system’s data-base.

DRIVE [28], compared with ADD, has a fixedand predefined set of relationships between its vari-ous model parameters. DRIVE builds relationshipsbetween its various model parameters in real-time,i.e. as the design develops. It helps designers expressthe rationale behind their design decisions in acomputer-interpretable format. It also assists valueengineers in formulating suitable design alternativesby presenting rationale about an existing design.However, the disadvantage of DRIVE is that it startsout with a totally empty rationale database and relieson the designers to create relationships among itsvarious object-parameters. In contrast, ADD startswith a predefined but modifiable set of rationaleinformation. ADD captures additional design ration-


ale when an expected value provided by the originalrationale database differs from the current state ofdesign. In other words, DRIVE needs user-inter-vention even though it is more flexible in terms ofdefining parameter dependency relationships.

KBDS-IBIS [14] introduced two new ideas. Thefirst was to enable the designer to record a varietyof complementary types of documents within theprocess design history, addressing the goal ofimproving the design information recorded. Designrationale is recorded in KBDS using an extensionof IBIS structures. Secondly to extend the range ofinformation recorded, KBDS allows the designer toannotate or associate a number of documents ofdifferent types to unit operations in a process flow-sheet or to notes within an IBIS structure. Thequality of design support depends on the qualityand quantity of the design history records. It isnecessary to have a full and accurate description ofthe design artifact on which to base the argumen-tation for design decisions.

Even though some design rationale systems needuser-intervention to record design information, a sys-tem must naturally support the design process orengineers will find the use of the system a distrac-tion. Chung’s [31] IDIS has three main componentsfor supporting natural capture of design rationaleduring the design process: aviewpoint system, anissue-based system, and a rule-based system. IDISprovides an integrated framework for recording threedifferent aspects of design rationale:exploration ofdesign alternatives, reasons for design decisionsanddesign constraints. Recording the possible solutionsand the argumentation explicitly helps other design-ers avoid considering the same unfruitful areas inthe future, and can be useful in checking designs.By recording the design constraints as decisions aremade, if changes are made to the design, the systemcan help designers check the design for violationsof these constraints.

5.2. Automatic Rationale Capture

The automatic capture of design rationale assumesthere is a method to capture the communicationamong the designers and design teams. The com-munication records can then be used to extractdesign rationale and decisions as they evolve duringthe design process [18]. Usually, communicationemploys Computer-Supported Co-operative WorkTools (CSCW) [52] or meeting technologies. Thisincludes, for example, telephone, tape recorders,video camera, shared applications, or e-mail to cap-

ture oral discussions as well as writings and draw-ings exchanged between designers. The designersneed not do anything more than pursue their usualdesign activities. When communications and meet-ings are archived digitally, design activities can beprocessed and design rationale determined.

One drawback is that what is recorded duringcommunication and collaboration is likely to be freeform, full of disorder and digressions [18]. Rawcommunication lacks structure; by using thisapproach to capture design information, the knowl-edge retrieval process may be ineffective as a result.While difficult to extract meaning from, the captureof raw CSCW sessions and project meetings is themost convenient approach for the raw archiving ofdesign rationale.

The HOS system [18] provides an environmentsupporting computer network design with the combi-nation of natural communication and design in anargumentation structure. HOS includes facilities forimporting email and USENET/Internet news files –thus, the network designers can continue their exist-ing practice of using e-mail to inform one anotheron the progress of tasks, and later include thisinformation in their HOS design space. This designinformation capture process is done automaticallyby the HOS.

PHIDIAS’s [18] integral, graph-based architecturefacilitates relating the semi-formal knowledge con-tained in design rationale with more formal systemknowledge. It implements this capture process intwo steps. The first is by representing all of itsknowledge, including semi-formal rationale as wellas formal representations of physical objects, facts,and rules, in a common graph-based format. Thesecond step is simply using hyper-links to intercon-nect knowledge items, regardless of their level offormality.

Ramesh [26] suggested that an ideal design ration-ale system should not only facilitate easy and non-intrusive capture, but also provide automated reason-ing with related knowledge. Ramesh implemented amultimedia extension based on the REMAP model,called REMAP/MM, which is a prototype DecisionSupport System (DSS) environment that supportscapture by providing a graphical interface for designteams to conduct their deliberations. It also supportshyperlinks among design deliberation records andmultimedia objects. REMAP/MM explicitly ident-ifies the dependencies among design rationale; whendesign is reviewed, dependency information can beused to identify relevant components of the process.

Fischer’s [16] CRACK kitchen design environ-ment consists of two components: a domain-oriented


construction kit for creating a kitchen floor planlayout and a knowledge-based critic for evaluation.The construction kit in CRACK is provided to givethe designer the feeling of directly generating thedesign without the computer’s being ‘in the way’.The important abstract operations and objects in thekitchen design domain have already been built intothe CRACK construction kit. Therefore, the designrationale used during the design is captured auto-matically by the system.

JANUS’s [21] architectural design system inte-grates a CAD-like editor with a rule-based designcritic and an argumentation-structured hypertextdocumentation environment; it is an integration ofthe CRACK and VIEWPOINTS systems. TheJANUS system has demonstrated that hypertext canbe used in conjunction with knowledge-based designenvironment to ease design knowledge capture.

An experimental system, the Rationale Construc-tion Framework (RCF) [32] was designed to acquirerationale information from the detailed design pro-cess without disrupting a designer’s normal activi-ties. The underlying approach involves monitoringdesigner interactions with a commercial CAD toolto produce a rich process history. This history issubsequently structured and interpreted relative to abackground theory of design metaphors that enableexplanation of certain aspects of the design process.

Generic task model of design. DEsign and Specifi-cation of Interaction REasoning components(DESIRE) is a formal framework for multi-agentsystems [53,51]. It explicitly models five types ofknowledge: the task composition, the knowledgestructure involved, information exchange betweentasks, sequencing of (sub)tasks and goals, and theroles of the participating agents. It has been used formanagement of conflicts in design [53], (parametric)design of elevators [51]. Generic Task Model ofDesign (GTMD) [36] is one of the generic modelsavailable within DESIRE. GTMD is used to struc-ture the acquisition process, clearly distinguishingthe design tasks into three subtasks: reasoning aboutrequirements and preferences (RQS); reasoningabout the Design Object Description (DOD); andreasoning about (coordination of) the overall designprocess. Each of these three are composed of foursubtasks: modification, update-of-modification his-tory, deductive refinement, and update of currentdescription. Knowledge used to generate designrationale is represented in the components of theGTMD. During the design process, the designrationale is generated and stored in the respectivehistory components. Different types of design ration-

ale are distinguished according to the functional rolethey play in the design process. GTMD has beenused to structure the modelling process of anexample aircraft design task [36] and an elevatordesign task [51].

Interactive Acquisition of Justifications. Justificationsexplain why something should be believed or done.Gruber [54] proposed an approach for acquiringjustifications by transforming why-questions intowhat-questions. It changes the open-ended task ofexplaining why into the constrained task of selectingwhat is relevant. The author framed the problem ofcapturing design rationale as a knowledge acqui-sition problem, where the task is to elicit, fromdomain specialists (designers), knowledge thatenables a program to generate explanations of howthe designed artifact is intended to achieve its func-tion. The ASK knowledge acquisition system wasproposed. It first elicits an example specifying asituation and a choice; the user provides the exampleby running the interactive knowledge system untilit comes to an interesting choice among actions.The user interrupts the knowledge system, and indi-cates which action the user would have taken in thesituation and an example of an action that wouldnot have been appropriate (the negative example).It then elicits justifications for the strategic decision,that is, reasons for choosing one action over another.The interface presents features of the current situ-ation, and users select from among these features aset of relevant features for choosing the positiveexample. ASK computes the values of the specifiedfeatures for the current state and the positive andnegative actions, and presents these object-feature-value tuples as English sentences that are intendedto explain why the chosen action is appropriate.

Capture of device behaviours. Stahovich [55,56]described a program called SketchIT that capturesthe behaviour of the device in a single sketch,represents them inqualitative configuration space(qc-space), and then synthesises them into multiplefamilies of new designs. The input of SketchIT isa stylised sketch of a device and a state transitiondiagram describing the device’s desired overallbehaviour. The latter provides guidance in ident-ifying what behaviour the individual parts of thedevice should provide. The overall behaviour of thedevice is achieved through a sequence of interactionsbetween pairs of engagement faces, hence the behav-iour of the device is captured and represented firstby configuration space curves (cs-curves), which areformed by touched points of engaged surfaces in


configuration space (c-space). The axes of a c-space are the position parameters of the bodies; thedimension of the c-space for a set of bodies is thenumber of degrees of freedom of the set. Thenumerical cs-curve is further abstracted into a quali-tative c-space, which represents cs-curves by theirqualitative slopes and the locations of the curvesrelative to one another. In the synthesis process, theprogram turns each of the working qc-spaces intomultiple families of new designs represented by aBEP-Model (Behaviour Ensuring Parametric Model).The synthesis process is comprised of two steps:selecting a motion type for each part and selectinga geometry for each pair of engagement faces. Thereare a variety of selections of motion type andgeometry which are different from those of theoriginal sketch, but have the same behaviourdescribed by the working qc-spaces. This varietyleads to a family of new designs which have thesame function as that of the original sketch.

6. Design Rationale Retrieval

The reuse of design rationale is realised by itssuccessful retrieval. In this context, design rationaleresearch shares much in common with research incase-based reasoning and case-based/variationaldesign. Case-based reasoning has been an activeresearch area for the past 15 years [57–60]. Thiswork represents a foundation of structures, algor-ithms and techniques for reasoning about and adapt-ing archived knowledge.

Design rationale systems operate in a similar man-ner, retrieving past experience relevant to solving anew problem. Which cases are retrieved dependsupon both the current objectives and the represen-tation schema of the design rationale. There aredifferent potential scenarios for retrieving designrationale: (1) to view similar design cases at theinitial conceptual phase of design; (2) to retrievecriteria, rules and options to help make designdecisions during the design process; or (3) to pro-duce documents after a design process. Dependingon the scenario, there are different strategies toretrieving related design rationale and avoidingunwanted material [14,27].

Lee [12] classified design rationale systems asuser-initiative or system-initiative, depending onwhether the user or the system initiates access. Weconsider the retrieval strategies of design rationalesystems by considering their support of three basicretrieval approaches: navigating by designers,

retrieval by queries, and automatic triggering duringthe design process.

6.1. Navigating Archived Design Rationale

Design rationale navigation involves permittingdesigners to explore design rationale by traversingfrom one node to another by existing links. Systemsmay provide facilities to help with such navigation[41]. For process-oriented approaches, this navi-gation often provides a backtracking of the designhistory. In a feature-oriented approach, with designknowledge being stored according to features of thedesigned artifact, navigation is done around the fea-ture structure. For a complex artifact, a large quan-tity of information is recorded during the designprocess – looking up specific answers is often adifficult task.

The VIEWPOINTS [41] system uses PHI andextends IBIS by broadening the scope of the con-cepts of issues, answers, arguments and graphics, toaid designers in finding answers to specific prob-lems. VIEWPOINTS creates an integrated multifa-ceted design environment with five components: aconstruction kit, an argumentative hypertext system,a cataloguewith a collection of design examples, aspecification componentand asimulation componentfor exploring the design options. VIEWPOINTS isused as a look-up manual, where designers can findanswers to specific problems and consider variousarguments for and against them. For a complexproblem, the discussion around it may be distributedin a wide range of archived activities. To navigatethrough all the related nodes and to make sense ofit becomes a difficult task.

An IBIS-style browser [22] lets users browsedesign rationale as a map with nodes such as issues,positions and arguments, and links such as respondsto, supports and objects. As a system combiningissue-based and truth-maintenance approaches, ithelps designers perform what-if analysis using colorsto indicate the belief status of nodes.

ADD [24] proposed a read-only interface to allowusers to navigate graphically through the decisionsand reasonings connected to the designed artifact.ADD also allowed users to verify the knowledgerequired for justifying each decision, thus leadingto retrieval of an intelligent design document. Acontroller contained domain knowledge for checkingdesigners’ decisions.

COMET [23], the software design support systemfor Computer-Aided Software Engineering, allowssoftware developers to review and check any exist-


ing module descriptions in the Comet knowledge-base that are consistent with the descriptions createdfor a new module. There is a design memory win-dow with a nodes-link diagram to help users withnavigation.

In IDIS [31], listing and browsing facilities areprovided by AutoCAD diagrams and the viewpointlinked to them. By clicking an item on an AutoCADdiagram, the specification of that item will be dis-played, and users can find out all the issues andrules related to it by visiting the viewpoint and itsparents and children. It also provides some sup-plemental facilities to support keeping track ofdesign progress, and for reviewing a project whenit is completed. It provides an option for listingunseen nodes in the issue base to answer the ques-tion ‘what is new’ in the design process, and anoption for listing the outstanding issues and theircorresponding deadlines to answer the question‘what are the outstanding issues’. Users can treatthe issue system as a database of free text, so akeyword search could be used to find out ‘what hasbeen said about a certain topic’; it can display allthe relevant issues that led a particular design alter-native to answer ‘how did we get here’. To answerthe question ‘what are the differences between twodesign alternatives’, it can provide a summary ofthe viewpoints leading to the different design alter-natives, process units that are in one design and notin another, and different parameter values associatedwith the same items in different designs.

6.2. Automatic Triggering

Several design rationale systems enable the capturingof design rationale by automatic triggers thatdetecting or monitor certain conditions according tothe design context. This type of approach sharesmany similarities with the event-driven programmingparadigm in the engineering of real-time and inter-active software systems. Design conditions are moni-tored according to corresponding rules, criteria orconstraints of design. The monitor is used to lookover and check the design process, and compare thedecisions made with the constraints, rules or criteriain a design rationale library or knowledge base; ifdifferences are detected, the design rationale will beretrieved automatically.

The PHIDIAS [18] system uses issue-basedindexing of design rationale as its hypertext-basedretrieval strategy. The basic idea is to connect thedesign rationale with the design task. The connectionis artifact-based indexing, which connects design

rationale to the drawing of the artifact, critique-based indexing, which connects the critique to thedesign task, and operation-based indexing, whichconnects the design rationale to some specific oper-ations on the designed artifact. Critics have beenbuilt according to the indexing scheme, which canbe specified to be triggered automatically dependingon design conditions or which may be requested tobe executed by users.

CRACK [21] is a knowledge-based computer sup-port system which can help designers solve construc-tive design problems in design activities. The criticsin CRACK are intelligent support systems whichdetect and criticize partial solutions constructed bythe designer based on knowledge of design prin-ciples. A critic can be triggered by state-drivencondition-action rules, because it checks the knowledge-base to detect non-satisfying design decision [16].

ADD1 [27] acts as an apprentice and learnsabout the features that make a specific case differentfrom the standard in the design process. The appren-tice must be able to access the design knowledgeso that a new design decision can be justified.

6.3. Query-Based Retrieval

To provide retrieval strategies according to design-ers’ queries is more efficient than browsing thenodes of design rationale structures. The queriesmay be ‘what-if’ questions, which can be answeredby exploring different options; or ‘why’ questions,which are answered by back-tracking in the networkof nodes and links to find out the argumentation orreasoning behind a decision. Gruber [54] proposeda generative approach, in which design rationaleexplanations are generated in response to infor-mation requests from background knowledge andrelevant information captured during design. Theproblem is how to provide a methodology of sel-ecting and assembling knowledge from libraries ofdesign rationale based on specifications of require-ments [61].

REMAP/MM [26] uses a deductive query langu-age to define various types of ad hoc queries, andprovides a graphical interface for displaying queriesand retrieving desired information. The queries maybe recursive, which supports selective retrieval ofprocess knowledge, allowing the design process tobe replayed. Instead of replaying the entire process,dependency information can be used to identifyrelevant components of the process that need tobe replayed. REMAP/MM made extensive use ofmultimedia and a combination of both informal and


formal representation to capture design rationale[26].

KRITIK [30,9] (Kritik in Sanskrit roughly means‘designer’) is an early case-based design system. Ituses a Structure-Behaviour-Function (SBF) model toexplain how the structure of a device accomplishesits function, which is part of design rationale inshowing why and how designers get the device towork as intended. The system searches the corre-sponding Causal Process Description (CPD), andfollows state transitions to retrieve the desiredknowledge.

DRIVE [28] is a rule-based system in which thecaptured design rationale has structure, and can beprocessed automatically by the system. It creates arule base for all rationale hierarchy objects whichis used to check the validity of the relationshipsevery time a relevant design parameter changes, orto detect conflict and provide designers with variousoptions for resolution.

6.4. Hybrid Retrieval Strategies

JANUS [21] uses the critics from CRACK to moni-tor the design process based on a knowledge base,and allows entering from a criticism point to theexact place in the hypertext network where theargumentation relevant to the current constructiontask lies. A Document Examiner provides func-tionality for on-line presentation and browsing ofthe issue base by users.

KBDS-IBIS [14] provides three ways in whichdesign rationale can be used to the designer’s advan-tage: dependency-directed backtracking, automaticevaluation of positionand automatic report gener-ation. All three need to review the design rationaleaccording to certain requirements. To provide sup-port in design requires prescriptive information todetermine the validity of the argumentation storedwithin KBDS-IBIS, so it is more than just retrievalof what has been recorded.

7. Related Research Areas SupportingDesign Rationale

Engineering design theory. Engineering design isthe process of creating new products, processes,software and systems from an initial, incompleteand general set of goals, objectives, functionalrequirements and constraints, with the considerationof social and economic impacts pertaining to theuse of product being designed. In general, engineer-

ing design involves the following four distinctaspects: problem definition, conceptualisation,synthesis/analysisand detail design.

Axiomatic design theory [62] is one of the suc-cessful methodologies used in the design field. Itdefines a design as the creation of the synthesisedsolutions that satisfy perceived needs through themapping of theFunctional Requirements(FRs) tothe physical space, represented byDesign Para-meters(DPs) as shown in Fig. 9. Functional require-ments are the minimum set of independent functionsconstructed to satisfy the design original needs. Thedesign parameters are specified to satisfy the func-tional requirements.

Intelligent CAD. While CAD systems provideincreasing levels of functionality to support thedesign process, they deal predominantly withdetailed design. CAD systems are drafting anddetailed modelling environments, performing bestwhen users know what the design’s physical formwill be [63].

There have been a number of different approachesenabling intelligent CAD. Case-based and Vari-ational Designenvironments enable previous designcases to be adapted to solve new problems [9,46,64].Research in this area has built symbolic represen-tations for indexing and retrieval of design cases.

Ullman [10] presents a detailed analysis of audioprotocols used by five mechanical designers, observ-ing that CAD tools should be designed to givecognitive support to the designer. He argues designrationale systems, combined with CAD systems, willprovide a more complete toolbox to give bettersupport for decision making at the initial designstage. A more recent project [65] examines com-munication among application programs in theArchitecture, Engineering and Construction (AEC)

Fig. 9. Mapping process by axiomatic design.


domain. Internet-based project collaboration productsare integrated with the AEC desktop, enabling abetter understanding among team members in adesign process. In this project, the commercial CADtool is used to monitor designer interactions.

Klein [7] indicated that to achieve the benefits ofusing design rationale, representations must allowdesigners to express their design reasoning in anatural way. At the same time, these representationsmust be formal enough to support useful compu-tational services and impose the minimum possibleoverhead on the design process. His Design Ration-ale Capturing System (DRCS) provides an integratedand generic framework for capturing rationale inteam contexts. DRCS uses a vocabulary of assertionsto capture design reasoning. The assertions consistof entities (e.g. modules, tasks, specifications andversions) and claims about these entities. Thevocabulary of claims and entities that make up theDRCS rationale language fall into five categories:synthesisto capture the actions used to define arti-facts and their plans;evaluationto capture not onlydesign specifications but also how well they havebeen achieved;intent to capture when a designertakes an action;versionsto capture how the designercreates and explores the space of design alternatives;and argumentation to capture the reasons for oragainst an action. DRCS was implemented in Com-mon Lisp on Symbolics workstations.

Knowledge representation. The artificial intelligencecommunity has produced a rich set of techniques forformal representation of knowledge [66–70,50,71].Many of these techniques build on formal logics,and are often difficult to adapt to ill-defined andoften informal engineering datatypes. This includeswork on functional representation [30,72] and thecreation of engineering ontologies [73–77]. There

Fig. 10. DRCS architecture.

have been a number of successful efforts from theengineering community to apply formal AI represen-tations to design and manufacturing problems [78–83,40,84].

Knowledge-based design support. To modelknowledge-bases and databases for intelligentdesign, design rationale must be captured and trans-lated into these formalisms [85]. Many knowledge-based systems have been developed for design; sev-eral most relevant to design rationale systemsinclude [15,14,31,86].

Gruber [87] analyses the role that a standardknowledge representation language can play in thesharing of Knowledge Bases (KB) among groups ofpeople and programs that can make use of theknowledge and across research groups developingknowledge-based technology. Other work from Stan-ford on the DARPA MADE Program [88–92]repeatedly addressed knowledge sharing and knowl-edge representation as central issues in deployingcollaborative engineering systems.

In a knowledge-based design system for concep-tual design in chemical engineering [15,14], fourinter-related networks are used to represent designprocess, and design rationale is represented usingan extension of IBIS. IDIS (Integrated Design Infor-mation System) [31] is an issue-based system thatsupports the argumentation process during design;viewpoints are used to represent the design hierarchyand to support design exploration, and a rule-basedsystem is used to represent design constraints.Knowledge can be represented in the expert systemat different levels: theknowledge-usedlevel is used90% of the time, while theknowledge levelis usedto support the knowledge-used level [86].

For a comprehensive text on the subject of knowl-edge-based systems in design, readers are referredto the recent book by Sriram [93,94].

Machine learning.The research work in the area ofmachine learning has contributed many methods thathave been applied to the acquisition of knowledgein design. Machine Learning in Design (MLinD)[95,96] examines the similarities between machinelearning and design rationale capture. The mainelements in machine learning are the input of knowl-edge, the output of knowledge, the transformationof knowledge, the learning triggers and the learninggoals which are related to the record, the access,the construction, the capture and trigger of designrationale. The approaches of machine learning arebasically analogical reasoning [97], induction-based


[98], knowledge compilation [99] and neural net-works [98,100–102].

8. Other Applications of DesignRationale Systems

Design rationale systems enable a wide variety ofother forms of knowledge reuse. For example,rationale environments can record not only thedesign decision, but also its justifications and theother design alternatives, trade-offs, and the argu-mentation that led to the decision. We present sev-eral other uses of design rationale environments.

Explanation, prediction and conflict management.Rationale systems can be used to provide justifi-cation for particular decisions [36]. In this way,people can understand which combinations ofrequirements and preferences designers have pre-viously considered, which options and which partialdesigns were explored, and in which situation. Theyalso can know the argumentation for the rejectionand/or acceptance of options, choices and partialdesigns. Further, archives can help determine ifspecific design decisions were made previously insimilar situations, using the results of past experi-ence to help designers predict the probability ofsuccess for the new design problems [27]. Rationalesystems have also been used to mitigate conflictsamong design team members [36,15,18].

Design indexing, navigation and reuse.By associat-ing formal representations of design rationale withtheir relevant design tasks, design experience canbe retrieved. Such indexing is especially valuablewhen rationale needs to be rediscovered, reused orre-evaluated. The indexing can be issue-based, task-based, artifact-based, critique-based or operation-based [15,18,103,104].

Design rationale-based indexing can also be usedto discover if parts of requirement descriptions, orobject descriptions for past design cases can bereused for new design problems [36,105]. Somecurrent research has focused on the role designrationale can play in redesign systems [105].

Design documentation. Rationale capture systemsprovide a form of design documentation, recordingwhat decisions are made, when they are made, whomade them and why. This documentation enablespeople outside the project team to understand, super-vise and regulate what is done by the project team.Another use of this documentation is to identify

and secure intellectual property generated during aproject [18,27,15,105]

Tazi [106] proposed to use design rationale forthe documentation of complex engineering systems.Intricate, multi-disciplinary design problems havenumerous quantities and qualities of information,correspondingly complex document structures, andmany intended users (such as engineers, technicalwriters, editors, graphics specialists and formatters)involved in the production of the product and itsdocumentation. In the case of the documentation ofa complex system (e.g. an aircraft or large softwaresystem), the authors need to be able to include notonly the information content derived from thedesign, but also communicative intentions – thetraces of various design choices by the designersand the authors.

Design rationale as a learning aid.Carey [107]proposed to develop a library of exemplar artifactsand design rationales as a Human-Computer Interac-tion (HCI) learning aid, to help train inexperiencedgraphical user-interface designers. For designers(both in training and on the job) the study of GUIdesigns is hindered by the lack of explicit rationalesto explain how the design achieves its objectives,and why other alternatives were deemed less attract-ive. A prototype system built as an extension to acommercial user-interface toolkit showed that gen-eric design rationale components could guide inex-perienced designers.

Construction of design models.Design is viewed asa process of constructing and evaluating a successionof increasingly complete design models until a finaldesign is produced. Templates [108] have been usedto guide the development of useful parts of designrationale by creating an instantiation of an existingtemplate, and supporting the design that evolves asa sequence of models towards a final result. Threekinds of templates are introduced [108] which sup-port software user interfacedevelopment, estab-lishing design goalsand design process manage-ment.

9. Discussion

This survey has discussed design rationale systemsfrom five perspectives:knowledge representation,rationale capture, rationale retrieval, technicalapproach and application domain. While consider-able effort has been put into developing designrationale systems, none of these systems has been


adopted for widespread industrial use. Althoughdesigners can benefit by using design rationale sys-tems, most systems are still in the laboratory stage.Further research needs to focus on the advancementsneeded to take the science to the level at which itcan be effectively deployed in industry.

9.1. Representational Challenges

The challenge of design rationale representation isto find the best method to assist designers in makingdecisions, which means this representation must pos-sess three qualities:ease of input, effective viewandactiveness[3]. For current systems, there are stillsome significant problems. For example, in IBIS-based design rationale systems, arguments are rep-resented as non-interpreted text – hence a systemcannot really understand the design, which jeopard-ises the usefulness of the method [31,24].

There is a considerable amount of work needed indesign rationale representation. A system componentshould be developed for articulating and representingthe task at hand, for example, how to create aDesign Space Analysis by using QOC representation[41,5]. Design rationale systems should have thecapability to represent potentially relevant featuresand combine features of objects in specific contextsto form coherent explanations in justification elici-tation [54], to explore the possibility of representingmore generic clauses in the formal components ofthe rationales [109], and to encode the modelingknowledge in a form that can be shared and reusedby several applications, i.e. the objective ofdeveloping some representation formalisms for shar-ing and reusing declarative knowledge [61].

For future systems, a formal language must bedeveloped to represent and reason about the stateof the design at all levels of abstraction [10]. Sys-tems should have the ability to provide differentviews, e.g. selectively hiding unnecessary detail andreorganising the information according to differentcriteria (such as subject, creator, status) rather thanonly chronologically. For argumentation systems, anissue is how to integrate authoring with browsing,which would enable the designer to annotate theissue base, record decisions on issues and generallypersonalise the argumentation [14,21].

9.2. Capture Challenges

The basic concern is how to capture process knowl-edge with minimal overhead, with the least inter-ference with the natural progression of design activi-

ties. Most importantly, how can this be done withoutshifting the focus of designers’ work from creativedesign tasks to the more tedious documentationtasks [27,26].

Other problems worth noting include how toresolve the conflicts that arise when new knowledgecaptured may violate the knowledge previously cap-tured, and how to construct the new design rationaleand keep it consistent for later use [9]. These prob-lems share issues in common with research frommainstream AI in areas such as non-monotonic logicand consistency management in knowledge-basedsystems. For most design rationale systems, thecurrent implementation is only able to record thedesign rationale after decisions are made, but notwhile they are being made. Further work couldcontribute to better tools for real-time capture andprocessing of rationale [14]. The ideal would be tohave design rationale systems that can bridge thegap between communication and argumentation bystructuring rationale after it has been captured [18,21].

For the engineers themselves, some problems needto be noticed. Considering the differences in thepreferred evaluation criteria used by differentdesigners, especially between experts and novices,to develop formal languages to represent and reasonabout the states of the design at all levels [10] is away to keep consistency in the capture and construc-tion of design rationale [34].

9.3. Retrieval Challenges

Since process-oriented design rationale is organisedchronologically, research on retrieval strategies isneeded to manage the enormous amount of chrono-logically organised design rationale [3] and increasehuman usability and computational tractability [1].Effective facilities need to be provided for users toget required information without navigating through-out the whole rationale space, such as by selectivelyhiding unnecessary detail and reorganizing the infor-mation [14,27].

To capture deliberations and reasonings in designprocesses, it is sometimes desirable to provide a setof predefined queries which address various knownuser needs [25]. These queries can be configuredusing the design rationale recorded for previousdesigns or by extracting analogies from previousdesign situations via case-based reasoning [14].


9.4. New Approaches

To bridge the representation gulf between designerand design rationale representation and strengthendesign rationale research, we need to modify thelanguage of communication (notation) and developthe representation medium (tool support) [2].

From our survey, while there have been designrationale systems and prototypes deployed in labsettings, much effort is needed before they will findwidespread acceptance in industry [28]. To extendthe system to a wider range of tasks such as com-missioning, maintenance, operational analysis andplanning, in any area where decisions are made, notjust in design process [14].

9.5. Conclusions

Organisations subsist on communication and coordi-nation. Whether the organisation is a multi-nationalconglomerate with a centuries-old history or schoolchildren playing basketball at recess, success of theorganisation depends on the ability of its membersto communicate and co-ordinate. The promise ofdesign rationale systems is to address this need –that is, to empower organisations to create andmanage their knowledge assets. However, despiteclaims of the ‘great potential’ of design rationalesystems, demonstrated successes are rare.

Design rationale is not a new concept for organis-ations. Organisations have long been concerned withcapturing and preserving their intellectual capital[110]. However, the introduction of new techno-logies and concepts can potentially change the wayin which knowledge must be managed. Currently,much of the information generated within an organ-isation is stored with the people in the organisation.That is, information about procedures, goals, prac-tices and history is stored in the people’s memory,desk drawers and bulletin boards. For decades, thisinformal method of managing information was,although not ideal, generally adequate. However, asartifacts increase in complexity the need to capturethe underlying design rationale increases. The goalof design rationale systems is to alleviate this prob-lem.

A successful solution to this problems is one thatfacilitates the generation, storage and retrieval ofinformation and associates the information with thedesigned artifact. Although that is the intent ofdesign rationale systems, the survey presented inthis paper shows that this intent is largely unmet.

In the sections below, we summarise the chal-

lenges that successful design rationale systems mustmeet. We include design challenges which, webelieve, will be more difficult to overcome than thetechnical challenges.

9.5.1. Technical ChallengesFirst, many systems require a large number ofknowledge workers to help organise and developthe content. This presents a problem for organis-ations with limited resources and a long list ofother priorities. These organisations need to takeadvantage of intellectual capital [110] that isdeveloped as part of the work process. One suchexample would be the communication and coordi-nation of distributed work teams that many managersare now required to do.

Secondly, even when the organisation as a wholeand individual groups are well supported, and con-tent is generated without an unreasonable cost tothe organisation, another challenge arises. This chal-lenge is in making members of the organisationaware of all the relevant resources available to them.This awareness mechanism must be based on eachindividual’s needs. It must also give the individualthe freedom to tailor it to his/her preferences (e.g.push versus pull, delivery frequency, and individualinterest profile).

Thirdly, design rationale technologies need to bedesigned specifically to suit the needs of the organis-ation in which they will be used [111]. It is virtuallyimpossible for systems to be reused from one organ-isation to the next. Although platforms such asLotus Notes and other intranet platforms have helpeddecrease the time it takes to develop individualapplications, it is difficult to find a reusable architec-ture for a system which would support an entireorganisation. Reuse is made more difficult becausetechnology can only be introduced after work onthe organisational issues discussed above has beeninitiated, and how these issues are resolved willcertainly reflect how technological solutions shouldbe designed.

9.5.2. Design ChallengesAs Davenport and Prusak [112] warn in their book‘if you build it, they may not come’. Being able tobuild a system is only an initial step; the ‘goldstandard’ against which success is measured, how-ever, is whether people will accept and use it. Astechnologists, we did not have much control overthe personal reward systems of the individual usersand management mandate that many [112,111] rec-ommend will enhance usage of the technology, andtherefore we could not motivate our users as such.


However, it has been shown that other factors arealso involved with designing and deploying such asystem that contribute to its success [113,111]. Byusing a ‘human-centred’ approach [114,115], thelevel of use will be strongly affected by the useful-ness and usability of the system deployed.

Following Grudin’s suggestion [113], we need todesign systems so that there are identifiable benefitsto the people who use them. When an individualuses a system, the benefit gained from this experi-ence should encourage him to continue using thesystem. We must strive to design systems in sucha way that there are benefits to the current users,not just the future users. In doing so, the system willhave a better chance of sustaining continued use.

Design rationale tools must support both formaland informal knowledge, making the system flexibleenough so that broad content types were supported[114]. They must support multiple levels of organis-ation of content and design systems so that knowl-edge can be structured at any time after it is entered[35]. We do not want to force the content to betoo structured, but need to provide structuring mech-anisms so that it can be automatically structured orrestructured at a later time.

As Grudin suggested [113], it is best to buildupon an already successful application. The luck, ofcourse, is in finding such an application, and inappropriately defining ‘successful’. Building on anapplication that the user population is already fam-iliar with reduces the overhead of learning to use anew system. Providing a totally new application forstoring and retrieving information increases overheadand correspondingly decreases the probability of asuccessful system introduction.

Finally, builders of design rationale systemsshould borrow ideas from the field of ParticipatoryDesign [116]. Evolutionary Growth [117], theImprovisational model [118], and the frameworkspecified in Zimmermann and Selvin [119]. Jointdesign of a system with the intended users is muchmore likely to succeed than designing for them.

9.5.3. A Final CommentThe need for design rationale is a common problem,but successful design rationale systems are rare. Theneed to record and preserve intellectual capitaldrives organisations to manage knowledge. Ourobjective in this paper is to provide present buildersof design rationale environments a guidebook intothe systems design and implementation issues.

We believe that, as the technological sophisti-cation of both the needed software components andsystems integration tools increase, design rationale

capture and reuse may soon become more wide-spread in business practice. We began this surveyby asking some questions, we conclude by offeringsome tentative answers. The questions we sought toanswer are:

I If design rationale is useful, why are designrationale systems not in widespread use in indus-try?

I How can design rationale systems better supportengineering design?

I What are the major obstacles to the creation oftruly useful and usable design rationale systems?

In conducting this survey, we found many thingsthat surprised us. We expected to find many descrip-tions of design rationale systems and few successfulapplications in the ‘real world’; but we were sur-prised that the number of descriptions was so largeand the number of applications was so small. Thisfinding underscores the importance of our initialquestions.

Looking across all the descriptions of designrationale systems, we see many useful insights andmany good ideas. We summarise these insights andideas with respect to the four issues in our frame-work: approaches, representation schema, captureand retrieval. It is clear, for example, that there isnot one right approach to building design rationalesystems; a process-oriented approach fits better in adynamic design domain and a feature-orientedapproach fits better in a highly standardised designdomain. Similarly, there is not one right approachto representation. A representational approach, forexample, would aid consistency of decision makingwhile a descriptive approach would aid reuse ofdesign components. Further, different representationscan be effectively combined in a single system.Automatic capture of design rationale certainlyseems like the right goal, even though it will be ahard one to achieve. We are less certain aboutautomatic retrieval. The idea is appealing, but find-ing the boundary across which systems become‘intrusive’ rather than ‘helpful’ will, we expect, bea difficult problem.

We were also surprised at the breadth of literaturerelevant to design rationale. Looking through ourreference list, you will find many citations to thefields of engineering, computer science and softwareengineering. Most readers, we expect, will not besurprised to find these citations. Some readers maybe surprised, however, at the number of citationsto fields such as cognitive psychology, sociology,business, management and human-computer interac-tion. The breadth of citations underscores, for us,


that design rationale is best viewed not as an inde-pendent area of investigation, but as a subproblemin the broader area of knowledge management. Aswe indicated earlier in this section, the design ration-ale community has much to learn from (and toteach to) their colleagues in the broader knowledgemanagement community.

Our tentative answer to the three questions aboveis that we know a great deal about approaches,representation schema, capture, and retrieval ofinformation in design rationale systems. There aremany good ideas and insights in current systemsthat should be able to be combined to make moreeffective systems. The primary challenges that wesee are the technical challenges of organising andmanaging knowledge and the design challenges ofusing a human-centred approach to building usefuland usable systems.

Acknowledgements

This work was supported in part by National ScienceFoundation (NSF), Knowledge and Distributed Intelligencein the Information Age (KDI) Initiative Grant CISE/IIS-9873005; CAREER Award CISE/IRIS-9733545 and GrantsENG/DMI-9713718 and CISE/CDA-9729827. Additionalsupport was provided by The National Institute of Stan-dards and Technology (NIST) Grant 60NANB7D0092 andAT&T Labs.

Any opinions, findings and conclusions or recommen-dations expressed in this material are those of the author(s),and do not necessarily reflect the views of the NationalScience Foundation or the other supporting governmentand corporate organisations.

References

1. Lee, J., Lai, K. (1991) What’s in design rationale.Human-Comput. Interaction, 6(3–4), 251–280

2. Buckingham-Shum, S. J., Hammond, N. (1994) Argu-mentation-based design rationale: What use at whatcost? Human-Comput. Stud., 40(4), 603–652

3. Conklin, J. E., Burgess Yakemovic K. C. (1991) Aprocess-oriented approach to design rationale. Human-Comput. Interaction, 6(3–4), 357–391

4. Gruber, T. R., Russell, D. M. (1992) Design knowl-edge and design rationale: A framework for represen-tation, capture, and use. Technical Report KSL 90–45,Knowledge Systems Laboratory, Stanford University

5. MacLean, A., Young, R., Belloti, V., Moran, T. (1991)Questions, options, and criteria: Elements of designspace analysis. Human-Comput. Interaction, 6(3–4),201–250

6. Rosenman, M. A., Gero, J. S. (1994) The what, thehow and the why in design. Appl. Artif. Intell., 8(2),199–218

7. Klein, M. (1993) Capturing design rationale in concur-rent engineering teams. IEEE Computer, 26(1), 39–47

8. Guindon, R., Krasner, H., Curtis, B. (1987) Break-downs and processes during the early activities ofsoftware design by professionals. In: Olson, G. M.(ed.) Empirical Studies of Programmers: SecondWorkshop, Ablex, pp 65–82

9. Prabhakar, S., Goel, A. K. (1998) Functional modelingfor enabling adaptive design of devices for newenvironments. Artif. Intell. in Eng., 12(4), 417–444

10. Ullman, D. G., Dietterich, P. G., Stauffer, L. A. (1988)A model of the mechanical design process based onempirical data. Artif. Intell. for Eng. Design, Analysisand Manuf., 2(1), 33–52

11. Moran, T. P., Carroll, J. M. (eds.) (1996) DesignRationale: Concepts, techniques, and use. LawrenceErlbaum

12. Lee, J. (1997) Design rationale systems: Understandingthe issues. IEEE Expert/Intelligent Systems and theirApplic., 12(3), 78–85

13. Thompson, J. B., Lu, S. C. Y. (1989) Representingand using design rationale in concurrent product andprocess design. In: Chao, N. H., Lu, S. C. Y. (eds)Concurrent Product and Process Design, ASME Win-ter Annual Meeting, ASME, pp 109–115

14. Banares-Alcantara, R., King, J. M. P. (1997) Designsupport systems for process engineering iii – designrationale as a requirement for effective support. Com-put. and Chem. Eng., 21(3), 263–276

15. King, J. M. P., Banares-Alcantara, R. (1997)Extending the scope and use of design rationale. Artif.Intell. for Eng. Design, Analysis and Manuf., 11(2),155–167

16. Fischer, G., McCall, R., Morch, A. (1989) Designenvironments for constructive and argumentativedesign. In: Bice, K., Lewis, C. (eds.), Conference onWings for the Mind, Addison-Wesley, pp 269–275

17. Kunz, W., Rittel, W. (1970) Issues as elements ofinformation systems. Working paper 131, Center forPlanning and Development Research, University ofCalifornia, Berkeley

18. Shipman III, F. M., McCall, R. J. (1997) Integratingdifferent perspectives on design rationale: Supportingthe emergence of design rationale from design com-munication. Artif. Intell. for Eng. Design, Analysisand Manuf., 11(2), 141–154

19. Gruber, T. R., Russell, D. M. (1992) Generative designrationale: Beyond the record and replay paradigm.Technical Report KSL 92–59, Knowledge SystemsLaboratory, Stanford University

20. McCall, R. J. (1991) PHI: A conceptual foundationfor design hypermedia. Design Studies, 12(1), 30–41

21. Fischer, G., McCall, R. (1989) JANUS: Integratinghypertext with a knowledge-based design environment.In: Halasz, F., Meyrowitz, N. (eds.), Hypertext,Addison-Wesley, pp pages 105–117

22. Lubars, M. D. (1991) Representing design depen-dencies in an issue-based style. IEEE Software, 6(4),81–89

23. Mark, W., Tyler, S., McGuire, J., Schlossberg, J.(1992) Commitment-based software development.IEEE Trans. Softw. Eng., 18(10), 870–886

24. Garcia, A. C. B., Howard, C. H. Acquiring designknowledge through design decision justification. Artif.Intell. for Eng. Design, Analysis and Manuf., 6(1),59–71


25. Ramesh, B., Dhar, V. (1992) Supporting systemsdevelopment using knowledge captured during require-ments engineering. IEEE Trans. Softw. Eng., 18(6),498–511

26. Ramesh, B., Sengupta, K. (1995) Multimedia in adesign rationale decision support system. DecisionSupport Syst., 15(3), 181–196

27. Garcia, A. C. B., de Souza C. S. (1997) Add1:Including rhetorical structures in active documents.Artif. Intell. for Eng. Design, Analysis and Manuf.,11(2), 109–124

28. de la Garza, J. M., Alcantara Jr, P. T. (1997) Usingparameter dependency network to represent designrationale. J. Comput. in Civil Eng., 11(2), 102–112

29. de la Garza, J. M., Ramakrishnan, S. (1995) A toolfor designers to record design rationale of a con-structed project. 10th International Conference onApplications of Artificial Intelligence in Engineering,Southampton, U.K. Computational Mechanics Publi-cations, pp 533–540

30. Chandrasekaran, B., Iwasaki, Y. (1993) Functionalrepresentation as design rationale. IEEE Computer,26(1), 48–56

31. Chung, P. W. H., Goodwin, R. (1998) An integratedapproach to representing and accessing design ration-ale. Eng. Applic. Artif. Intell., 11(1), 149–159

32. Myers, K. L., Zumel, N. B., Garcia, P. (1999) Auto-mated capture of rationale for the detailed designprocess. In: Uthurusamy, R: Hayes-Roth, B. (eds.),Eleventh Conference on Innovative Applications ofArtificial Intelligence, AAAI Press, pp 876–883

33. Gruber, T. R., Russell, D. M. (1992) Derivation anduse of design rationale information as expressed bydesigners. Technical Report KSL 92–64, KnowledgeSystems Laboratory, Stanford University

34. Guindon, R. (1990) Knowledge exploited by expertsduring software system design. Int. J. Man-MachineStud., 33, 279–304

35. Shipman III, F. M., McCall, R. J. (1994) Supportingknowledge-base evolution with incremental formaliz-ation. In: Adelson, B., Dumais, S., Olson, J. (eds.),Human Factors in Computing Systems: ‘CelebratingInterdependence’, Boston, MA: ACM/SIGCHI,pp 285–291

36. Brazier, F. M. T., Van Langen, P. H. G., Treur, J.(1997) A compositional approach to modelling designrationale. Artif. Intell. for Eng. Design, Analysis andManuf., 11(2), 125–139

37. Goel, A. (1991) Model revision: A theory of incremen-tal model learning. 8th International Conference onMachine Learning, Chicago, IL. Morgan Kaufman,pp 605–609

38. Doyle, J. (1979) A truth-maintenance system. Artif.Intell., 12(3), 231–272

39. Liang, J., Shah, J. J., D’Souza, R., Urban, S. D.,Ayyaswamy K., Harter, E., Bluhm, T. (1999) Syn-thesis of consolidated data schema for engineeringanalysis from multiple STEP application protocols.Comput. Aided Design, 31(7), 429–447

40. Shah, J. J., Rangaswamy, S., Qureshi, S., Urban, S.,(1999) Design history system: Data models and proto-type implementation. Knowledge Intensive ComputerAided Design, Kluwer, pp 91–114

41. Fischer, G., Lemke, A. C., McCall, R. (1991) Making

argumentation serve design. Human-Comput. Interac-tion, 6(3–4), 393–419

42. Buckingham-Shum, S. J., MacLean, A., Bellotti, V.M. E., Hammond, N. V. (1997) Graphical argumen-tation and design cognition. Human-Comput. Interac-tion, 12(3), 267–300

43. Lee J. (1990) SIBYL: A qualitative decision manage-ment system. In: Winston, P. H., Shellard, S. A. (eds.),Artifical Intelligence at MIT: Expanding Frontiers,Vol. 1, The MIT Press, pp 106–133

44. Franke, D. W. (1991) Deriving and using descriptionsof purpose. IEEE Expert/Intelligent Systems and theirApplic., 6(2), 41–47

45. Bobrow, D. G. (1984) Qualitative reasoning aboutphysical systems: An introduction. Artif. Intell., 24(1–3), 1–5

46. Fowler, J. E. (1996) Variant design for mechanicalartifacts: A state-of-the-art survey. Eng. with Comput.,12, 1–15

47. Goel, A. (1991) A model-based approach to caseadaptation. 13th Annual Conference of the CognitiveScience Society, Cognitive Science Society, LawrenceErlbaum, pp 143–148

48. MacGregor, R. (1990) The evolving technology ofclassification-based knowledge representation systems.In: Sowa, J. F. (ed.), Principles of Semantic Networks:Explorations in the Representation of Knowledge.Morgan Kaufman

49. Mann, W. C., Thompson, S. A. (1987) Rhetoricalstructure theory: A theory of the text organization.Technical Report ISURS-87-190, InformationScience Institute

50. Sowa, J. F. (1984) Conceptual Structures: InformationProcessing in Mind and Machine. Addison Wesley

51. Brazier, F. M. T., Van Langen P. H. G., Treur, J.,Wijngaards, N. J. E., Willems, M. (1996) Modellingan elevator design task in DESIRE: the vt example.Int. J. Human-Comput. Stud., 44(3–4), 469–520

52. Poltrock, S. E., Grudin, J. (1999) Cscw, groupwareand workflow: Experiences, state of the art, and futuretrends. ACM SIGCHI Tutorial, Pittsburgh, PA

53. Brazier, F. M. T., Van Langen, P. H. G., Treur, J.(1995) Modelling conflict management in design: Anexplicit approach. Artif. Intell. for Eng. Design, Analy-sis and Manuf., 9(4), 355–366

54. Gruber, T. R., Russell, D. M. (1991) Interactive acqui-sition of justifications: Learning why by being toldwhat. IEEE Expert/Intelligent Systems and theirApplic., 6(4), 65–75

55. Stahovich, T. F. (1997) Interpreting the engineer’ssketch: A picture is worth a thousand constraints. In:Anderson, M. (ed.), AAAI Symposium on Reasoningwith Diagrammatic Representations II, Providence,Rhode Island. AAAI Press, pp 31–38

56. Stahovich, T. F., Davis, R., Shrobe, H. (1996) Gener-ating multiple new designs from a sketch. TheNational Conference on Artificial Intelligence, Port-land, Oregon. AAAI Press, pp 1022–29

57. Aamodt, A., Plazas, E. (1994) Case-based reasoning:Foundational issues, methodological variations, andsystem approaches. AI Comm., 7(1), 39–52

58. Bardasz, T., Zeid, I. (1991) Applying analogical prob-lem solving to mechanical design. Int. J. Comput.Aided Design, 23(3), 202–212


59. Bardasz, T., Zeid, I. (1992) Cognitive models of mem-ory for mechanical design problems. Int. J. Comput.Aided Design, 24(6), 327–342

60. Maher, M. L., Balachandran, M. B., Zhang, D. M.(1995) Case-Based Reasoning in Design. LawrenceErlbaum

61. Gruber, T. R. (1992) Model formulation as a problem-solving task: Computer-assisted engineering modeling.Int. J. Intell. Syst., 8, 105–128 (Also available astechnical report KSL-92-57 at Knowledge SystemsLaboratory, Stanford University)

62. Suh, N. P. (1990) The Principles of Design, Vol. 1.Oxford University Press

63. Lakin, F., Wambaugh, H., Leifer, L., Cannon, D.,Sivard, C. (1989) The electronic design notebook:Performing medium and processing medium. The Vis-ual Computer: Int. J. Comput. Graphics, 5, 214–226

64. Sycara, K., Navinchandra, D. (1992) Retrieval stra-tegies in a case-based design system. In: Tong, C.,Sriram, D., (eds.), Artificial Intelligence in EngineeringDesign, Vol. II. Academic Press

65. Laiserin, J. (1999) A new kind of CAD–Communi-cation-Aided Design. CADENCE, pp 18–26

66. Ginsberg, M. L. (1991) Knowledge interchange for-mat: The KIF of death. AI Mag., 12(3), 57–63

67. Bobrow, B. G., Norman, D. (1977) An overview ofKRL: A knowledge representation language. CognitiveSci., 1, 3–46

68. Brachman, R. J., Schmolze, J. G. (1985) An overviewof the KL-ONE representation system. Cognitive Sci.,9, 171–216

69. Evett, M. P., Hendler, J. A., Spector, L. (1994) Parallelknowledge representation on the Connection Machine.J. Parallel and Distributed Comput., 22, 168–184

70. Stein, L. A. (1996) Science and engineering in knowl-edge representation and reasoning. AAAI Mag., 17(4),77–83

71. Brachman, R. J., Levesque, H. J. (eds) (1985) Read-ings in Knowledge Representation. Morgan Kaufmann

72. Chittaro, L., Kumar, A. N. (1998) Reasoning aboutfunction and its application to engineering. Artif.Intell. in Eng., 12(4), 331–226

73. Kumar, A. N., Upadhyaya, S. J. (1998) Component-ontological representation of function for reasoningabout devices. Artif. Intell. in Eng., 12(4), 399–415

74. Kim, J., Ringo Ling, S., Will, P. (1997) Ontologyengineering for active catalog. Technical report, TheUniversity of Southern California, InformationSciences Institute

75. Schlenoff, C., Denno, P., Ivester, R., Libes, D., Szyk-man, S. (1999) An analysis of existing ontologicalsystems for applications in manufacturing. ASMEDesign Engineering Technical Conferences, 19th Com-puters and Information in Engineering Conference,New York, NY. ASME Press

76. Szykman, S., Racz, J. W., Sriram, R. D. (1999) Therepresentation of function in computer-based design.ASME Design Engineering Technical Conferences,11th International Conference on Design Theory andMethodology, New York, NY. ASME Press

77. Szykman, S., Senfaute, J., Sriram, R. D. Using XMLto describe function and taxonomies in computer-based design. ASME Design Engineering Technical

Conference, 19th Computers and Information inEngineering Conference, New York, NY. ASME Press

78. Chen, A., McGinnis, B., Ulman, D. G., Dietterich, T.G. (1990) Design history knowledge representationand its basic computer implementation. In: Rinderle,J. R. (ed.), Proceedings of the Design Theory andMethodology Conference, ASME, 175–184

79. Catron, B., Ray, S. (1991) Alps: A language forprocess specification. Int. J. Comput. IntegratedManuf. 4(2), 105–113

80. Schlenoff, C., Knutilla, A., Ray, S. (1996) Unifiedprocess specification language: Requirements formodeling process. Technical Report NISTIR 5910,National Institute of Standards and Technology, Gai-thersburg, MD

81. Dong, A., Agogino, A. (1997) Text analysis for con-structing design representations. Artif. Intell. in Eng.,11(2), 65–75

82. Thompson, J. B., Liu, S. C.-Y. (1990) Design evol-ution management: A methodology for representingand utilizing design rationale. Proceedings of theSecond International ASME Conference on designTheory and Methodology

83. Urban, S. D., Ayyaswamy, K., Fu, L., Shah, J. J.,Liang, J. (1999) Integrated product data environment:Data sharing across diverse engineering applications.Int. J. Comput. Integrated Manuf., 12(6), 525–540

84. Liang, J., Shah, J. J., Souza, R. D., Urban, S. D.,Ayyaswamy, K., Harter, E., Bluhm, T. (1999) Syn-thesis of consolidated data schema for engineeringanalysis from multiple step application protocols. Int.J. Comput. Aided Design, 21, 429–447

85. Xue, D., Yadav, S., Norrie, D. H. (1999) Knowledgebase and database representation for intelligent concur-rent design. Comput. Aided. Design., 31(2), 131–145

86. Steels, L. (1990) Components of expertise. Al Mag.,11(2), 28–49

87. Gruber, T. R. (1990) The role of standard knowledgerepresentation for sharing knowledge-based tech-nology. Technical Report KSL 90–53. Knowledge Sys-tems Laboratory, Stanford University

88. Cutkosky, M. R., Tenenbaum, J. M., Glicksman, J.(1996) Madefast: Collaborative engineering over theinternet. Comm. ACM, 39(9), 78–87

89. Olsen, G. R., Cutkosky, M., Tenenbaum, J. M.,Gruber, T. R. (1994) Collaborative engineering basedon knowledge sharing agreements. ASME DatabaseSymposium. Minneapolis, MN

90. Tove, G., Cutkosky, M. R., Leifer, L. J., Tenenbaum,J. M., Glicksman, J. (1993) Share: A methodologyand environment for collaborative product develop-ment. IEEE Workshop on Infrastructure for Collabor-ative Technologies (Also available as Stanford CDR-TR #19930507)

91. Cutkosky, M. R., Tenenbaum, J. M. (1992) Towarda framework for concurrent design. Int. J. Syst. Auto-mation: Res. and Applic., 1(3), 239–261

92. Cutkosky, M. R., Engelmore, R. S., Fikes, R. E.,Genesereth, M. R., Gruber, T. R., Mark, W. S., Tenen-baum, J. M., Weber, J. C. (1993) Pact: An experimentin integrating concurrent engineering systems. IEEEComputer, 26(1), 28–38

93. Sriram, D., Stephanopoulos, G., Logcher, R., Gossard,D., Groleau, N., Serrano, D., Navinchandra, D. (1989)


Knowledge-based systems applications in engineeringdesign research at mit. Al Mag., 10(3), 79–96

94. Sriram, R. D. (1997) Intelligent Systems for Engineer-ing: A Knowledge-Based Approach. Springer-Verlag

95. Duffy, A. H. B. (1997) The ‘what’ and ‘how’ oflearning in design. IEEE Expert/Intelligent Systemsand their Applic., 12(3), 71–76

96. Sim, S. K., Duffy, A. H. B. (1998) A foundation formachine learning in design. Artif. Intell. for Eng.Design, Analysis and Manuf., 12(2), 193–209

97. Umeda, Y., Tomiyama, T. Functional reasoning indesign. IEEE Expert/Intelligent Systems and theirApplic., 12(2), 42–48

98. Duffy, S. M., Duffy, A. H. B. (1996) Sharing thelearning activity using intelligent cad. Artif. Intell. forEng. Design, Analysis, and Manuf., 10(2), 83–100

99. Gero, J. S., Sudweeks, F. (eds.), Second InternationalConference on Artificial Intelligence in Design.Kluwer Academic

100. Liu, X., Gan, M. (1991) A preliminary structuraldesign expert system (spred-1) based on neural net-works. In: Gero, J. S. (ed). First International Confer-ence on Artificial Intelligence in Design (AID’91),Edinburgh, Scotland, pp 785–799.

101. Maher, M. L., Brown, D. C., Duffy, A. H. B. (1994)Special issue on machine learning in design. Artif.Intell. for Eng. Design, Analysis and Manuf., 8(2),81–82

102. Schreiber, G., Wielingas, B. (1997) Configuration-design problem solving. IEEE Expert/Intelligent Sys-tems and their Applic., 12(2), 49–56

103. Sycara, K., Navinchandra, D. (1989) Representingand indexing design cases. Proceedings of the SecondInternational Conference on Industrial EngineeringApplications of Artificial Intelliegence and ExpertSystems, Tullahoma, T.N. ACM Press, pp 735–741

104. Mostow, J. (1989) Design by derivational analogy:Issues in the automated replay of design plans. Artif.Intell., 40(1–3), 119–184

105. Pena-Mora, F., Vadhavkar, S. (1997) Augmentingdesign patterns with design rationale. Artif. Intell.For Eng. Design, Analysis and Manuf., 11(2), 93–108

106. Tazi, S., Novick, D. (1998) Design rationale forcomplex system documentation. Conference on Com-plex Systems, Intelligent Systems and Interface,Nimes, France

107. Carey, T., McKerlie, D., Wilson, J. (1996) HCIdesign rationale as a learning resource. In: Moran, T.

P., Carroll, J. M. (eds.), Design Rationale Concepts,Techniques and Use, Ist ed. Lawrence Erlbaum.pp 373–392

108. Casaday, G. (1996) Rationale in practice: Templatesfor capturing and applying design experience. In:Moran, T.P., Carroll, J. M. (eds.), Design RationaleConcepts, Techniques and Use, Ist ed. LawrenceErlbaum, pp 351–372

109. Johnson, C.W. (1996) Literate specification: Usingdesign rationale to support formal methods in thedevelopment of human-machine interfaces. Human-Comput. Interaction, 11(4), 291–320

110. Putnam, R. D. (1993) Making Democracy Work:Civic Traditions in Modern Italy. Princeton Univer-sity Press

111. Orlikowski, W. J. (1992) Learning from notes:Organizational issues in groupware implementation.Conference on Computer Supported CooperativeWork (CSCW), Toronto, Canada. ACM/SIGCHI,pp 362–369

112. Davenport, T.H., Pruzak, L. (1998) Working Knowl-edge: How Organizations Manage What They Know,Vol. 1. Harvard Business School Publishing

113. Grudin, J. (1994) Groupware and social dynamics.Comm. ACM, 37(1), 93–105

114. Davenport, T. H. (1994) Saving IT’s soul: Human-centered information management. Harvard Bus.Rev., 94(2), 39–53

115. Mackayn, W. (1990) Patterns of sharing customizablesoftware. Conference on Computer Supported Coop-erative Work (CSCW), Los Angles, CA.ACM/SIGCHI, pp 209–221

116. Greenbaum, J., Kyng, M. (eds.) (1991) Design atWork – Cooperative Design of Computer Systems.Laurence Erlbaum

117. Fischer, G. (1994) Domain-oriented design environ-ments. Applications and Impacts, Information Pro-cessing, pages Hamburg, Germany. International Fed-eration for Information Processing, North-Holland,pp 115–122

118. Orlikowski, W. J., Hofman, J. D. (1997) An impro-visational model for change management: The caseof groupware technologies. Sloan Manage. Rev.,38(2), 11–21

119. Zimmermann, B., Selvin, A. M. (1997) A frameworkfor assessing group memory approaches for softwaredesign projects. Conference on Designing InteractiveSystems, New York, N.Y. ACM Press, pp 417–426

A Survey of Design Rationale Systems: Approaches ... · A Survey of Design Rationale Systems 211...

Documents

Transcript of A Survey of Design Rationale Systems: Approaches ... · A Survey of Design Rationale Systems 211...