Revisiting the Relationship between Software Architecture and Requirements: the
case of Dynamically Adaptive Systems
Nelly Bencomo, Paul Grace, Pete Sawyer
Computing department, InfoLab21, Lancaster University, LA1 4WA, United Kingdom
nelly@acm.org, gracep@comp.lancs.ac.uk, sawyer@comp.lancs.ac.uk
Abstract
This paper revisits the relationship between software
architecture and requirements focusing on the case of self-
adaptive systems. The authors present their view of the
state-of-the-art, including their own work, on both areas
and their contribution towards the development of self-
adaptive systems. The authors support the claim that there is
no fundamental distinction between architectural decisions
and architecturally signi cant requirements and discuss h ow
these claims are speci cally appropriate for the case of sel f-
adaptive systems. A discussion of the approach described
and challenges for the case of adaptive systems are also
presented.
Keywords: architecture, requirements, dynamically adaptive
systems.
1. Introduction
For a long time the relationship between software ar-
chitecture and requirements has been subject to deliber-
ation. Several venues have hosted the exchange of ideas
on the topic: e.g. the panel on the topic of Role of
Software Architecture in Requirements Engineering at the
rst IEEE International Conference on Requirements En-
gineering (ICRE’94) and the workshop series Software
Requirements to Architecture (STRAW 2001 and 2003).
The relationship between Requirements and Architecture
was also acknowledged by Nuseibeh & Easterbrook in
[15]. These research efforts have produced different results
with different visions of the relationship between require-
ments and architecture. For example, Gr¤unbacher et al.
[10] presented an approach to provide a systematic way
of reconciling requirements and architectures. Jackson et
al. [11] uses problem frames to allow architectural struc-
tures to be considered as part of the problem domain. In
contrast to efforts that emphasize the gap that needs to be
bridged between requirements and architecture, Nuseibeh
[14] emphasizes the equal status we give to requirements
and architectures . He acknowledges a process that allows
both requirements engineers and software architects to work
concurrently and iteratively to specify the artifacts to be
produced.
More recently, de Boer and van Vliet [7] argue that there
is no fundamental distinction between architectural decisions
and architecturally signi cant requirements. According t o
de Boer and van Vliet even though, software architectures
and requirements engineering have different perspectives
[s] oftware architecture is not merely the domain of the
architect. Each architecturally signi cant requirements is al-
ready a decision that shapes the architecture [7]. Similarly,
van Lamsweerde [17] claims that when using goal-oriented
requirements engineering (GORE) high-level architectural
judgements are made in that process. We claim in this
paper that the arguments presented in [7] and [17] are
particularly appropriate for the case of self-adaptive systems.
Furthermore, and as in [7], we also agree the need to identify
research areas in which tighter collaboration between the
software architecture and requirements engineering research
communities would lead to advantages and faster progress
for both.
In this paper we present a systematic, incremental ap-
proach to deriving software architectures and their recon-
gurations from system goals. Our approach is grounded
on goal-based models with the intent of guiding software
architects in their design task when developing self-adaptive
systems. Speci cally, our work on goal-based modelling
supports the mapping between system goals and their impact
in the architecture and its recon guration during runtime
adaptations. The approach allows us to articulate different
research challenges in terms of capturing, maintaining and
adapting the requirements of a self-adaptive system and their
impact on the software architecture after the system itself has
been deployed and is operational.
2. State-of-the-art
The need of self-adaptation as a crucial enabling ca-
pability for many applications has stimulated researchers
from both requirements engineering and software archi-
tecture research areas to propose different approaches. In
the context of requirements engineering, Berry et al. [3]
have proposed four levels of analysis that encompasses a
framework of discourse for requirements of self-adaptive
systems. A notable body of work has applied goal-based
modeling notations, such as i* [9], to the discovery and

speci cation of requirements of self-adaptive systems. Go al-
based models have proven to be effective for the speci ca-
tion of the adaptation selections that a self-adaptive system
must perform and the speci cation of monitoring and change
between adaptive behaviours [5, 17]. The ability to reason
about partial goal satisfaction is a particular strength of goal-
based modelling
Architecting self-adaptive systems has also produced a
large body of work. A recent roadmap paper which discusses
the state-of-the-art in software architecture for self-adaptive
systems is given in [13]. This roadmap paper presents among
many others the work of Oreizy et al. that introduced an
architecture-based approach to self-adaptive software and
evolution management; Dashofy, van der Hoek and Taylor
propose the use of architecture-based evolution management
for run-time adaptation using ArchStudio; Garlan et al
have proposed the Rainbow framework that uses software
architectures and a reusable infrastructure to support self-
adaptation of software systems.
There have also been research efforts that combine both
requirements and architectures to study the case of self-
adaptive systems. Partially based on the research initiatives
presented above, Kramer and Magee [13] describe their
vision of self-management at the architectural level, where a
self-managed software architecture automatically con gu res
the interaction of its components to be compatible with
an overall architectural speci cation and to achieve the
speci ed goals of the system. Floch et al. [8] promote
the use of architecture models to support the development
of adaptive applications for mobile applications. In contrast
to traditional event-action rules, Floch et al. propose the
use of goal-based policies expressed as utility functions
leaving to the system the decisions on the actions required to
implement those policies. Partial results of our own research
using requirements and architecture and that are explained
in more detail in Section 3 are shown in [9, 16]. The
approaches of Kramer and Magee, Floch et al., and our own
work carry the notion of the need to achieve the speci cation
of goals in such a way that it is intelligible by the system
itself and not only by humans. This last is an important point
we visit again at the end of the paper when discussing the
challenges.
It is common to nd in the literature the explicit dis-
tinction between requirements and architecture. A decisive
factor used in academia to distinguish both concepts en-
compasses what vs how and problem vs solution .
Industry is more pragmatic and that factor is usually related
with what is determined before and after the contract
is signed by the client. What is relevant to this paper, as
our focus is on self-adaptive systems, is that the criteria
described above encompasses the belief of already xed
or agreed vs what remains to be done [7]. A self-
adaptive system is able to modify its behavior according to
changes in its environment [5]. Requirements engineering
for self-adaptive systems must deal with uncertainty [5, 18]
because the information about future execution environments
is incomplete, and therefore the requirements for the be-
havior of the system may change (at runtime) according
to the changing environment. One of challenges that self-
adaptation poses is that we cannot anticipate requirements
for the whole set of possible conditions and their consequent
impacts on the architecture.
3. Goal-based requirements speci cation for
self-adaptive systems
Our requirements speci cation approach is goal-driven
and characterizes the environment as a nite set of stable
states subject to events that cause transitions between states.
A self-adaptive system can be modeled as a collection of
target systems [20], each of which correspond to, and operate
within, a state of the environment [9]. The concerns mod-
elled correspond to levels of analysis that represent particular
concerns of a self-adaptive system: the behaviour of the set
of target systems, the requirements for how the self-adaptive
system adapts from one target system to the next, and the
requirements for the adaptive infrastructure. We make each
concern the focus of a different model, or group of models,
that we use to visualize and analyze the system require-
ments. Level 1 is analogous to the analysis needed for a
conventional, non-adaptive system. A separate level 1 model
is needed for each stable state of the environment for each
target system. Level 1 models must specify the variables
in the environment to monitor that represent the triggers
for adaptation. Level 2 is concerned with decision making
and has no direct analogue in conventional systems. Level
2 helps the analyst focus on understanding the requirements
for adaptation by de ning adaptation scenarios. The analys t
must identify the values of the monitored environment vari-
ables that prompt transitions between stable states, specify
the target systems that represent the start and end points of
adaptations and specify the form of the adaptation. Level
3 analysis is concerned with identi cation of the adaptive
infrastructure in order to enable self-adaptation. Level 3 is
not relevant for this paper.
We have successfully applied our approach to GridStix
[12], an adaptive ood warning system and is documented
in [9]. We describe only a subset of the the models for the
case study. A fuller description is found in [9, 16]. The rst
task at level 1 was to identify the high-level, global goals
of GridStix: the main goal Predict Flooding, and three goals,
or softgoals that describe required qualities, Fault Tolerance,
Energy Ef ciency and Prediction Accuracy. Next, states of the
river environment were identi ed, each of which could be
treated as a discrete domain for a target system. In GridStix,
these represented a three-fold classi cation of the river s tate:
S1: Normal or quiescent, where depth and ow rate are both
within bounds that indicate no risk of ood; S2: Alert where