A Rationale-based Model for Architecture Design Reasoning

9.1. Background
9.1 Background
In this section, we examine the needs for a better way to recover design rationale to
support design reasoning. We analyse existing design-rationale methods and requirement
traceability methods to identify the challenges. From the perspective of a practising
architect, we identify a number of uses cases for traceable design rationale.
9.1.1 Issues with design rationale
Researchers in the area of design rationale have argued that there is a need to improve the
process to capture, represent and reuse design rationale. Perry and Wolf [119] suggested
that as architecture design evolves, the system is increasingly brittle due to two problems:
architectural erosion and architectural drift. Both problems may lead to architecture design
problems over time if the underlying rationale is not available. Bosch suggested that
as architecture design decisions are crossing-cutting and inter-twined, the design is complex
and prone to erroneous interpretations without a first-class representation of design
rationale [11]. As such, a design could be violated and the cost of architectural design
change could be very high and even prohibitive. As discussed in earlier chapters, design
rationale is important to support knowledge retention and facilitate the understanding of
the architecture design. The form of design rationale representation is also important for
it has to support structured and automated tracing.
9.1.2 Requirements and design traceability
Requirements traceability is the ability to describe and follow the life-cycle from requirements
to their implementation, in both a forward and backward direction. For example,
given a requirement, an architect might wish to find the design objects that realise the
requirement in forward tracing. Gotel and Finklestein [51] distinguish two types of traceability:
pre-requirements specification (Pre-RS traceability) and post-requirements specification
(Post-RS traceability). They argue that wider range of informational requirements
are necessary to address the needs of the stakeholders. This is an argument for representing
contextual information to explain requirements and design. A survey of a number of
systems by Ramesh and Jarke [129] indicates that requirements, design and implementation
ought to be traceable. It is noted by Han [58] that traceability “provides critical
support for system development and evolution”. The IEEE standards recommend that
requirements should be allocated, or traced, to software and hardware items [67, 68].
In the development life-cycle, architects and designers typically have available to them
152