May 2007: Design rationale

Introduction

To successfully describe design rationale we must first address and attempt to understand what we mean by design. Despite most people having an idea of what design is, this is not entirely a trivial question. Nevertheless we can first investigate some ideas relating to design and the process of design before considering the rationale of design.

Burge (2002) states that the design process is: "... the set of steps, or activities, that take place in achieving the design goals, or objectives. Models of the design process are used in order to either describe the activities of the design process or prescribe how the designing should be done. Many decisions need to be made while designing. A process model can assist in guiding what decisions should be made when, and if, the model describes the design of a specific artefact, can even provide the knowledge to be used to make the decisions."

... to include not only the reasons behind a design decision but also the justification ...

This effectively describes what a design is and what the objectives are, while outlining the importance of the decisions that are made during the process. Although some may argue this is not a comprehensive definition of design, it is sufficient to give us the reasoning to progress to a further understanding design rationale.

Based on these ideas, we can appreciate the reasons for having some way of recording design decisions so they may be reviewed and reused.

What is design rationale?

A typical dictionary definition of rationale is that it is the: "... underlying principle; a rational account; a theoretical explanation or a solution.". So when associated with the word design we mean the underlying principle behind, a rational account of, or a theoretical explanation of a design.

This basic definition is taken a little further by Lee (1997) who states that: "Design rationales include not only the reasons behind a design decision but also the justification for it, the other alternatives considered, the tradeoffs evaluated, and the argumentation that led to the decision".

This expands the definition such that it states: we require the whole story behind the design, and not just a static snapshot of the final product.

As is often the case with such engineering concepts a number of definitions have been derived by authors over the last 10 to 15 years. Some of these are:

  • Design rationale expresses elements of the reasoning which has been invested behind the design of an artefact, (Shum 1993).
  • Design rationale is the reasoning and argument that leads to the final decision of how the design intent is achieved." "Design intent is the 'expected' effect or behaviour that the designer intended the design object should achieve to fulfil the required function, (Sim 1994).
  • Design rationale means statements of reasoning underlying the design process that explain, derive, and justify design decisions, (Fischer 1995).
  • Design rationale means: "information that explains why an artefact is structured the way that it is and has the behaviour that it has, (Conklin 1995).

In general each of these views tend to agree on the form of design rationale, in that it describes, using various methods, the way a designer has achieved a particular objective. These methods may include any reasoning or decision making which took place and include a description of the available options.

At each option, whenever a decision is made this would also include justification, which can also incorporate any trade-offs that were considered. If we assume that all these definitions are positives that is, why we did something, then what is not specifically stated are the negatives or why we did not do something. It may be argued however, these surface as a part of our justifications and trade-offs.

Design Rationale

To investigate design rationale it is probably most important to regard what a design engineer does and thinks. Research in this field has identified how experienced designers think, and record what they do, prior to arranging this in the form of a design framework that novice designers could adhere to or even learn from.

In theory this helps novice designers to think and act more like experienced designers. The main aspects exhibited by experienced designers are, they: will try to identify many more of the issues than a novice designer, be aware of the reason why something was done, will refer to past designs as starting points for new designs, question if something is worth pursuing, question the validity of data, keep options open, be aware of trade-offs, and be aware of limitations.

A good record of design rationale will therefore have to be able to demonstrate these points and will give a definite direction for the progression of the support and design tools in this area.

What an experienced designer has is experience and if a novice designer can be supplied with the benefit of someone else's experience then this type of approach can address this issue.

Traceability

Many ideas related to design rationale include traceability, since it is in the interest of designers to be able to trace the chain of reasoning why particular choices have been made.

These approaches consider what should be recorded so that traceability can be implemented. Approaches identified include, a method based on rich traceability and one based on requirements management. Each utilise some form of documentation.

The first method also utilises a flowchart of design rationales between a users requirement and what the requirements of the system are. The rationales simply plot the designers' path between these. This also exists in parallel with a large document base which records all relevant information.

Rich traceability

This type of traceability can be described as creating traceability through the use of links between paragraphs of documents, or between paragraphs in a requirements database (Dick 2002). The thinking behind this is described as design justification and the information is used to indicate how systems requirements interact to satisfy high level requirements. For example, the MoD (Ministry of Defence) SMART procurement method attaches statements to requirements which link with other requirements, and denotes the satisfaction chain (see Figure 1). Another means of describing rich traceability is the Goal Structuring Notation (GSN) to construct arguments used in justifying decisions.

Requirements traceability

This is the ability to describe and follow the life of a requirement in both directions, towards its origin or towards its implementation, passing through all the related specifications. Within this three methodologies are commonly followed:

  • traceability links,
  • contribution structures, and
  • rationale capture.

Formalisation of requirements traceability allows guidewords to be associated with specifications in a systems design. Established with the TraceTo phrase they can be include a variety of forms such as: ModifiedBy, ResponsibleOf, RationaleOf, ValidatedBy, VerifiedBy and AssignedTo.

Image of: Fig 1. Statement describing a requirements link

Fig 1. Statement describing a requirements link

Recording design rationale

Various attempts have been made to implement methods of recording various attributes of Design Rationale. A good example is the Klein, Design Rationale Capture System (DRCS), which utilises a language. The language incorporates a vocabulary to describe specific entities within the approach. The vocabulary is a set of pre-defined relational terms which exist between entities within a model. The pre-defined terms being:

  • Synthesis: used to define how a project is controlled and any planning information,
  • Evaluation: describing how a design achieves specifications,
  • Intent: a record of decisions taken in pursuit of achieving specifications,
  • Versions: a record of alternative designs,
  • Argumentation: record of the reasons behind a decision,
  • Responsibility: relating decisions to stakeholders, and
  • Design: linking information and any automated tools.

Requirements management

This can be considered as an extension and application of the tracing and tracking of properties of a system, specifically in the area of specifications management. In their simplest form, nearly all requirements can be treated as properties and this is a good reason why traceability can be used to manage the requirements of a project. Requirements management may be defined as: "the ability to describe and follow the life of a requirement, in both a forward and backward direction (i.e., from its origins, through its development and specification, to its subsequent deployment and use, and through periods of ongoing refinement and iteration in any of these phases)" (Gotel 1997).

The aim of requirements management is to influence the completeness, consistency and traceability of system requirements to provide solutions to:

  • What mission is addressed by a requirement?
  • Where is the requirement implemented?
  • Is the requirement necessary?
  • How do I interpret this requirement?
  • What design decisions affect the implementation of a requirement?
  • Are all requirements allocated?
  • Why is the design implemented this way and what were the other alternatives?
  • Is this design element necessary?
  • Is the implementation compliant with the requirements?
  • Are we done?
  • What is the impact of changing a requirement?

There are currently two approaches to requirements management, these are the Argument based design rationale capture method, and Feature based design rationale capture method.

Argument based design rationale capture (DRC)

This method incorporates the:

  • discussion and deliberations that occur during initial requirements analysis,
  • reasons and rationale behind design changes,
  • system changes over the lifecycle, whether they are changes in requirements, design, or any system artefact, and
  • reasons for and impact of the changes on the system.

Two popular approaches to argument based capture of rationale are, Issue Based Information Systems (IBIS), which deals with issues, positions and arguments for which the emphasis on the recording of the argumentation process for a single design. Ramesh (1992) and Questions, Options and Criteria (QOC). This notation implies that assessments are composed of relationships between options, with criteria and arguments used to conduct debate about the status of the associated entities and their relationships. Shum (1994).

Feature based design rationale capture (FBDRC)

Based on research from the 1990's this was originally within the domain of software engineering. In the interests of re-engineering projects, this simply states that design choices should not be stated in isolation but should be accompanied by the associated rationale, i.e. the reason for the design choice.

Although this approach evolves from the previous argument based DRC above, the major difference is the way knowledge is organised. In a feature based method the capture is based around capturing the distinctive features of a system (hence feature-based) rather than around issues raised during the development process (hence argument-based).

Features are given two definitions, one from Bailin (1990) "any distinctive or unusual aspect of system, or a manifestation of a key engineering decision" and from Kang (1990) "a user visible aspect or characteristic of the domain".

The primary commercial tool that employs this approach is called Software Technology for Adaptable, Reliable Systems (STARS). This utilises the feature based design rationale capture method (Lettes 1996).

Author: John Dalton

Contact: john.dalton@ncl.ac.uk

References

  1. Bailin, S., "KAPTUR: Knowledge Acquisition for Preservation of Tradeoffs and Underlying Rationale," 95-104. Proceedings of the 5th Annual Knowledge-Based Software Assistant Conference. Liverpool, NY, September 24-28, 1990. Rome, NY: Rome Air Development Center, 1990.
  2. Burge, J.; Brown, D. C., "Integrating Design Rationale with a Process Model", Workshop on Design Process Modelling, Artificial Intelligence in Design '02, Cambridge, UK, 2002.
  3. Conklin, J.; Burgess-Yakamovic, K., "A Process-Oriented Approach to Design Rationale", in Design Rationale Concepts, Techniques, and Use, T. Moran and J. Carroll, eds., Lawrence Erlbaum Associates, Mahwah, NJ, pp. 293-428. 1995.
  4. Dick, J., "Rich Traceability", Proceedings of the 1st International Workshop on Traceability in Emerging Forms of Software Engineering, Edinburgh, Scotland, 2002
  5. Fischer, G.; Lemke, A.; McCall, R.; Morch, A., "Making Argumentation Serve Design", in Design Rationale Concepts, Techniques, and Use, T. Moran and J. Carroll, eds., Lawrence Erlbaum Associates, pp. 267-294. 1995.
  6. Gotel, O., "Extended Requirements Traceability: Results of an Industrial Case Study", 3rd IEEE International Symposium on Requirements Engineering (RE 97), January 1997.
  7. Lee, J., "Design Rationale Systems: Understanding the Issues", IEEE Expert, Vol. 12, No. 3, pp. 78-85. 1997.
  8. Lettes, J. A.; Wilson, J., "Army STARS Demonstration Project Experience Report" (STARS-VC-A011/003/02). Manassas, VA: Loral Defense Systems-East, 1996.
  9. Ramesh, B.; Dhar, V., "Supporting Systems Development by Capturing Deliberations During Requirements Engineering", IEEE Transactions on Software Engineering 18, 6 (June 1992): 498-510.
  10. Shum, S., "QOC Design Rationale: A Cognitive Task Analysis and Design Implications" ,Technical report EPC-93-105, Rank Xerox Research Centre Cambridge, 1993.
  11. Sim, S.; Duffy, A., "A New Perspective to Design Intent and Design Rationale", in Artificial Intelligence in Design Workshop Notes for Representing and Using Design Rationale, 15-18 August, pp. 4-12. 1994.