A Rationale-based Model for Architecture Design Reasoning

8.1. Background
Based on these assumptions, we seek to improve decision making by structuring the
decision process. Such an approach can provide some discipline to the architecture design
process where it currently relies heavily on individual experience and intuition. Such approach
can also help less experienced architects to systematically make decisions to design
better. Using the AREL model as a basis, we propose the Architecture Rationalisation
Method (ARM) as a process to systematically reason about design decisions during architecture
construction. 1 Section 8.2 describes how ARM works. Section 8.3 describes how
ARM can be applied to various aspects of architecture design and system maintenance.
8.1 Background
The process of architecture design is a systematic decomposition of problems using requirements
as a basis to drive design objects creation. The key focus of the architecture
process is to create a design structure for the system. During this process, requirements
analysis and clarifications may be performed. Although requirements elicitation and analysis
are relevant, they are not the key outcomes of architecture design. There has not been
a commonly agreed scope for architecture design process. Researchers [8, 119, 46, 84] and
industry consortia [21, 31, 164] hold different views of the scope of architecture activities
ranging from enterprise systems strategic planning to detailed software design.
Existing requirements engineering methods mainly focus on the elicitation, modelling
and refinement of business goals. In particular, it articulates high-level business goals
to become systems requirements. For example, graphical notations for requirements decomposition
using AND / OR reduction links have been proposed [28, 61]. Mylopoulos
et al. [104] present a framework for representing non-functional requirements and proposed
decomposition methods to satisfy non-functional goals. Dijkman et al. [30] use a
separation-of-concerns or multiple-viewpoint approach to relate the enterprise viewpoint
(i.e. requirements) to the computational viewpoint (i.e. design). These methods provide
different ways to transform requirements into design. The level of transformation required
to reach the necessary design details is often not defined clearly.
In Figure 8.1, we outline a generic high-level system development process to define the
scope for system and software architecture design activities.
• Business requirements elicitation stage - business analysts or designers gather business
goals and produces system requirements. This activity is mainly concerned with
requirements gathering and therefore is outside the scope of architecture design. Its
1 This chapter is based partially on our work published in [159].
134