A Language for Self-Adaptive System Requirements

Jon Whittle, Pete Sawyer, Nelly Bencomo
Computing Department,
InfoLab21,
Lancaster University,
Lancaster LA1 4AW, UK
Betty H.C. Cheng
Department of Computer Science and
Engineering,
Michigan State University,
East Lansing, MI 48824, USA

ABSTRACT
Self-adaptive systems have the capability to autonomously
modify their behaviour at run-time in response to changes in
their environment. Such systems are now commonly built in
domains as diverse as enterprise computing, automotive control
systems, and environmental monitoring systems. To date,
however, there has been limited attention paid to how to
engineer requirements for such systems. As a result, self-
adaptivity is often constructed in an ad-hoc manner. In this
paper, we argue that a more rigorous treatment of requirements
relating to self-adaptivity is needed and that, in particular,
requirements languages for self-adaptive systems should include
explicit constructs for specifying and dealing with the
uncertainty inherent in self-adaptive systems. We present some
initial thoughts on a new requirements language for self-
adaptive systems and illustrate it using examples from the
services domain.
1. Introduction
A system has goals that must be satisfied and, whether these
goals are explicitly identified or not, system requirements should
be formulated to guarantee goal satisfaction. This fundamental
principle has served systems development well for several
decades but is founded on an assumption that goals are fixed. In
general, goals can remain fixed if the environment in which the
system operates is stable. Hence, for example, using
conventional development techniques and systems
infrastructures, banking systems can be developed on the
assumption that the fundamental characteristics of the financial
services industry remain stable. However, in the 1980s,
deregulation caused fundamental changes to the UK financial
services industry. So significant were these environment
changes that UK banking systems had new goals. Many existing
systems had to undergo costly changes and completely new
systems had to be developed to adapt to the new environment.
Deregulation of the UK financial services industry caused
fundamental changes to banks’ operating environments but this
change took place over a period of time that was sufficiently
long to allow developers to make the necessary system
adaptations. Increasingly, there is a demand for systems whose
environment changes at a rate that necessitates the system to
adapt in real time and with minimal intervention of developers.
As an example, a mobile device may need the ability to adapt in
order to take advantage of new services as they come in range
and become available. The goals of such a system may remain
constant (e.g., to provide users with access to communication
and information services) but subtle trade-offs in how they are
satisfied may be necessary. For example, the choice of service to
use may be constrained by a preference for certain service
providers that may not always be available. The need for such
trade-offs poses significant challenges for system developers but
it is also possible to envisage systems where the environment is
so volatile that the goals themselves change, and change so fast
that systems need to adapt at run-time. (We acknowledge,
however, that at the highest level of abstraction, invariant goals
exist that indicate the fundamental services that must be
provided by an adaptive system.)
Consider, for example, an autonomous vehicle designed for use
in hazardous environments. One of its goals is to extinguish
fires. It is a valuable vehicle so it also has a goal to preserve its
capability to fight future fires, perhaps specified as (amongst
others) a requirement that the temperature of the vehicle’s
casing must be maintained below some threshold value. If
operating at the scene of a chemical fire (say) where the fire is in
danger of reaching a tank of explosive chemicals, however, the
second goal may have to be relaxed or disappear. Hence, in such
circumstances, it may be better to allow the vehicle to remain in
position spreading fire-suppressant chemicals for longer than
guarantees the vehicle’s survival, if this offers the best chance of
avoiding an explosion. Note that there is an implicit trade-off
between the two goals and it is easy to hypothesise
circumstances where, even in non-emergency situations, the
state of the environment might mean that achieving both goals
was infeasible.
Quite aside from the obvious challenges of implementing such a
self-adaptive system (although great strides in developing
adaptive infrastructures have been made in recent years [9]), it is
difficult to specify requirements to satisfy goals that:
ξ may change in the sense that their priority in relation to
other goals may evolve;
ξ may disappear, as in the case of the self-preservation goal
above;
ξ may have been unanticipated by the analyst.

Clearly, this final category is beyond the capabilities of existing
technologies, yet it is not outside the scope of the vision of fully
autonomic computing such as that articulated in [6]. Existing
requirements techniques are unsuited even to the expression of
the first two classes of goal. Mandating goal or requirement
satisfaction using the traditional “shall” (the vehicle shall ensure
its own survival) is unhelpful because it does not allow
requirements to be relaxed. Simply picking a different modal
verb (the vehicle should ensure its own survival) doesn’t help
much. Fit Criteria [11] may be used to define different levels of
requirement satisficement but their principal role is to define
how to verify a requirement. It is important to retain this crucial
role for fit criteria and not conflate it with the separate issue of
the specification of uncertainty. Traditional behavioural
modelling techniques are poorly suited also, although notations
such as i* [15], that allow the analyst to model NFR (non-
functional) trade-offs go some way to help. However, these
typically support only enumeration of alternative goals that are
known at design time.
This paper makes the first steps towards defining a requirements
language that addresses the first two problems identified above.
We sketch out a vocabulary that allows analysts to mark
requirements that may be relaxed at run-time and embody this in
a requirements engineering language, RELAX. Our ultimate aim
is to address uncertainty in requirements to support self-adaptive
systems development, in a way such that the uncertainty can be
specified declaratively rather than by simply enumerating all
alternative goals. Doing so will enable run-time adaptation
modules to reason about goal satisfaction at run-time in such a
way that critical goals are never jeopardised but non-critical
goals may be left unsatisfied temporarily. The paper also
outlines a process for translating traditional requirements into
RELAX requirements. This process supports requirements
engineers who must determine points of flexibility in their
requirements.
The paper is structured as follows. Section 2 outlines RELAX.
Section 3 applies it to an example from the smart office domain.
Section 4 describes related work and is followed by conclusions
and a discussion of further work.
2. RELAX: a Requirements Engineering
Language for Self-Adaptive Systems
In this section, we present our initial work towards a
requirements engineering language, RELAX, for self-adaptive
systems. RELAX is based on two fundamental principles:
ξ In practice, most requirements are written as textual
documents.
ξ Requirements for self-adaptive systems should build
in flexibility in the way that goals are satisfied or
traded-off against each other.
As a result, RELAX is a textual requirements language that
includes a vocabulary for identifying explicit points where
flexibility is allowed. Furthermore, since understanding where
points of flexibility are allowed (or disallowed) is generally
difficult, we propose a requirements process that guides
engineers in modifying a set of traditional requirements into a
set of RELAX requirements.

2.1 Vocabulary for Identifying Flexibility

Typically, textual requirements prescribe behavior using a
modal verb such as SHALL (or WILL) that defines actions or
functionality that a software system must always provide. For
self-adaptive systems, however, such statements are overly
prescriptive and requirements should instead mark explicit
points where the system is free to trade-off or relax
requirements. We propose a specific vocabulary for expressing
these kinds of requirements. This vocabulary enables
requirements engineers to explicitly identify requirements that
should never change as well as requirements that may change
under certain conditions. Our vocabulary currently includes the
following keywords.
2.1.1 Modal verb:
SHALL – we retain the conventional modal verb for expressing a
requirement. This is because, even in self-adaptive systems,
some requirements are forever invariant.
However, for a requirement that contributes to the satisfaction of
goals that may be temporarily left unsatisfied, the inclusion of a
temporal or ordinal RELAX-ation modifier will define the
requirement as RELAX-able. In such a case, the requirement
statement should also define the conditions for RELAX-ation
using the MONITOR and ENVIRONMENT keywords (which
are explained under Section 2.1.4).
2.1.2 Temporal RELAX-ation
We currently offer three temporal modifiers, as follows.
AS CLOSE AS POSSIBLE TO <frequency> – expresses a
requirement that something occurs repeatedly but the frequency
may be relaxed. The ideal frequency of occurrence is defined
but the modifier allows one to represent uncertainty about the
frequency and which conditions in the environment will permit
frequency relaxation. The requirement will be completely
satisfied if the actual occurrence is periodic and at the ideal
frequency. If this is unachievable, however, the system should
ensure that the event occurs periodically at a frequency that is as
close to the ideal as conditions permit, or aperiodically at a mean
frequency that is as close as is achievable to the ideal. The
clause implicitly mandates the system to opportunistically adapt
in order to achieve as close to the ideal frequency and as close to
being periodic as is feasible.
AS EARLY AS POSSIBLE AFTER <event> – expresses a
requirement that an event occurs immediately after the defined
event or, if that is not possible, with minimal delay. Again,
implicit in the clause is the requirement that the system adapts to
minimize the delay whenever an opportunity to do so occurs.
EVENTUALLY – expresses the requirement that something must
occur. How soon it occurs is less important but eventual
occurrence must be guaranteed, by adaptation of the system if
necessary.
2.1.3 Ordinal RELAX-ation
RELAX also supports the following ordinal modifier.
AS {MANY|FEW} <subject> AS POSSIBLE – permits one to
mandate that the system maximizes or minimizes some
occurrence. Again, opportunistic adaptation is implicitly
required of the system.