Colin Potts

Georgia Tech, School of Interactive Computing

Portrait of the artist with teapots
How to get me
Where to get me
by email potts@cc.gatech.edu
by phone (+1) (404) 894-5551
by foot Tech Square Research Building, Room 339
by mail School of Interactive Computing
Georgia Institute of Technology
Technology Square Research Building, 85 5th Street,
Atlanta, GA, 30332-0760
by fax (+1) (404) 894-0673

Design rationale

Background. Design is an intellectual process in which choices are continually made among alternatives, and there are reasons for choosing one alternative over another. Retrospective design rationale is the recording of decisions and their rationale for future reference (e.g. in regulated industries where business decisions must be justified to regulators or in generic design patterns and guidelines where standard rationales operate in many design settings). Prospective design rationale is the recording of currently open decisions, criteria being considered, informal inputs and suggestions. Its goal is to sustain awareness of loose ends and recent commitments. I have investigated both retrospective and prospective design rationale, and my current interest is mainly in prospective rationale during requirements evolution (e.g. keeping track of what further questions we need to ask a customer representative.)

Ancient History: Design Rationale and 1980s Design Methods. My early work in design rationale, conducted at MCC, was influenced by Horst Rittel's issue-based information systems. The intention was to take issue-based models and technology and marry them to the evolution of system descriptions that occurs during the application of a standard design method. This was before object-oriented analysis, and so we used Liskov and Guttag's abstraction-based method and Jackson's JSD, but the ideas apply to any design method:

  1. Part of a design method involves representing information in the method's standard notation. (Today, most practitioners use UML notations.)
  2. A true method, as opposed to a mere collection of notations, involves guidelines about what to look for in the problem domain and in current representations, what questions to ask, standard criteria for resolving issues, and how to revise the representations created so far (or create new ones).
  3. Some methods involve domain guidelines, not just generic design guidelines.
All these guidelines and questions can be modeled as miniature issue bases that annotate one or mediate between several representations.

The Inquiry Cycle. Taking these ideas further led to the Inquiry Cycle and prototype hypertext engines Tuiqiao and EColabor developed at NTT Research Laboratory in Musashino, Japan. In the Inquiry Cycle, designers collaboratively express designs in documents that they tag with notes of several types. There is a simple grammar that constrains what types of additional notes can be spawned to comment on other notes or relevant attached design objects. This is relatively independent of the design method in question. We used a scenario-based goal-refinement method (see the requirements page for further details). ScenIC is based on the same ideas, but for a more methodical use of scenario analysis during requirements elaboration.

Relevant publications (mostly old!).