Tracing Requirements for Adaptive Systems using Claims ¤
Kristopher Welsh
School of Comp. & Comm.
Lancaster University, UK
k.welsh@lancaster.ac.uk
Nelly Bencomo
INRIA Paris - Rocquencourt
France
nelly@acm.org
Pete Sawyer
School of Comp. & Comm.
Lancaster University, UK
sawyer@comp.lancs.ac.uk
ABSTRACT
The complexity of environments faced by dynamically adap-
tive systems (DAS) means that the RE process will often be
iterative with analysts revisiting the system speci¯cations
based on new environmental understanding product of ex-
periences with experimental deployments, or even after ¯nal
deployments. An ability to trace backwards to an identi¯ed
environmental assumption, and to trace forwards to ¯nd the
areas of a DAS's speci¯cation that are a®ected by changes
in environmental understanding aids in supporting this nec-
essarily iterative RE process. This paper demonstrates how
claims can be used as markers for areas of uncertainty in
a DAS speci¯cation. The paper demonstrates backward
tracing using claims to identify faulty environmental under-
standing, and forward tracing to allow generation of new
behaviour in the form of policy adaptations and models for
transitioning the running system.
Categories and Subject Descriptors
D.2.1 [Software Engineering]: Requirements/Speci¯cations|
design, software architectures
General Terms
Design, Documentation
Keywords
Claims, requirements, traceability, adaptive systems
1. INTRODUCTION
A Dynamically Adaptive System (DAS) monitors its envi-
ronment at runtime, and adjusts its behaviour according to
monitored changes. Specifying a system that is to operate in
¤Partially supported by Marie-Curie Require-
ments@run.time, EU DiVA, and EU CONNECT projects.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
TEFSE ’11, May 23, 2011, Waikiki, Honolulu, HI, USA
Copyright 2011 ACM 978-1-4503-0589-1/11/05 ...$10.00.
a complex, changeable environment is a challenging task, in-
volving analysis of multiple sets of potentially disparate en-
vironmental conditions. The likelihood of Requirements En-
gineers fully understanding the operating environment and
specifying a DAS that will successfully identify, and have
the °exibility to operate in, all encountered environmental
conditions at the ¯rst attempt is therefore remote.
The ability of reusable adaptive infrastructures such as
GridKit [4] to utilise adaptive behaviour speci¯cations in the
form of adaptation policies means that the task of adjusting
a DAS's adaptive behaviour can be less complex than the
task of reprogramming a system, where such adaptive be-
haviour is hard-coded. However, any RE process that takes
advantage of this °exibility to allow multiple iterations of
proposed adaptive behaviour to be explored (e.g. through
prototyping), needs to allow practitioners to "go back to the
beginning" and re¯ne their domain understanding as knowl-
edge improves, before reconsidering the DAS's adaptive be-
haviour. In other words, some requirements tracing activity
is promoted as essential standard practice when performing
RE for a DAS. We promote the use of recorded assump-
tions made during the requirements modelling process to
provide a means of documenting and tracing the decisions
made during the modelling process. By recording assump-
tions on DAS models, it becomes possible to revisit them in
light of changed information or new understanding as nec-
essary. This revisiting of previously made decisions can be
done by humans later in the RE process, or potentially by
the DAS itself at runtime. In this paper we focus on the
work done by humans (o®-line).
This paper demonstrates that the ability to trace back-
wards to previously captured areas of uncertainty, along
with knowledge of a DAS's proposed adaptive behaviour,
allows for a relatively straightforward identi¯cation of the
con¯gurations (de¯ned in the adaptive behaviour speci¯ca-
tion) a®ected by a change in high-level domain understand-
ing. This paper also demonstrates that the same captured
uncertainty information, along with knowledge of the DAS's
proposed adaptive behaviour, can be used to trace forwards
after a change, allowing a modi¯ed speci¯cation for a DAS's
adaptive behaviour to be generated from modi¯ed models
to achieve requirements model-driven development.
The paper is organised as follows: Section 2 discusses re-
lated work. Section 3 shows how claims can be used to
mark areas of uncertainty for future tracing. Section 4 and
5 demonstrate the backwards forward tracing. Section 6
concludes the paper.

2. RELATED WORK
The study of requirements for DASs shares their initial
roots with the research ¯eld Requirements Monitoring, which
proposed the run-time collection of data to assess a system's
conformance to its requirements [9]. The possibility of tak-
ing action when monitoring data indicates sub-optimal per-
formance is a natural extension of this work. Several authors
[10, 13] report on the use of goals for modelling requirements
for DASs, using i* [13] and KAOS [8]. The strength of goal
modelling when dealing with DAS requirements lies in the
inherent ability to reason about alternate goal attainment
strategies, and partial goal ful¯lment. The RE community
is beginning to consider how systems can utilise these models
at runtime to guide their adaptive behaviour [5].
We have previously proposed the use of claims to enhance
the traceability of DAS requirements models [12], demon-
strating that a relatively simple record of an assumption
made can be used to support requirements evolution. In
this paper, we extend our previous work to demonstrate for-
ward tracing using the same captured assumptions, mod-
elled as claims, to derive modi¯ed adaptive behaviour as
models evolve.
There is some existing work aimed at traceability in model-
driven development. Speci¯cally [2] and [7] address tech-
niques to account for how requirements relate to the various
artefacts created during the design phase. However, none of
these works investigate traceability of requirements to sup-
port changes in requirements speci¯cations. These changes
may arise because of actual changes to the requirements of
the application, or as a result of improved understanding of
the environment in an iterative software development pro-
cess. Uncertainty plays an important role in any software-
based system that needs to evolve and adapt continuously
to meet the goals [11]. In [3], authors discuss traceability
in the presence of uncertainty. Similar to our work, authors
propose to attach supplementary information to traceability
links. This additional information describes the con¯dence
and the rationale for its creation. The authors take into
account the fact that the rationale that supports design de-
cisions is often based on assumptions and beliefs. However,
in contrast to our work, their work focuses on the case of
software product lines and their evolution during software
life cycle. Our work focuses on evolution due to run-time
adaptation. As in [11], this paper, argue that the focus of
managing uncertain information should be on the rationale
used to come to a decision. The decision may be taken either
during design or requirements.
3. CLAIMS IN GOAL-BASED MODELS
In our LoREM (Levels of RE for Modeling), process a
DAS is conceptualised as a set of distinct programs (target
systems) designed to operate in a particular domain. Each
target system and the conditions that trigger the DAS to
adapt from one target system to another are explicitly mod-
elled. An i* Strategic Rationale (SR) model is developed for
each target system, showing the solution strategies employed
by the DAS to achieve its goals and best satisfy its softgoals
for a speci¯c domain. This model is known as a level-one SR
model, and forms the focus of the tracing work described in
this paper. Underpinning LoREM is an assumption that a
DAS must satis¯ce a set of NFRs, but that the balance of
satis¯cement and the consequent trade-o®s di®ers according
to domain. Thus, an understanding of a DAS's adaptive be-
haviour can be reached by analysis of the di®erent trade-o®s
made, and resultant con¯guration decisions, made in a set
of LoREM level-one SR models
Figure 1 shows a level-one SR model for one of the tar-
get systems of an adaptive satellite navigation system to be
installed on suitably mobile telephones. The system pro-
vides verbal navigation cues to a driver en-route to a des-
tination selected in advance. Two types of navigation cues
are supported: turn navigation and lane navigation. Us-
ing turn navigation, the system provides verbal instructions
to take left or right turns, to join or leave a motorway as
necessary. Using lane navigation, the system also gives the
driver advance notice of which lane they need to be in, and
instructions to change lanes should the driver be approach-
ing a junction in the wrong lane. Lane navigation o®ers
greater detail, reducing the chance of the driver having to
make a dramatic, late lane switch to make a turn. However,
these precise navigation instructions require accurate loca-
tion data. Should the calculated location be out even by a
few meters, the system may issue an incorrect instructions,
potentially confusing the driver or even causing an accident.
The system supports two di®erent sources of location data,
with the phone's operating system switching between the
two: a GPS receiver or cell-tower triangulation. The loca-
tion supplied by a GPS receiver is relatively accurate, but
requires line-of-sight to three or more GPS satellites. In
built-up or hilly areas this requirement can be di±cult to
achieve. The location data supplied by the user's mobile
network provider varies in accuracy according to the num-
ber of cell towers the phone is currently within range of: the
more towers in range, the more accurate the triangulated
location. The accuracy o®ered by cell-tower triangulation
is inferior to that o®ered by GPS. Thus, the adaptive satel-
lite navigation system's operating environment can be par-
titioned into two distinct domains: GPS Signal Available
(D1) and GPS Signal Unavailable (D2). Figure 1 shows the
level-one SR model for the S1 target system, to operate in
domain D1.
Figure 1: Level-One SR Model for S1 Target System
In Figure 1, the goal: "Provide Directions" is satis¯ed by
the completion of the task: "O®er Verbal Navigation". This
task is decomposed into the goals "Calculate Fastest Route",
"Find Current Location" and, most importantly, "Provide
Verbal Cues". The "Calculate Fastest Route" and "Find
Current Location" goals could be modelled as having sev-
eral alternate means of satisfaction, and are omitted here
for simplicity and brevity. Our concern: the "Provide Ver-