The most commonly mentioned reason for using DR in SE is to support future changes in software, a problem that is perhaps more pressing in this field than in any other design or engineering field. This does not necessarily require …
DR can be used to promote both collaborative and participatory design. Rittel argued that participation by users in design is often inhibited because they do not understand what rationale designers are using, what questions they are addressing, what alternative answers …
DR can help to coordinate many aspects of a design team’s work. Different members of a team can use a common repository of DR to understand what others in the team are doing and what the consequences are for their …
Gruber and Russell [23] argue that argumentative schemas do not include all the rationale that designers use, because all of them are prescriptive about what information is relevant. No collection of DR, they claim, could answer all of the questions …
Problem-Based Evaluation
Lewis et al. [37] present a novel approach for evaluating alternative features of an artifact. They describe their own software design process as using a suite of problems for conceptual evaluation of different proposals for a computational environment …
The most commonly used way of treating DR is as a type of argumentation that is structured according to a given schema. There are many ways in which DR argumentation might be structured, but there have historically been two major …
There are already many different approaches to DR, and more are coming into existence on a regular basis. This multiplicity of approaches shows that the DR field is healthy, but it also creates the need to make sense of this …
Systematic documentation of rationale for practical decisions began more than 35 years ago with work on rationale for design [30], in particular, design of buildings and cities. In the 1980s, interest in rationale spread to other fields involved with design, …
