A Rationale-based Model for Architecture Design Reasoning

3.2. Why do we need design rationale?
Supporting the Maintenance Activities
• Retaining Knowledge - in the design process, assumptions are made, constraints are
considered and priority is assigned. These elements shape the design decisions. Often
the only documentation available to the maintainers are the design specifications.
If the designers who maintain and enhance a system are not the same person who
created the system, which is often the case, the maintainer would have to secondguess
these intangible rationales. Failure to retain such knowledge might cause
violations and inconsistencies in a system [33]. It was found in a survey that most
designers cannot remember the reasons of their design [158]. If the maintainers are
not the original designer, then design rationale as a source of knowledge would be
very useful [157]. Such retained knowledge could save costs because engineer’s time
to recover lost rationale is reduced [25].
• Capturing Design Alternatives - as Parnas and Clements pointed out that the ideal
design document which consists of all the details is impractical [114]. Therefore,
recording key design rationale information such as design alternatives and why they
have been rejected can answer many questions about the design.
• Understanding Decision Dependency - design decisions sometimes are inter-twined
and cut across a number of issues. Changing a decision may trigger a series of side
effects to the other parts of the system through the ripple effect [59]. Designers could
potentially omit necessary changes caused by the inter-dependent decisions in the
design space. Some design rationale methods could address this issue by providing
linkages between dependent decisions to facilitate traceability [97, 162].
• Improving Design Understanding - in one of the experiments, Brathall et al. showed
that a group of designers equipped with the design rationale can work faster and
identify more changes that are required in a system maintenance exercise than a
control group without the design rationale [12]. Burge showed that using the design
rationale, those designers with moderate and some experience in Java perform their
work better than the designers without the design rationale [14].
• Predicting Change Impact - design rationale could be used to assist the maintainer
to predict which part of the system is subject to change. This kind of predictive
and diagnostic capabilities provide quantitative analysis to assist decision makers on
predicting the change impact in a system [162].
• Providing Traceability - when the design rationale is associated with the design artefacts,
maintainers would be able to trace how design artefacts satisfy requirements
in a system with some reasoning support [129].
28