Communicating and recording the decisions made during the course of producing a design is useful and important for a number of different people. Traditionally, system documentation is the main method of communicating about a software system between the relevant parties: developer to customer, analyst to the designer, resigning design team member to new member, and so on. Unfortunately, it is common for documentation to be inadequate, incomplete and poorly organized. The ack of such a record can cause even more time to be wasted and can be frustrating.
Many people involved with software need to know the reasoning or rationale behind the design of that software. It is clearly important for the maintainers of a system to have access to a coherent description of its structure and purpose, but there are others who also benefit from understanding as much as possible about the product and why it is the way it is; for example, software maintainers, trainers, and marketing personnel. If new staff join the development team they need to understand why certain decisions have been made. Design team members themselves will benefit from an explicit representation of the design's rationale while it is being developed. A further possible advantage of having a design and its decisions recorded is that this could facilitate reuse.
One of the main questions associated with design rationale is how to document it. One could imagine producing a table of some sort, with maybe data, alternatives considered, reasons for choosing one solution over the others, and so on. This would be one step better than narrative text, which in turn is one step better than a transcript of the meeting or meetings at which the decisions were made. However, none of these ways would make the information particularly accessible. Imagine, for example, trying to identify the reasons for a decision made at the beginning of the project, and it could take a long time to find the specific point you need. We cannot present all approaches that have been developed for documenting design rationale, but we describe three of the more significant: IBIS, Design Space Analysis, and Claims Analysis.
Issue-Based Information Systems is a technique which was devised in order to capture design decision as the design progressed; that is, it was to be a by-product of the design process itself. The central activity of IBIS is deliberation, that, considering the pros and cons of alternative answers to questions. The questions are called issues, the answers are called positions and the pros and cons are the arguments for or against the position. An IBIS discussion begins with a root issue, which is the main question to be addressed; for instance: what should this system do? Positions are put forward to answer this question, together with arguments for and against them. Secondary issues can be generated and deliberated in the same way, and these may lead to tertiary issues, and so on until a solution is reached. The issue deliberations are chartered by producing a graphical diagram called an issue map, which illustrates the issues and their relationships. An example map is given below:
An example IBIS issue map - Image from Lucidchart
Design Space Analysis
Design can be viewed as an exploration of a space of alternatives. That is, there are a host of alternative designs that fulfill the system,s specification, and the process of design involves identifying the one, or ones, that satisfy the system's constraints and goals as closely as possible. In design space analysis, the designer is actively encouraged to explore alternative designs, so the final result is not just a detailed description of the "whys" and "wherefores" of a design, but also better quality designs since the designer will have explored many more alternatives. A notation called QOC (Questions, Options, and Criteria) can be used for this purpose. The below image is an example of this notation.
Components of a design space using QOC notation
Notice that options can be thought of as answers to questions, just as the IBIS notation considered questions and answers. However, the major difference between questions, options and criteria, and issues, positions, and arguments is that the issues and positions in IBIS are general-purpose, whereas the questions and options in design space analysis are specifically for design. The questions addressed highlight important dimensions in the design space; they represent issues that must be considered. Criteria are positive goals, which are used to distinguish between the various options; they argue for or against the various alternatives. Unbroken lines indicate a positive relationship between the criteria and the option whereas dotted lines indicate a relatively negative relationship, that is, that the option is not supported by the criterion.
An alternative way to identify the rationale of a software design of an existing system is to examine the psychological claims that the designer is making or has made with regard to the use of a system, the user of the system, the environment of use, and so on. The range of issues that may be addressed by a claim is very broad. A claim relates some aspect of a system's design with an important consequence for the user. In this sense, it represents a rationale for the design, in that it explains why a design decision was made, based on the implications of that decision for the system's use. The claim that this design embodies is that understanding real-world tasks is facilitated by filtering inappropriate goals, that is, inappropriate functions. It is possible to identify claims at various levels of abstraction. Claims analysis is done by creating scenarios of the system's use and analyzing them for claims. Core tasks that the system is intended to support and key errors that the system must be able to handle should be included. Although the primary purpose is to identify trade-offs, that is situations in which the design decision was perhaps not the best for supporting the users. However, it is useful to remember that all designs have to accommodate compromises and that trade-offs can be viewed as the usability gambles taken by designers.