M. Glinz and P. Heymans (Eds.): REFSQ 2009, LNCS 5512, pp. 59–73, 2009.
© Springer-Verlag Berlin Heidelberg 2009
Requirements Tracing to Support Change in
Dynamically Adaptive Systems
Kristopher Welsh and Pete Sawyer
Lancaster University, Computing Dept., Infolab21 LA1 4WA Lancaster, UK
{k.welsh,p.sawyer}@lancs.ac.uk
Abstract. [Context and motivation] All systems are susceptible to the need for
change, with the desire to operate in changeable environments driving the need
for software adaptation. A Dynamically Adaptive System (DAS) adjusts its be-
haviour autonomously at runtime in order to accommodate changes in its operat-
ing environment, which are anticipated in the system's requirements specification.
[Question/Problem] In this paper, we argue that Dynamic Adaptive Systems' re-
quirements specifications are more susceptible to change than those of traditional
static systems. We propose an extension to i* strategic rationale models to aid in
changing a DAS. [Principal Ideas/Results] By selecting some of the types of
tracing proposed for the most complex systems and supporting them for DAS
modelling, it becomes possible to handle change to a DAS' requirements effi-
ciently, whilst still allowing artefacts to be stored in a Requirements Management
tool to mitigate additional complexity. [Contribution] The paper identifies differ-
ent classes of change that a DAS' requirements may be subjected to, and illus-
trates with a case study how additional tracing information can support the
making of each class of change.
Keywords: Adaptive Systems, Requirements Evolution, Traceability.
1 Introduction
Changes can be required of a system at any stage during its design, implementation or
useful life. In traditional static systems, these adaptations (e.g. changed requirements),
are made offline by the system developers as maintenance. Recently a new class of
system has begun to emerge, capable of adapting to changes in its environment
autonomously at run-time. Such Self-Adaptive or Dynamically Adaptive Systems
(DASs) are designed for volatile environments where the system requirements and/or
their priorities may change along with the environment even while the system is run-
ning. The nature of the problem domains for which DASs are conceived are such that
their environments may be only partially understood at design time. Similarly and
particularly for embedded DASs, the potential for new and exploitable technologies to
emerge during the course of the system’s life is high because, with the current state-
of-the-art, a DAS often represents a novel application of emergent technologies. The
DAS itself may exhibit emergent behaviour as it re-configures itself dynamically, in
ways and under circumstances that may have been hard to anticipate at design-time.

60 K. Welsh and P. Sawyer
Thus, far from their runtime adaptive capability making them immune to the need for
offline adaptation, DASs are particularly susceptible to it.
It has long been recognized [1] that requirements management (RM) is needed to
help deal with anticipated change by recording (among other items of information) as
traces the relationships between requirements and the down-stream artifacts of the
development process. This allows questions about how requirements came to be and
how decisions were reached to be answered later in the development process, or in-
deed after deployment. Given the identified need for evolvability and the variety of
factors that may mandate it, the importance of traceability information in a DAS is,
we claim, at least as high or even higher than in a comparable static system.
In this paper we identify requirements for traceability of DASs and, building on
our earlier work on using goal models to discover DAS requirements [2], [3] show
how i* [12] models can be augmented to record this information, for later integration
in a Requirements Management tool.
The rest of this paper is organised as follows: Section 2 looks at related work in the
area of DASs. Section 3 identifies the types of change that the specification of a DAS
may need to accommodate, section 4 examines the types of traceability required to
support these changes. Section 5 proposes a lightweight, i* based method of capturing
these types of traceability information for the purposes of modelling the proposed
DAS' adaptive behaviour. Section 6 presents a case study demonstrating the use of
Section 5's method to revisit decisions in light of different types of change, whilst
Section 7 concludes the paper.
2 Related Work
The requirements engineering (RE) community has recently started to investigate
higher-level runtime representations that would support self-adaptation. Although the
challenges posed by DASs to RE were first identified over ten years ago – principally,
in run-time monitoring of requirements conformance [4] [5] [6] [7] – there are few
current approaches for reasoning at runtime about system requirements.
There is a strong case that any such approach should be goal-based and a number
of authors [8], [9], [10], [3] report on the use of goals for modelling requirements for
DASs. This work commonly recognises that the aim of the system should be to satis-
fice its overall goals even as the environment in which it operates changes. Here, ad-
aptation is seen as the means to maintain goal satisficement, while goal modelling
notations such as KAOS [11] and i* [12] support reasoning about both functional and
non-functional (soft-) goals. We have previously argued [2] that context-dependent
variation in the acceptable trade-offs between non-functional requirements is a key
indicator of problems that require dynamically adaptive solutions.
Goldsby et. al. [3] use i* as part of the LoREM process which partially implements
the four levels of RE for self-adaptive systems proposed by Berry et al. [13]. The lat-
ter work is interesting because it partitions the environment into discrete domains,
each of which represent a state of the environment with distinct requirements. The
system's adapted configuration for each domain is termed a target system. LoREM
has validated this approach on the requirements for a self-adaptive flood warning sys-
tem implemented in the GridKit adaptive middleware system [14] which we use in