A Rationale-based Model for Architecture Design Reasoning

3.2. Why do we need design rationale?
descriptive categories based on general design rationale schemes can be useful in
analysing activities in design meetings [112].
• Justifying Design Decisions - a rationale may explicate tacit assumptions, clarify
dependencies and constraints, and justify a design decision by reasoning why a choice
is made by selecting from amongst the alternatives [53]. There are many reasoning
perspectives and hence many reasoning methods for justifying the design decisions,
these methods are discussed in the next section.
• Supporting Tradeoffs Analysis - a design decision often involves resolving conflicting
requirements where they cannot be fully satisfied simultaneously. Therefore,
tradeoffs analysis method such as ATAM are used to provide ways to prioritise requirements
and obtain a compromised decision [8].
• Structured Design Process - design rationale provides a design practice which is
structured and accountable compared with the ad-hoc design practice. It provides a
pertinent understanding of the context, the users, the tasks, the technologies and the
situations in the project space [18]. With design reasoning, designer has a specific
focus (so-called turtle-eye’s view) to raise issues about a specific artefact in a design
[122].
• Design Verification & Review - design rationale provides a record of why certain design
decisions have been made. This provides a trail for design validation and review
in which independent assessment of the design can be supported [159]. Reviewers
can also validate the design through inspecting whether design alternatives are considered,
design can be traced to requirements and sufficient reasons are provided in
a design alternative [14].
• Notational Support - the semi-formal notations record the deliberation of design
reasoning. They provide uniform notations to represent key rationale elements such
as design issues (or questions), design alternatives (options or positions) and arguments.
Methods such as gIBIS [26], QOC [97] and DRL [94] each have their own
notational support.
• Communication and Knowledge Transfer - the knowledge about a system design
needs to be shared amongst different interested parties. Information such as the
current state of the design, any unresolved issues and what to do next can be captured
by the design document and the design rationale. Conklin and Burgess-Yakemovic
found that design rationale is most useful in knowledge transfer in an industrial case
at NCR when some designers leave the design team and the knowledge needs to be
transferred to new members of the team [24].
27