Design Rationale Systems: Understanding the Issues

Jintae Lee, University of Hawaii

IN THE LAST FEW YEARS, INTEREST OST CURRENT DESIGN RATIONALE SYSTEMS FAIL TO in design rationales has grown. Design ratio- M nales are important tools because they can CONSIDER PRACTICAL CONCERNS, SUCH AS COST-EFFECTIVE include not only the reasons behind a design decision but also the justification for it, the USE AND SMOOTH INTEGRATION. THE AUTHOR IDENTIFIES other alternatives considered, the tradeoffs SEVEN TECHNICAL AND BUSINESS ISSUES AND DESCRIBES evaluated, and the argumentation that led to the decision. The use of a design rationale sys- THEIR IMPLICATIONS. tem—a tool for capturing and making design rationales easily accessible—can thus improve dependency management, collaboration, re- to address all these issues. Some will empha- (future designers and maintainers). The use, maintenance, learning, and documenta- size one thing; others, another. Indeed, these arrows between services indicate that a ser- tion. However, if such systems are to keep pace issues delineate the major dimensions along vice at the end of the arrow (tail) supports the with the growing and changing demands of which a design rationale system is likely to dif- service at the beginning (arrowhead). For design technology, researchers and develop- fer. But if the community can better understand example, using design rationales to support ers must begin to answer certain questions. each of these issues, it will be more equipped dependency management or problem solving In this article I identify seven issues, which to produce design rationale systems that suc- or simulation and diagnosis improves design I have derived from an informal (undocu- ceed in their particular application areas. and maintenance, and supports learning. mented) survey of major existing design Using design rationales to support project rationale systems and discussions with work- management helps support collaboration, shop participants, including those in the 1992 What services to provide requirements engineering, or reuse—any one AAAI Design Rationale Capture and Use of these in turn can result in better design. Workshop.1 The issues identified include The services a design rationale system what services to provide; what parts of the provides will determine almost all other Better design support. Well-structured de- rationale to represent explicitly; how to rep- aspects of its design, such as what to repre- sign rationales can help designers track the resent, produce, and access rationales and sent and how to represent the rationales. issues and alternatives being explored and manage them cost effectively; and how to Figure 1 shows common services classi- their evaluations. This, in turn, clarifies the integrate the design rationale system. fied into four major groups according to the overall structure of the reasoning process and My goal in writing this article is to help user group who benefits: better design supports decision making. In some cases, of researchers and developers of future design (designers), better maintenance (system course, all this information can actually hin- rationale systems understand the available maintainers), learning (new trainee, students, der design activities by imposing unneces- options and tradeoffs. No one system can hope learning programs), and documentation sary overhead or breaking the natural flow

Better design Better maintenance Learning support Documentation support support of design activities, but in most cases this clarification leads to better design. Theoretically, one design rationale system can support all the services described here Dependency Problem-solving Simulation and both during design and before—for exam- management support diagnostics support ple, during requirements definition.

Dependency management. Design can be Collaboration Requirement Reuse support viewed as the process of managing depen- support engineering support dencies to yield a product that honors all Project management dependencies among requirements and the support components that implement them. Design rationales can make explicit dependency relations among design parts, decisions, argu- Figure 1. Services provided by most design rationale systems. Arrows between services indicate support relations. ments, and alternatives so that they work together consistently. Some systems provide dependency management simply by display- arguments evaluating the alternatives. that learn by analogy (see articles by Ashok ing issues that depend on the current issue,2 For reuse to be successful and cost- Goel and Alex Duffy in this issue). while more complex systems actually detect effective, however, the design rationale sys- conflicts among various constraints.3 tem must also make it cost-effective to sort Documentation support. Design rationales out knowledge that is outdated or context- can be used to automatically generate docu- Collaboration/project management. Design sensitive. Without this provision, its sugges- mentation. I mention documentation as a rationales also provide a common founda- tions must be taken with a large grain of salt. category apart from better design because tion when multiple parties are involved. Mary Lou Maher and Andres Gomez de documents help others besides designers. Explicitly represented rationales can provide Silva Garza discuss other problems in the Managers or users can use them to evaluate common vocabulary and project memories, reuse of design knowledge.6 the design. Lawyers can use them to deter- and make it easier to negotiate and reach con- mine if the design is intellectual property. In sensus. In Shared-DRIM,3 for example, Better maintenance support. Because fact, Frank Shipman and Ray McCall,8 who whenever a design agent makes a recom- design rationales explain the design decisions articulate three main perspectives of design mendation, the system checks to see if an made, they can also help maintain the design. rationales—argumentation, communication, existing recommendation might conflict with Most existing systems provide this service and documentation—argue that the docu- it. If so, the system informs all relevant par- in its simplest form: comments documenting mentation perspective has been the most suc- ties about the change made to the object, program codes. EES,7 on the other hand, cessful and should provide a model for the identifies the cause of the change, and looks extracts much richer development rationales design of design rationale systems (see “How for a constraint violation. In this way, inter- and uses them to generate more sophisticated to access rationales”). actions among, say, engineers and contrac- explanations for system maintenance. tors are reduced, which helps design proceed more efficiently. Learning support. Design rationales can What to represent explicitly Design rationales also help designers or help both people and systems learn mutually computational agents track unresolved issues and interactively. Janus,8 for example, pro- It is impossible to represent an entire and their dependencies, train newcomers, vides computational agents, or critics, which design rationale explicitly. Rationales are restore interrupted designs, and support dis- have access to design rationales and monitor embedded not only in formal documents tributed task allocation. human designers. When a critic encounters such as design specifications, meeting ab- a human decision that is suboptimal accord- stracts, and interface documents, but also in Reuse/redesign/extension support. Design ing to its knowledge, it presents the designer informal media such as phone conversations, rationales help reuse in two ways. First, they with an appropriate recommendation along blackboard sketches, and discussions over can serve as indices to past knowledge (sim- with its rationales. The designer can either lunch. In fact, almost anything in a design ilar designs, parts, problems encountered). agree and accept them, thus acquiring a new process may be a part of a design rationale SoftDA,4 for example, supports reuse by piece of knowledge, or disagree and teach as long as it is represented and can be used to acquiring the relationship information about the system by supplying a new piece of trace a reason for some aspect of the design. designs and requirements and using it to knowledge so that the critic knows better Whatever is represented, however, must be index documents and codes. next time. accessible, so it must have some structure. Designers can also reuse the rationales Of course, many learning systems attempt This is why, say, videotaping all designer themselves. For example, the precedent man- to pick up knowledge from past problem- interaction would not be suitable. The agement in Sibyl5 uses the goals from past solving traces. And if you view a problem- unstructured nature of the recording would decision rationales to suggest potentially rel- solving process as the process of designing a make it difficult to access exactly what is evant alternatives, and uses both goals and solution, technically all these systems can be needed and use that information in any quan- alternatives to retrieve potentially relevant design rationale systems, especially those titative way.

MAY/JUNE 1997 79 .

Functional dependency. As is true for any maximum expected utility). With the evalu- Systems also differ in the richness of the representation, what you represent depends ation layer, the individual evaluations be- constructs they provide to represent a par- on what you want to do with it. Shipman and come accessible to the system, which might ticular space. For example, the constructs in McCall8 note that if design rationales are used use them to rank the alternatives or recom- DRCS9 for the evaluation space let design- primarily to ensure careful reasoning and bet- pute the evaluations when related evaluations ers characterize the evaluation of alternative ter problem solving among the designers change. The criteria layer (Figure 2d) makes design specifications, reveal how well spec- (argumentation perspective), then the logical explicit the criteria used and their relations ifications have been achieved (has-impor- structure of the reasoning must be made (mutually exclusive, tradeoffs, specializes). tance, is-more-important-than, has-subat- explicit so that the system can do the logical With constructs for this layer, the system can tribute, has-subspecification, specification, bookkeeping and detect any potential errors. group evaluations and the arguments by version, achieves), and provide evaluation On the other hand, if the rationales are used alternative and criterion, display them (in a history (version, achieves relation between primarily to enable outsiders to understand or table, for example), and update evaluations version and specification). However, these regulate design activities (documentation per- when the relevant criteria change. The issue services come at the cost of high overhead. spective), then only the results of the reason- layer (Figure 2e) makes explicit the individ- Generally, the less a system represents, the ing and their immediate explanations must be ual issues and their relations (generates, less overhead it will impose—but the trade- documented—not all the possibilities and the depends-on, replaces). With the issue layer, off is fewer services. dead ends explored. Finally, if rationales are the system can now track all issues that used to support project management, then Design artifact layer. If a design activity is constructs and attributes that reflect project viewed solely as a set of decision-making status must be provided, such as unresolved steps, the rich information about how the or pending issues and deadlines and the peo- design components are related and how the ple responsible for them. SYSTEMS ALSO DIFFER IN THE information relates to individual decisions RICHNESS OF THE CON- will remain implicit, if it is there at all. The Generic structure. In my survey of existing design artifact layer takes a broader view, and proposed design rationale systems and STRUCTS THEY PROVIDE TO making explicit both decision-making steps in my discussions with workshop partici- REPRESENT A PARTICULAR and the related information. pants, I was able to find a generic structure to A system can also provide constructs for what was being represented—despite major SPACE. GENERALLY, THE LESS representing design artifacts but not decisions. differences in system implementation. This For example, FR10 expresses only the func- A SYSTEM REPRESENTS THE structure takes the form of layers, with some , tional or causal relation among design com- layers specializing other layers or requiring LESS OVERHEAD IT WILL ponents and requirements. Again, the system’s the presence of others. I identified three intended function explains this representation. major layers: decision, design artifact, and IMPOSE—BUT THE TRADEOFF The author notes that the design rationales can design intent. IS FEWER SERVICES. be used for tasks such as simulation, verifica- tion, and diagnosis, but the system would not Decision layer. The decision layer charac- be able to answer questions about the alterna- terizes the generic structure of a decision depend on a particular issue, all issues that tives and arguments explored. process, regardless of use. It comprises five are yet to be resolved, issues that replace a Systems also differ in the richness of the sublayers: issue, argument, alternative, eval- given issue, and so on. constructs they provide for this layer. Colin uation, and criteria. Figure 2 shows how pro- The constructs underlying these sublayers Potts and Glen Bruns11 designed a system that viding additional constructs progressively appear under different names and not all are explicitly introduces a construct in this space for each sublayer can differentiate the com- always present explicitly. However, even (artifact) and relates it to the decision layer. ponents of design rationales and enrich their systems that do not make them explicit rep- The artifact-synthesis layer in DRCS pro- representation.5 The argumentation layer resent them implicitly as text. For example, vides a richer set of constructs such as mod- (Figure 2a) makes explicit the arguments gIBIS2 explicitly represents only the deci- ule, interface, connection, and constraints for underlying a decision and their relations sion layer, calling it “issue,” the alternative representing artifacts and related operations. (supports, refutes, qualifies). The alternative layer (position), and the argument layer Although a design rationale system should layer (Figure 2b) makes explicit individual (arguments). DRL5 provides similar con- not be expected to represent or reason about alternatives and their relations (component- structs for the sublayers, calling them deci- all domain-specific design artifacts, it should of, incompatible, specializes). With con- sion problem, alternative, and claim, respec- at least provide a way to link design rationale structs for this layer (and the constructs link- tively, and adds constructs for the criteria objects (such as those in the decision layer) ing them to those in the argument layer), the layer (criteria). Of course, a design rationale to relevant design artifacts. For example, a system can sort an undifferentiated body of system must provide constructs for a layer system need not provide a construct such as arguments and associate them with individ- before it can see the designer’s actions. Hydraulic Jack, but it should provide a con- ual alternatives. Hence, if the system supports comparing struct, say Artifact, that it knows can be The evaluation layer (Figure 2c) makes alternatives along different criteria, it must decomposed into other artifacts, each of explicit the evaluation measure and the rela- also provide constructs for representing the which can be associated with an issue or a tions used (nominal, ordinal, real values, alternative and the criteria spaces. set of constraints.

80 IEEE EXPERT .

Artifact Criterion i (bicycle) Argument layer Alternative layer Criteria layer

Criterion i

Arguments relevant to Evaluation layer the design of the artifact Arguments about the relation between criteria i and j (a)

Alternative layer

Arguments about criterion i Arguments about criteria j Alternative i Alternative j (racing bike) (mountain bike) (d) Arguments about the relation between alternatives i and j Issue layer Arguments about alternative i Arguments about Issue i alternative j Criteria layer

(b) Alternative layer Evaluation layer

Evaluation i (good) Evaluation j (poor) Issue j Evaluation Arguments about layer issue j Alternative layer

Arguments about the relation between evaluations i and j

Arguments about the relation (e) Arguments about issue i between i and j

Arguments about Arguments about evaluation i evaluation j (c)

Figure 2. A progressively differentiated representation of design rationales within each of five sublayers in the decision layer.

Design intent layer. The third layer represents How to represent rationales and raw drawings. Informal descriptions are the metainformation underlying design deci- easy to create, but the system cannot interpret sions, such as intents, strategies, goals, and The details of how design rationales are to them, making them ill-suited for most com- requirements. Once represented, this layer be represented will depend on the system’s putational services. The Electronic Notebook, allows a design rationale system to reason representation language. However, the degree developed by Fred Lakin of the Performing about the goal, intent, or plan responsible for of formality is a more generic issue. For the Graphics Company, attempts to overcome this a given design. For example, from goals the sake of discussion, I assume a representation limitation by using parsing technology. How- system can derive criteria for evaluating can be informal, semiformal, or formal, ever, the technology is not yet mature enough alternatives so that when goals change, it can although formality is typically a continuum, to produce reliable interpretations of complex update or at least flag the criteria as outdated. not a set of categories with thresholds. descriptions. The constructs provided for this layer range Once again, the choice of approach depends A semiformal representation is best if the from simple constructs, such as objective and largely on the services the system will pro- primary services are to help people archive, goal to complex constructs that capture rela- vide. Informal representation captures ratio- retrieve, and examine the reasons for their tions, such as is-more-important and has- nales in an unstructured form: descriptions in decisions. In a semiformal representation, higher-priority. a natural language, audio/video recordings, only parts of the representation are computer

MAY/JUNE 1997 81 .

readable; the rest is informal. In the systems the incremental formalization approach is still Record-and-replay. In this approach, ratio- with a semiformal representation, such as appealing because it changes creation to the nales are captured as they unfold—for exam- Sibyl,5 the user interacts typically with dif- easier process of reaction and modification. ple, as designers use a shared database to raise ferent types of templates by filling out their issues, propose alternatives and criteria, and attributes, either by typing in a natural lan- enter evaluations. The rationales can be cap- guage or by selecting from a menu of options. How to produce rationales tured synchronously (via videoconferencing A semiformal representation can support or a shared screen that participants use to inter- many computational services not possible Design rationales can be produced in act with one another) or asynchronously (via with an informal representation and may even many ways, with the system participating bulletin board or e-mail-based discussion). require less overhead in capturing rationales entirely alone, somewhat, or not at all. The Systems that have informal and semiformal because the system can suggest what infor- approaches described here are in order of representations tend to use this approach mation is expected (typed forms and options). minimum to maximum system participation. because a representation that is too rich or too However, the set of computational services formal would create excessive overhead and would depend on how much of the represen- Reconstruction. In this approach, people disrupt the flow of design activities. tation was formal. produce design rationales without using the In a formal representation, objects and rela- system. They can do so by reasoning from Methodological byproduct. In this approach, tions are defined as formal objects that the their existing knowledge (introspection), design rationales naturally emerge from the system can interpret and manipulate using process of designers following a certain formal operations. The creation of design method. For example, in EES, the developers rationales thus becomes a matter of creating of an expert system follow a specific method a knowledge base in some formal language. that EES supports. The method’s steps are in The kind of formal representation will depend FORMALIZING KNOWLEDGE IS essence different kinds of refinements and on the operations to be performed (deductive COSTLY. ONE WAY TO REDUCE reformulations, which the system captures and inference, associate defaults, inheritance). It uses to generate explanations. Another exam- can be any one of several standard represen- COST IS TO FORMALIZE IT ple is the transformational approach,14 in tations: rules, frames, and logic. An example which a design rationale is defined as a trace INCREMENTALLY ESSENT is any machine-learning system that uses its — - of the decomposition of the heuristic methods past problem-solving traces for future prob- IALLY TRANSFORMING A into submethods and finally into applied trans- lem solving. formations. The designer uses the transfor- The more formally rationales are repre- SEMIFORMAL REPRESENTATION mations to verify that the derived artifact sented, the more services the system can pro- TO A FORMAL ONE. meets all specifications. vide. However, formalizing knowledge is This approach is appealing because the costly. One way to reduce cost is to formalize user benefits from the method and the ratio- it incrementally—essentially transforming a conducting interviews with those involved nales are captured at a relatively low cost. semiformal representation to a formal one. in the design, or capturing rationales in raw The challenge is to provide a method that Thus, rationales can be captured with less form, such as video, and then translating really does help the user without imposing overhead (because they are captured in a semi- them into a more structured form. Yet another excessive overhead or restrictions. formal state), but once formalized can be used way is to reverse-engineer a design by try- to support more computational services. ing to infer a plan from the design artifact Apprentice. In this approach, the system gen- uiSibyl,12 for example, starts with an infor- itself through a general knowledge of func- erates rationales by essentially “looking over mal requirements description, extracts rele- tions and device behaviors. the designer’s shoulder” and asking questions vant keywords, and determines if it can Reconstruction allows more careful reflec- whenever it does not understand or disagrees replace or describe any keywords with exist- tion on the representation and layout of the with the designer’s action. ADD,15 for exam- ing formal objects. If not, it attempts to help rationales and does not disrupt the designers’ ple, learns about the features that make a spe- formalize the keywords by offering poten- activities. Jeff Conklin and K. Burgess- cific case different from a standard one. tially related formal objects. Gerhard Fischer Yakemovic2 report on using gIBIS at NCR, Whenever the designer’s proposed action dif- and Kumiyo Nakakoji of the University of saying that the reconstruction process helped fers from ADD’s expectations, it will ask the Colorado attempt to incrementally formalize them identify several design omissions that designer to justify or explain the difference. rules or domain objects from informal texts, would have cost three to six times more than Later, it answers queries for design rationales using keywords.13 mSibyl, proposed by the cost of capturing and reconstructing the by using both its domain knowledge and the Lukas Reucker and Warren Seering of the rationales. Shipman and McCall8 claim that designer-supplied justifications. Janus16 also Massachusetts Institute of Technology, offers the success of the documentation perspective uses this approach. still another alternative: The user supplies a of design rationales (as opposed to the com- Both the user and system benefit from this restricted form of English sentence as an munication and argumentation perspectives) interaction. The user benefits if the system is attribute value of a semiformal object such as owes much to the post-hoc creation of docu- right; the system learns something if it is Decision and the system parses it into a for- mentation. On the down side, the cost of wrong. In addition, rationales are captured in mal language. Although the system’s attempt reconstruction is high and it may introduce the the context of use, when the relevant knowl- to formalize hardly succeeds the first time, biases of the person producing the rationales. edge is fresh in the designer’s mind and new

82 IEEE EXPERT .

knowledge can be anchored in old. However, the issue of how to make a system understand nales in which the user and the system mutu- for this approach to be viable, it must create the designer’s actions enough to ask intelli- ally benefit is an example, although even an initial knowledge base rich enough to gent questions at appropriate times without here the extra time and attention spent inter- understand most of the designer’s actions and seeming obtrusive. Much more research is preting and answering questions is still a cost ask intelligent questions when it does not. needed before a system-initiative approach that requires compensation. becomes viable. When the cost bearer is not the same as the Automatic generation. In the simplest form Another critical issue associated with beneficiary, providing a cost-effective sys- of this approach, the system generates design design rationale access is intelligent index- tem becomes more problematic. In fact, as rationales automatically from an execution ing. Designers will be disrupted if the sys- Jonathan Grudin of the University of Cali- history. An expert system that uses a trace of tem’s response is slow, no matter how appro- fornia, Irvine, points out, many groupware its rule invocations to explain the why and priate its timing might be. A special case of systems fail exactly because of this mis- how of its actions is an example. This ap- the tradeoff between representational for- match.17 For example, most online meeting proach has the appeal of creating rationales mality and computational services (described schedulers fail because they require people at little cost to the user later and of being able earlier) is the tradeoff between the structure in to maintain their local calendars online, even to maintain consistent and up-to-date ratio- rationale representation and ease of retrieval. though the only beneficiaries are those nales. However, it also has the high initial Incremental formalization provides an inter- responsible for scheduling the meeting. cost of compiling the knowledge needed to esting approach to the indexing problem. For Grudin recommends either that the connec- construct the rationales. Furthermore, to go tion between the contributor and the benefit beyond the simple explanatory model based be made clear to all group members, or, bet- on execution traces, many issues at the core ter still, that there be a process along with the of machine-learning research must be re- technology that delivers some benefit to the solved: what parts of the problem-solving WHEN THE COST BEARER IS contributor. For example, whenever a de- trace must be captured and how, how to infer NOT THE SAME AS THE signer benefits from part of a rationale, the rationales from the trace, how to assess their system might allow the designer to send relevance, and how to adapt them to the cur- BENEFICIARY, PROVIDING A compliments to the contributor, which man- rent situation. COST-EFFECTIVE SYSTEM agers and others can see. BECOMES MORE PROBLEMATIC. How to access rationales IN FACT, MANY GROUPWARE How to integrate the system A design rationale system need not make SYSTEMS FAIL EXACTLY Integration is concerned with integrating rationales directly accessible to the user. How- the use of a design rationale system with all ever, accessibility lets the user directly exam- BECAUSE OF THIS MISMATCH. the varied aspects of design activities. It must ine, update, or revise rationales, making be able to integrate design activities more cost-effective and effi- example, MIT’s mSibyl uses the formal rep- cient. Such systems can be classified as user- resentation of knowledge about mechanical • Design rationales of multiple users initiative or system-initiative, depending on artifacts to provide more intelligent indexing despite heterogeneous mediums (video, whether the user or the system initiates access. and matching of design rationales. audio, text) and/or platforms (Unix, Win- In a user-initiative system, the user decides dows, Mac OS). the parts of the design rationale to examine • Design rationales with other objects that and when or how to look at them. These sys- How to manage rationales serve different functions—for example, tems must help the user become aware of cost-effectively to link design rationales to objects in what exists and make it easy to find the CAD or database modules. desired parts. Most systems adopt simple Like anything else, a design rationale sys- • Different types of representation (object- versions of query and navigational aids tem will not be used if the cost outweighs the oriented vs. rule-based, procedural vs. (trees, zoomable graphical views), but many benefits. The benefits are the services the sys- declarative, formal vs. informal). useful navigational tools such as the fish-eye tem can provide. The cost is primarily the view and guided tour are still not being used. cost of producing the rationales in a form that Integration, like cost-effective rationale In a system-initiative system, on the other can support the services. The fixed cost, such management, has not received much research hand, the system decides when and how to as building the system or the initial knowl- attention in the context of design rationale present which parts of the rationales. Such edge base, is not a big problem as long as the systems. Only a few systems have attempted systems must have enough knowledge to cumulative benefits from the system’s use to address integration needs. More design make intelligent decisions and must present outweigh it. The bigger question is, who will rationale researchers should understand these rationales in ways that the user finds unob- bear the cost of producing design rationales types of integration and begin to adapt exist- trusive. Possible solutions to the second for a particular artifact, and why? ing technologies to the systems they propose. problem are the Janus critic16 and ADD’s The ideal cost bearer is the person who apprentice15 (described earlier). However, gets enough benefit to compensate for the Among users. Because a design rationale these solutions have only begun to address cost. The interactive acquisition of the ratio- system has many users, it should provide

MAY/JUNE 1997 83 .

some way to share objects or translate them ments, process sheets) used to develop the edge acquisition, reuse, natural language over heterogeneous representations or sys- process step. Examining the insights and understanding, and machine learning. tems. Exporting and importing through a file problems in such an integrated system can Finally, integration is an important issue may work in some cases. Another possible aid the design of a future design rationale that can no longer be overlooked. Researchers solution is the wrapper approach,18 in which system. in the management of design rationale sys- each system builds a layer that handles any tems can look at solutions that work in other heterogeneous input, allowing participants areas, such as wrappers, mediators, OLE, and to maintain their autonomy. Yet another pos- APIs. sible solution is to communicate via a black- By addressing these neglected areas, board by publishing a portion of each par- design rationale research can enhance its con- ticipant’s private scratchpad. Both options tribution to design research and begin to pro- will require developing a common protocol duce more esffective and economical sys- and language or an extension of an API for tems. exchanging design rationale information. Among multimedia objects. Even when A MONG THE SEVEN ISSUES I there is only one user, a design rationale sys- have identified, only a few have been explored tem must be able to integrate various multi- in sufficient depth. Issues such as how to rep- References media artifacts that must be accessed: design resent design rationales will not pose many 1. J. Lee, “AAAI ‘92 Workshop on Design notebooks, sketchbooks, phone conversa- new problems for developers of future design Rationale Capture and Use,” AI Magazine, tions, videos, CAD drawings, and e-mail. rationale systems. However, a few critical Vol. 14, No. 2, 1993, pp. 24–26. Phidias16 addresses this problem by provid- issues have been neglected. For example, I ing uniform access to artifacts through hyper- believe providing for cost-effective use, 2. J. Conklin and K. Burgess-Yakamovic, “A Process-Oriented Approach to Design Ratio- text typed links, which the user can define. domain-knowledge generation, and integra- nale,” in Design Rationale Concepts, Tech- Phidias stores and manages these heteroge- tion give rise to many open research questions. niques, and Use, T. Moran and J. Carroll, eds., neous objects in a single hypermedia data- Designing a cost-effective system is one Lawrence Erlbaum Associates, Mahwah, base, the Hyper-Object Substrate. of the most urgent issues design rationale N.J., 1995, pp. 393–428. researchers face. Without a handle on this 3. F. Pena-Mora, D. Sriram, and R. Logche, With design modules. A design rationale problem, the system, even with many sophis- “Design Rationale for Computer-Supported system must integrate well with other design ticated features, may not be used or, worse, Conflict Mitigation,” J. Computing in Civil components, such as CAD module databases may be counterproductive.20 Neither do I Eng., Vol. 9, No. 1, 1995, pp. 57−72; URL for and simulation packages. Because these believe that management is beyond the con- Shared-DRIM: http://ganesh.mit.edu/feniosky/ shared_ pub.html. components are often implemented on dif- cern of research. The eventual goal of all ferent platforms, integration also means research is to pave the way for practical sys- 4. S. Yamamoto and S. Isoda, “SOFTDA—A achieving interoperability across heteroge- tems. Of what practical value can engineer- Reuse-Oriented Software Design System,” neous platforms. Integration with other mod- ing be if it is not cost-effective? The chal- Proc. Compsac, IEEE Computer Society Press, − ules requires not only that these objects be lenge is for researchers to build in an Los Alamitos, Calif., 1986, pp. 284 290. linked or presented to the user but also that incentive structure that would obviate the 5. J. Lee and K.-Y. Lai, “What’s in Design other modules be able to understand and need for a separate management structure. Rationale?” J. Human-Computer Interaction, manipulate them—at least enough for, say, One approach is to provide a game-like inter- Vol. 6, No. 3, 1991, pp. 251−280. the critic module to use design rationale face for acquiring design rationales. Similar 6. M. Maher and A. Garza, “Case-Based Rea- objects and decide whether or not to inter- problems have been studied in other fields soning in Design,” IEEE Expert, Vol. 12, No. rupt the user. such as computer-aided instruction and 2, Mar./Apr. 1997, pp. 34–41. Shared-DRIM3 is one system that is well machine learning. Future research in design integrated with many other design modules, rationale systems would benefit from these 7. R. Neches, W. Swartout, and J. Moore, “En- including Object Store, the Cosmos rule sys- studies. hanced Maintenance and Explanation of Expert Systems through Explicit Models of tem, the Coplan constraint manager, the Dot- Another urgent need is for methods to pro- Their Development,” IEEE Trans. Software strean communication manager, the Gnomes duce formal design rationales at less cost. Eng., Nov. 1986, pp. 1337−1351. geometric module, the Shared abstraction Incremental formalization is promising, but and integrity manager, and the Congen alter- existing proposals are only a beginning. Key- 8. F. Shipman and R. McCall, “Integrating Dif- 19 ferent Perspectives on Design Rationale: Sup- native generator. PTTT provides an exam- word-based parsing can go only so far, and a porting the Emergence of Design Rationale ple of integration with standard operating robust technology for understanding natural from Design Communication,” Tech. Report procedures, a compound document editor, language is not yet here. A restricted form of 96-001, Center for the Study of Digital mail, a code management system, and a natural language with a menu-based inter- Libraries, Texas A&M Univ., College Station, photo manager. When PTTT identifies a face might be a compromise worth explor- Texas, 1996. process problem, for example, it can display ing. Again, researchers would do well to 9. M. Klein, “Capturing Design Rationale in a standard operating procedure, which can examine the many relevant techniques and Concurrent Engineering Teams,” Computer, then point to the stored information (experi- methods that have been explored in knowl- Vol. 26, No. 9, Jan. 1993, pp. 39−47.

84 IEEE EXPERT .

10. B. Chandrasekaran, A. Goel, and Y. Iwasaki, “Functional Rep- GET CONNECTED resentation as Design Rationale,” Computer, Vol. 26, No. 9, Jan. 1993, pp. 48−56. with a new publication from IEEE Computer Society 11. C. Potts and G. Bruns, “Recording the Reasons for Design Decisions,” Proc. Int’l Conf. Software Eng., IEEE CS Press, IEEE Internet Computing 1988, pp. 418−427. is a bimonthly magazine focused 12. J. Lee, “Incrementality in Rationale Management,” Proc. Requirements Eng. Symp., IEEE CS Press, 1992, p. 283. on Internet-based applications

13. G. Fischer and K. Nakakoji, “Making Design Objects Rele- and supporting technologies. vant to the Task at Hand,” Proc. AAAI ‘91, AAAI Press/MIT Press, Cambridge, Mass., 1991, pp. 67−73. IC is designed to help computer

14. I. Baxter, “Design Maintenance Systems,” Comm. ACM, Vol. scientists and engineers use the − 35, No. 4, Apr. 1992, pp. 73 89. ever-expanding technologies and 15. A. Garicia and H. Howard, “Acquiring Design Knowledge resources of the Internet. through Design Decision Justification,” Artificial Intelligence in Eng. and Manufacturing, Vol. 6, No. 1, pp. 91−109.

16. G. Fischer et al., “Making Argumentation Serve Design,” in Features Design Rationale Concepts, Techniques, and Use, T. Moran ❖ Peer-reviewed articles report the latest developments in and J. Carroll, eds., Lawrence Erlbaum Associates, 1995, pp. Internet-based applications and enabling technologies. 267−294. ❖ Essays, interviews, and roundtable discussions address 17. J. Grudin, “Groupware and Social Dynamics: Eight Challenges the Internet’s impact on engineering practice and society. for Developers,” Comm. ACM, Vol. 37, No. 1, Jan. 1994, pp. ❖ Columnists provide tutorials and expert commentary on 92−105 a range of topics. 18. M. Genesereth, “An Agent-Based Approach to Software Inter- operation,” Tech. Report Logic-91-6, Stanford Univ. Logic To subscribe at half yearly rates Group, Stanford, Calif., 1991. ❖ Send check, money order, or credit card number to 19. D. Brown and R. Bansal, “Using Design History Systems for IEEE Computer Society, 10662 Los Vaqueros Circle, Technology Transfer,” in Computer Aided Cooperative Prod- PO Box 3014, Los Alamitos, CA 90720-1314. uct Development, D. Sriram, R. Logcher, and S. Fukuda, eds., ❖ Lecture Notes Series, No. 492, Springer-Verlag, New York, $14 for members of the IEEE Computer or Communi- 1991, pp. 544−559. cations Societies (membership no: ______) ❖ $17 for members of other IEEE societies (include mem- 20. S. Shum and N. Hammond, “Argumentation-Based Design Rationale: What Use at What Cost?” J. Human-Computer Stud- bership number: ______) ies, Vol. 40, 1994, pp. 603−652. ______Name ______Acknowledgments Company Name ______I thank all the workshop participants and organizers who con- Address tributed to the valuable discussions on which this article is partly ______based. I also thank the four anonymous IEEE Expert reviewers for City State Zip Code their valuable and detailed comments. Finally, I thank Frank Halasz, ______who got me interested in the topic of design rationales while I Country worked with his group at the Xerox Palo Alto Research Center.

IC Online is a companion webzine that supports Jintae Lee is an assistant professor of decision sciences at the Uni- discussion threads on magazine content versity of Hawaii, where he is leading the Process Interchange For- mat project to define a common language for process descriptions. and links to other useful sites, as well as He is also an active member of the MIT Process Handbook project to create an intelligent repository of process descriptions for reuse an online archive of back issues. in process modeling and analysis. His research interests are understanding and improving knowledge sharing processes. Lee received http://computer.org/internet/ a BA in mathematics from the University of Chicago, an MA in psy- chology from Harvard University, and a PhD in electrical engineering and computer science from the Massachusetts Institute of Technology in 1991. He is a member of the IEEE, the AAAI, and the ACM. His address is Dept. of Decision Sciences, Univ. of Hawaii, 2404 Maile Way, Honolulu, HI 96825; [email protected].

THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, INC. MAY/JUNE 1997 ¨