Rationale research in software development is a challenging area because although there is no shortage of advocates for its value, there is also no shortage of reasons for why rationale is unlikely to be captured in practice. Despite more than 30 years of research there still remains much uncertainty: how useful are the potential benefits and how insurmountable are the barriers? Will the value of the rationale (design and otherwise) justify the cost of collecting it? Although there have been numerous rationale research projects, many, if not most, received little or no empirical evaluation. There also have not been many studies examining what the needs are of the practitioners who would be supported by the rationale. This article discusses the “doom and gloom” predictions of rationale's failure, provides a survey of evaluations of rationale systems, and discusses what we hope is a brighter outlook for rationale research in the future. There are development standards and synergistic research areas that may help with rationale research and its acceptance in the software community with which we should be working. This article also presents the results of a pilot survey of software developers who were asked how they would envision using rationale and what they believe the most important barriers are. Although some results were as expected, there were also some surprises. Research on technology transfer indicates that, among other things, to transition successfully from research into practice we need to understand the need that is being met and demonstrate the value of our approach. Until we have determined how our work is needed by the people we are trying to help we will remain researching under uncertainty.

The Designers' Workbench is a system developed by the Advanced Knowledge Technologies Consortium to support designers in large organizations, such as Rolls-Royce, to ensure that the design is consistent with the specification for the particular design as well as with the company's design rule book(s). In the principal application discussed here, the evolving design is described using a jet engine ontology. Design rules are expressed as constraints over the domain ontology. Currently, to capture the constraint information, a domain expert (design engineer) has to work with a knowledge engineer to identify the constraints, and it is then the task of the knowledge engineer to encode these into the Workbench's knowledge base. This is an error-prone and time-consuming task. It is highly desirable to relieve the knowledge engineer of this task, so we have developed a system, ConEditor+, that enables domain experts themselves to capture and maintain these constraints. Further, we hypothesize that to appropriately apply, maintain, and reuse constraints, it is necessary to understand the underlying assumptions and context in which each constraint is applicable. We refer to them as “application conditions,” and these form a part of the rationale associated with the constraint. We propose a methodology to capture the application conditions associated with a constraint and demonstrate that an explicit representation (machine interpretable format) of application conditions (rationales) together with the corresponding constraints and the domain ontology can be used by a machine to support maintenance of constraints. Support for the maintenance of constraints includes detecting inconsistencies, subsumption, redundancy, fusion between constraints, and suggesting appropriate refinements. The proposed methodology provides immediate benefits to the designers, and hence, should encourage them to input the application conditions (rationales).

Documented engineering design rationale has the potential to become a key source of information about past designs. Ease of comprehension of design rationale might play a crucial role in ensuring that the full potential of documented information is realized and that the effort and time necessary to capture design rationale pay off. This research proposes an empirical methodology for evaluating how structuring design rationale and supplying it with visual nontextual cues influences reading and interpretation. The study compares reading and interpretation of technical documentation presented in different formats to engineering graduate trainees in the aerospace industry.

Design rationale should be regarded both as a tool for the practice of design, and as a method to enable the science of design. Design rationale answers questions about why a given design takes the form that it does. Answers to these why questions represent a significant portion of the knowledge generated from design research. This knowledge, along with that from empirical studies of designs in use, contributes to what Simon called the sciences of the artificial. Most research on the nature and use of design rationale has been analytic or theoretical. In this article, we describe an empirical study of the roles that design rationale can play in the conduct of design research. We report results from an interview study with 16 design researchers investigating how they construe and carry out design as research. The results include an integrated framework of the affordances design rationale can contribute to design research. The framework and supporting qualitative data provide insight into how design rationale might be more effectively leveraged as a first-class methodology for research into the creation and use of artifacts.

Identification of latent or unarticulated customer and other stakeholder needs has been a significant barrier to improving the efficiency and effectiveness of the front-end phase of new product development processes. In-depth determination of stakeholder needs entails analysis of their intentions; the overall aim of the work reported in this article is to establish a framework of intentional analysis, and its associated methods and techniques for improving traceability of design practice during the early phases of the design process. The specific aim of this article is to present a conceptual framework for design rationale systems. The framework built upon the cross-fertilization of approaches and methods drawn from systems engineering and philosophy, focussing on the notions of antecedence and consequence. It was developed in the course of tackling design problems originating in industrial contexts. The methods developed were thus evaluated, updated, and refined in real applications. Two application cases are described that have been drawn from the aerospace and power sectors, respectively. The applications showed that the framework's central antecedent/consequent scheme provides a cell from which to develop either a history of actual successive changes, or a tree of alternative possible projected designs.

This paper presents an approach to capture and exchange the arguments and rationale architects develop while designing. The approach was inspired by experiments conducted in the context of a larger research project on architectural redesign. Protocol analysis revealed that architects tend to use three mechanisms in constructing arguments for design solutions: chunks, lines of thought, and strategies. These three mechanisms were used to record “real-world” design processes in architectural practice, the results of which were evaluated by assessors with different backgrounds. The paper closes by comparing the approach to related work, and outlining challenges for the future.

This article presents Kuaba, a new design rationale representation approach that enables employing design rationale to support reuse of model-based designs, particularly, software design. It is shown that this can be achieved through the adoption of an appropriate vocabulary that allows design rationale representations to be computationally processed. The architecture and implementation of an integrated design environment to support recording design rationale using Kuaba is also shown. The Kuaba approach integrates the design rationale representation model with the formal semantics provided by the metamodel of the design method or modeling language used for describing the artifact being designed. This integration makes the design rationale representations more specific according to the design methods and enables a type of software design reuse at the highest abstraction level, where rationales can be integrated and reemployed in designing a new artifact.