A Rationale-based Model for Architecture Design Reasoning

3.5. How well design rationale methods work?
There is an implicit assumption that such traceability can provide the explanatory power
to help designers understand the system. However, design reasoning is missing and needs
to be reconstructed even though source code or design objects can be traced back to
requirements. Additionally, implicit assumptions and constraints cannot be traced by
such methods. As such, the traceability of design rationale requires further investigation.
A more detailed discussion on design rationale traceability is in Chapter 9.
3.5 How well design rationale methods work?
Although researchers have different ideas of what and how to represent design rationale,
they basically agree on the importance of retaining design rationale, and it is concurred
by practising software architects [157]. With such common view, why then are design
rationale methods not widely adopted by the software industry?
Shipman III and McCall suggested that neither the argumentation nor the communication
perspective of argumentation-based design rationale has been generally successful
in practice [139]. From the argumentation perspective, the issue has been the ineffective
capture of rationale. From the communication perspective, design rationale cannot be
retrieved effectively. Regli et al. [132] have a similar argument that design rationale must
have three qualities: ease of input, effective view and activeness. That means the rationale
capture process must least interfere with the natural progression of design activities.
Gruber and Russell [55] examined a set of empirical studies of people requesting,
communicating and using information associated with design rationale. They found two
basic uses for information explicitly related to decisions. First, decisions serve as loci
for considering alternatives and linking dependent elements. Second, a designer would
evaluate a design or a sub-design to predict the potential impacts on criteria. For design
rationale to be successful, it must be captured as a by-product of the design process using
software tools to make the effort worthwhile.
Buckingham Shum and Hammond [13] examined two claims made by argumentationbased
design rationale approaches: (a) expressing design rationale as argumentation is
useful and (b) designers can use such notations. However, they found no evidence to
support argumentation-based schemas being useful as a record of previous argumentation.
Also, they concluded that argumentation-based schemas assume that designers would be
able to directly express rationale in terms of the argumentation-based structures, which
could not be proven. They also concluded that there was a tendency for some of these
semi-formal methods to move to an informal textual rationale. In another study, Shum
[140] investigated the cognitive dimensions of design rationale. It was found that problem
42