Capturing design assumptions for rational coordination, integration and negotiation in the design process

Abstract Assumptions form the base on which the design is founded. Design starts by taking a concept based on assumptions of what may be wanted and how those needs may be satisfied. Later, this concept is decomposed into sub-problems that, in turn, may be decomposed in smaller sub-problems. This decomposition is based on a set of assumptions of how the sub-problems interact and how they may be solved. In addition, this decomposition requires the participation of multiple actors from multiple disciplines who must coordinate and communicate their assumptions on how to solve the sub-problems. Capturing the assumptions as they are presented, and making them available to the remaining phases of the design process would enhance coordination, integration and negotiation during the process. However, there are some problems with the capture and use of design assumptions. In current practice, certain kinds of vital information—usually unstructured and informal, often having to do with why certain actions are taken (design rationale and intent)—are often lost in large projects. Usually the information that is related to the relationship between the parts of an artifact and the context in which they are designed to work is lost. To solve these problems of capturing design assumptions, this paper recommends the use of the Design-Rationale-Intent Model (DRIM), a model that attaches the design rationale behind an artifact to the hierarchical decomposition of that artifact.

[1]  Alberto L. Sangiovanni-Vincentelli,et al.  Design management based on design traces , 1991, DAC '90.

[2]  P. Borrel,et al.  Interactive design with sequences of parameterized transformations , 1989 .

[3]  Robert D. Logcher,et al.  DICE: An object-oriented programming environment for cooperative engineering design , 1992 .

[4]  K. C. Burgess Yakemovic,et al.  Report on a development project use of an issue-based information system , 1990, CSCW '90.

[5]  David Serrano,et al.  Constraint Management in Conceptual Design , 1989 .

[6]  Jintae Lee,et al.  What's in design rationale? , 1991 .

[7]  S. Toulmin The uses of argument , 1960 .

[8]  Colin Potts,et al.  Recording the reasons for design decisions , 1988, Proceedings. [1989] 11th International Conference on Software Engineering.

[9]  David G. Lowe Co-Operative Structuring of Information: The Representation of Reasoning and Debate , 1985, Int. J. Man Mach. Stud..

[10]  Jack Mostow,et al.  Toward Better Models of the Design Process , 1985, AI Mag..

[11]  James H. Garrett,et al.  Representing and reasoning with design intent , 1991 .

[12]  Thomas P. Moran,et al.  Design rationale: the argument behind the artifact , 1989, CHI '89.

[13]  Michael L. Begeman,et al.  gIBIS: a hypertext tool for exploratory policy discussion , 1988, CSCW '88.

[14]  Robert D. Logcher,et al.  Computer-Aided Cooperative Product Development , 1989, Lecture Notes in Computer Science.

[15]  John M. Carroll,et al.  Artifact as theory-nexus: hermeneutics meets theory-based design , 1989, CHI '89.

[16]  H. Craig Howard,et al.  Acquiring design knowledge through design decision justification , 1992, Artificial Intelligence for Engineering Design, Analysis and Manufacturing.

[17]  Raymond McCall,et al.  Design environments for constructive and argumentative design , 1989, CHI '89.