News

  • January 08th 2010: Version (2.0) of Dream is now available (Support for tracing Requirements within the Design Rationale process).
  • November 29th 2004: Edition bugs fixed.
  • September 10th 2004: Version (1.0) of Dream.
  • August 5th 2004: Dream's website created on.

Introduction

DREAMER is a tool-supported notation for addressing problems of traceability and coverage of both requirements and design options during the development process of interactive systems. It provides support for structuring and recording (in an exhaustive manner) the information produced during design meetings, including:

  • Questions that have been raised,
  • Design options that have been investigated and the ones that have been selected,
  • Criteria that have been used for evaluating the options considered,
  • Requirements for the system and how they are supported by design options,
  • Factors that have been taken into account and how they relate to criteria,
  • Arguments and documents used to explain the design options,
  • Task models corresponding to options,
  • Scenarios extracted from the task models that are used to compute, for each option the value of the criteria

DREAMER extends the former released DREAM-TEAM tool and associated notation in order to explicitely describe the requirements for the system and how they are supported by the different design options.

DREAM (Design Rationale Environment for Argumentation and Modelling) is a tool for editing graphically extended QOC diagrams.

User centred development (Norman and Draper, 1986, Vredenburg et al., 2001) processes advocate the use in the early phases of participatory design activities, end-users evaluations, and brainstorming. Such approaches work in opposition of some software engineering techniques that promote iterative development processes such as in agile processes (Beck, 1999) in order to produce software as quickly and as cheaply as possible.

One way of justifying profitability of development processes promoted in the field of Human-Computer Interaction, is not only to take into account development costs but also to take into account costs of use i.e. costs related to the employment, training and usage errors. Gain, in terms of performance (for instance by providing default values in the various fields of a computer form) or in reducing the impact of errors (by providing undo facilities for instance) can only be evaluated if the actual use of the system is integrated in the computation of the development costs. User centred development processes compensate additional costs by offering additional pay-offs when the system is actually deployed and used. Precise evaluation of costs and pay-offs for usability engineering can be found in (Mayhew and Bias, 1994).

Design rationale approaches (Moran et al., 1996) face the same problems of profitability as user centred development processes. As pay-offs are not immediately identifiable, developers and designers of software products are still reluctant to either try it or use it in a systematic way. Design rationale follows three main goals:

  • Provide means (notations, tools, techniques ?) for systematic exploration of design alternatives throughout the development process;
  • Provide means to support argumentation when design choices are to be made;
  • Provide means to keep track of these design choices in order to be able to justify when choices have been made.

Such approaches increase the production of rational designs i.e. where trust in designers' capabilities can be traced back. One of the main arguments for following a rationale-based design development process is that such processes increase the overall quality of systems. However, when it comes to putting design rationale into practice i.e. within development teams and real projects, more concrete arguments around costs and benefits have to be provided.

We believe that this under exploitation of such a critical aspect of for the design process lies in two main points:

  • There is no integration of current practice in User Centred Design processes and design rationale. For instance, no design rationale notation or tool relates to task modelling, scenarios, dialogue models, usability heuristics ? that are at the core of the discipline;
  • There is no adequate tool to support a demanding activity such as design rationale that is heavily based on information storage and retrieval as well as on reuse. In software engineering, similar activities are supported by case tools that are recognised as critical elements for effective use of notations.