The four levels of requirements engineering for and in dynamic adaptive systems
System (2005)
- ISBN: 0769522688
- DOI: 10.1109/HICSS.2005.139
- arXiv: 1102.4178
Available from citeseerx.ist.psu.edu
or
Abstract
This paper argues that there are four levels of requirements engineer- ing for and in a dynamic adaptive system: (1) by humans, for the general behavior of the system, (2) by the system itself, whenever it is adapting based on changes to its environment, (3) by humans, to decide when, how, and where the system is to adapt, and (4) by humans, doing research about adaptive systems.
Available from citeseerx.ist.psu.edu
Page 1
The four levels of requirements engineering for and in dynamic adaptive systems
Mixed-Variable Requirements Roadmaps and their Role
in the Requirements Engineering of Adaptive Systems
Ivan J. Jureta
University of Namur
ivan.jureta@fundp.ac.be
Alexander Borgida
Rutgers University
borgida@cs.rutgers.edu
Neil A. Ernst
University of Toronto
nernst@cs.toronto.edu
Abstract—The requirements roadmap concept is introduced
as a solution to the problem of the requirements engineering
of adaptive systems. The concept requires a new general
definition of the requirements problem which allows for quan-
titative (numeric) variables, together with qualitative (binary
boolean) propositional variables, and distinguishes monitored
from controlled variables for use in control loops. We study the
consequences of these changes, and argue that the requirements
roadmap concept bridges the gap between current general
definitions of the requirements problem and its notion of
solution, and the research into the relaxation of requirements,
the evaluation of their partial satisfaction, and the monitoring
and control of requirements, all topics of particular interest in
the engineering of requirements for adaptive systems [3]. From
the theoretical perspective, we show clearly and formally the
fundamental differences between more traditional conception
of requirements engineering (e.g., Zave & Jackson [16]) and
the requirements engineering of adaptive systems (from Fickas
& Feather [6], over Letier & van Lamsweerde [9], and up
to Whittle et al. [14] and the most recent research). From the
engineering perspective, we define a proto-framework for early
requirements engineering of adaptive systems, which illustrates
the features needed in future requirements frameworks for this
class of systems.
Keywords-requirements roadmap, requirements problem,
adaptive systems, relaxation of requirements, monitoring
I. INTRODUCTION
There is a growing interest in the requirements engineering
(RE) of adaptive systems, whose salient feature is the ability to
adjust behavior in response to requirements and environment
variations. The robustness and versatility that these systems
promise will likely result in future sustained investment in
theoretical and applied RE research.
The salient feature of research in RE of adaptive systems is
disconnectedness (see Cheng et al. [3] for a general overview,
Whittle et al. [14] for a recent and comprehensive list of
references in RE). This reflects the very novelty of this class
of systems, so that mature results were not to be expected.
But disconnectedness causes a number of very practical
problems which should be discussed already now, reflected
by such general questions as “How exactly is RE for this
class of systems different from established RE?”, “How do
the inputs and outputs of RE for adaptive systems differ from
those in established RE?”, as well as more specific ones, e.g.,
“What should we keep, remove from, or add to existing RE
modeling languages/frameworks/methodologies to use them
for RE of adaptive systems?”.
The aim of this paper is to give clear and formal answers
to these questions, and thereby help connect existing research,
inform future work, move closer to a deeper classification of
research in RE of adaptive systems, and help skeptics decide
if/how novel is the problem posed to RE by adaptive systems.
To reach this aim, we illustrate and define the requirements
problem for adaptive systems, using a formalism which is just
expressive enough to include concepts and relations already
appearing in RE, and which includes features central for RE of
adaptive systems: (i) monitoring and control of requirements
(following Fickas & Feather [6], Feather et al. [5], and
Robinson [11]); (ii) probabilistic relaxation of requirements
(Letier & van Lamsweerde [9]); (iii) fuzzy relaxation of
requirements (Whittle et al. [14] and Baresi et al. [2]); and (iv)
adaptation requirements (Souza et al. [13]). It turns out that
extending the simple, but abstract modeling language Techne
[7] to allow constraints over quantitative (numerical) variables
is enough to capture key ideas in monitoring, relaxation,
and adaptation, and to show how they participate in the
requirements problem of adaptive systems.
This paper presents two main contributions:
The requirements problem for adaptive systems and its
solution concept, called requirements roadmap (roadmap
hereafter), are formally defined. A roadmap amounts
to a sequence of requirements configurations, each of
which is shown to satisfy all properties required by
Zave & Jackson [16], and in our prior work [8]. These
parallels show exactly how the problem and roadmap
concepts are different from more traditional RE.
To introduce the problem and roadmap concepts, we
define a simple formalism in which we can model (i)
probabilistic and fuzzy relaxation, (ii) monitored and
controlled variables, (iii) adaptation requirements. It is
a proto-framework for RE because (a) it is impractical
in its current form, but is enough to allow us to present
and discuss the salient properties of the problem and
roadmap concepts, and (b) it can serve as a prototype
for early formal modeling languages for RE of adaptive
systems.
ar
X
iv
:1
10
2.
41
78
v1
[
cs
.SE
]
21
Fe
b 2
01
1
in the Requirements Engineering of Adaptive Systems
Ivan J. Jureta
University of Namur
ivan.jureta@fundp.ac.be
Alexander Borgida
Rutgers University
borgida@cs.rutgers.edu
Neil A. Ernst
University of Toronto
nernst@cs.toronto.edu
Abstract—The requirements roadmap concept is introduced
as a solution to the problem of the requirements engineering
of adaptive systems. The concept requires a new general
definition of the requirements problem which allows for quan-
titative (numeric) variables, together with qualitative (binary
boolean) propositional variables, and distinguishes monitored
from controlled variables for use in control loops. We study the
consequences of these changes, and argue that the requirements
roadmap concept bridges the gap between current general
definitions of the requirements problem and its notion of
solution, and the research into the relaxation of requirements,
the evaluation of their partial satisfaction, and the monitoring
and control of requirements, all topics of particular interest in
the engineering of requirements for adaptive systems [3]. From
the theoretical perspective, we show clearly and formally the
fundamental differences between more traditional conception
of requirements engineering (e.g., Zave & Jackson [16]) and
the requirements engineering of adaptive systems (from Fickas
& Feather [6], over Letier & van Lamsweerde [9], and up
to Whittle et al. [14] and the most recent research). From the
engineering perspective, we define a proto-framework for early
requirements engineering of adaptive systems, which illustrates
the features needed in future requirements frameworks for this
class of systems.
Keywords-requirements roadmap, requirements problem,
adaptive systems, relaxation of requirements, monitoring
I. INTRODUCTION
There is a growing interest in the requirements engineering
(RE) of adaptive systems, whose salient feature is the ability to
adjust behavior in response to requirements and environment
variations. The robustness and versatility that these systems
promise will likely result in future sustained investment in
theoretical and applied RE research.
The salient feature of research in RE of adaptive systems is
disconnectedness (see Cheng et al. [3] for a general overview,
Whittle et al. [14] for a recent and comprehensive list of
references in RE). This reflects the very novelty of this class
of systems, so that mature results were not to be expected.
But disconnectedness causes a number of very practical
problems which should be discussed already now, reflected
by such general questions as “How exactly is RE for this
class of systems different from established RE?”, “How do
the inputs and outputs of RE for adaptive systems differ from
those in established RE?”, as well as more specific ones, e.g.,
“What should we keep, remove from, or add to existing RE
modeling languages/frameworks/methodologies to use them
for RE of adaptive systems?”.
The aim of this paper is to give clear and formal answers
to these questions, and thereby help connect existing research,
inform future work, move closer to a deeper classification of
research in RE of adaptive systems, and help skeptics decide
if/how novel is the problem posed to RE by adaptive systems.
To reach this aim, we illustrate and define the requirements
problem for adaptive systems, using a formalism which is just
expressive enough to include concepts and relations already
appearing in RE, and which includes features central for RE of
adaptive systems: (i) monitoring and control of requirements
(following Fickas & Feather [6], Feather et al. [5], and
Robinson [11]); (ii) probabilistic relaxation of requirements
(Letier & van Lamsweerde [9]); (iii) fuzzy relaxation of
requirements (Whittle et al. [14] and Baresi et al. [2]); and (iv)
adaptation requirements (Souza et al. [13]). It turns out that
extending the simple, but abstract modeling language Techne
[7] to allow constraints over quantitative (numerical) variables
is enough to capture key ideas in monitoring, relaxation,
and adaptation, and to show how they participate in the
requirements problem of adaptive systems.
This paper presents two main contributions:
The requirements problem for adaptive systems and its
solution concept, called requirements roadmap (roadmap
hereafter), are formally defined. A roadmap amounts
to a sequence of requirements configurations, each of
which is shown to satisfy all properties required by
Zave & Jackson [16], and in our prior work [8]. These
parallels show exactly how the problem and roadmap
concepts are different from more traditional RE.
To introduce the problem and roadmap concepts, we
define a simple formalism in which we can model (i)
probabilistic and fuzzy relaxation, (ii) monitored and
controlled variables, (iii) adaptation requirements. It is
a proto-framework for RE because (a) it is impractical
in its current form, but is enough to allow us to present
and discuss the salient properties of the problem and
roadmap concepts, and (b) it can serve as a prototype
for early formal modeling languages for RE of adaptive
systems.
ar
X
iv
:1
10
2.
41
78
v1
[
cs
.SE
]
21
Fe
b 2
01
1
Page 2
We use the London Ambulance Service (LAS) case study
[1] to recall and illustrate the key notions from prior work
that we mentioned above (xII), then to informally illustrate
the new problem and roadmap concepts (xIII). We discuss
their departure from prior work (xIV), and present the
formalization of the concepts and relations used to define
these concepts and model there instances throughout the
paper (xV). Finally, we summarize conclusions and open
issues (xVI).
II. BASELINE & RELATED WORK
We discuss in this section how earlier contributions in RE
– concerning monitoring and control, probabilistic relaxation,
and fuzzy relaxation – influence the understanding of the
requirements problem and its solutions for adaptive systems.
A. Background
We assume that requirements are either propositional
variables or constraints on quantitative variables, which are
categorized according to the core ontology [8], and that
relations are formalized as in Techne [7]; a requirement is
k: a domain assumption if it states a value that a variable
is believed to have; e.g., in Figure 1(a), k(r1) is a
domain assumption over a propositional, qualitative
variable, while in Figure 1(d), k((tx) = 0:6) is a
domain assumption over a quantitative variable, the
value of a function ;
g: a goal if it identifies a desirable value of a qualitative
variable, i.e., it states a property that we want to see
holding; e.g., g(p2) in Figure 1(a);
q: a quality constraint if it places a constraint on desirable
values of a quantitative variable; e.g., in Figure 1(d),
q(tx = 60sec) says that the desirable value of tx is
60sec;
s: a softgoal if it refers to a desirable value of a variable
in such a way that it is not possible to identify exactly
which value, or range of values of that variable it refers
to; e.g., in Figure 1(d), s(w1) is a softgoal.
t: a task if the propositional variable in it says what to
do; e.g., in Figure 1(a), t(u1) is a task.
A requirement can be mandatory, optional, or neither.
g(q2)M is a mandatory goal, which means that it must be
satisfied. g(p15)O is an optional goal, meaning that it is more
desirable that it is satisfied, than not, but we will still accept a
system which fails to satisfy g(p15)O. Requirements can be in
three binary or n-ary relations. The directed arrow in Figure
1(a) represents the inference relation [7], also understood
as a conditional, if-then relation, so that the line from t(u1)
to g(p2) abbreviates the formula k(t(u1) ! g(p2)), i.e., a
domain assumption according to which, if we can deduce
t(u1), then we can also deduce g(p2), or in other words, t(u1)
operationalizes g(p2). The inference relation stands for opera-
tionalization when it goes from tasks and domain assumptions
to goals; otherwise, it can be read as a refinement: in Figure
1(a), k(k(r1)^k(r2)^g(p1)^g(p2)^g(p3)^g(p4)! g(q2)M)
says that the domain assumptions k(r1) and k(r2), and the
goals g(p1) to g(p4) refine g(q2)M. Logically inconsistent
requirements are in the conflict relation: e.g., we assume
in Figure 1(a) that t(u2) cannot be satisfied together with
t(u4), which we draw with the bulleted line between them,
and this abbreviates the assumption k(t(u2) ^ t(u4)! ?):
if we can deduce both, then we will also conclude logical
inconsistency. Finally, we can have a preference relation
between requirements: e.g., t(u10) t(u13) in Figure 1(d)
reads that satisfying t(u10) is strictly more desirable than
satisfying t(u13).
B. Monitoring, Control, Probabilistic & Fuzzy Relaxation
Enabling adaptive behavior requires the monitoring of
requirements and control of behaviors intended to satisfy
requirements. Fickas & Feather [6] suggested that for
this we must start with a specification of all alternative
behaviors to be considered in a requirments model, that
is, alternative refinements and operationalizations of all
requirements. The model is then a source of monitored
variables, the observed values of which will trigger behaviors,
called reconciliation tactics, that are intended to change
the values of control variables, which can affect how one
operationalizes a requirement. This forms a control loop,
through which the system observes and reacts by switching
from one runtime configuration to another. For illustration,
consider the goal g(p3 : Check if double location) for LAS
in Figure 1(a), which is operationalized via two refinements:
one way to satisfy g(p3) is by executing both tasks t(u2) and
t(u3), the other is via t(u4). A reconciliation tactic could
be, e.g., if t(u2) fails, then operationalize g(p3) by t(u4).
Feather et al. [5] combined the requirements monitoring
mechanisms from Fickas & Feather with KAOS [4] to make
an RE framework, where requirements can be converted into
constraints on events, and events are monitored at runtime.
Robinson [11] suggested a requirements monitoring platform
that can be combined with a requirements modeling language
via translation rules between the expressions of the latter
and those accepted by the former, then suggested how to use
OCL as the modeling language for the platform [12].
An important characteristic of a reconciliation tactic (and
same applies to adaptation goals [2]), is that it is defined
in relation to local requirements, i.e., it says what to do
in relation to a single requirement which is not being
satisfied. There are two problems with defining adaptation
requirements by looking mainly at local requirements. First,
it is not clear that following any or every reconciliation
tactic will make sure that the new system configuration is
consistent with the requirements. It is not clear what happens
if the reconciliation tactic works locally, but activates, e.g.,
tasks which are inconsistent with some other already active
part of the system. The other problem is that one local
change may seem fine by itself, and may result in a new
[1] to recall and illustrate the key notions from prior work
that we mentioned above (xII), then to informally illustrate
the new problem and roadmap concepts (xIII). We discuss
their departure from prior work (xIV), and present the
formalization of the concepts and relations used to define
these concepts and model there instances throughout the
paper (xV). Finally, we summarize conclusions and open
issues (xVI).
II. BASELINE & RELATED WORK
We discuss in this section how earlier contributions in RE
– concerning monitoring and control, probabilistic relaxation,
and fuzzy relaxation – influence the understanding of the
requirements problem and its solutions for adaptive systems.
A. Background
We assume that requirements are either propositional
variables or constraints on quantitative variables, which are
categorized according to the core ontology [8], and that
relations are formalized as in Techne [7]; a requirement is
k: a domain assumption if it states a value that a variable
is believed to have; e.g., in Figure 1(a), k(r1) is a
domain assumption over a propositional, qualitative
variable, while in Figure 1(d), k((tx) = 0:6) is a
domain assumption over a quantitative variable, the
value of a function ;
g: a goal if it identifies a desirable value of a qualitative
variable, i.e., it states a property that we want to see
holding; e.g., g(p2) in Figure 1(a);
q: a quality constraint if it places a constraint on desirable
values of a quantitative variable; e.g., in Figure 1(d),
q(tx = 60sec) says that the desirable value of tx is
60sec;
s: a softgoal if it refers to a desirable value of a variable
in such a way that it is not possible to identify exactly
which value, or range of values of that variable it refers
to; e.g., in Figure 1(d), s(w1) is a softgoal.
t: a task if the propositional variable in it says what to
do; e.g., in Figure 1(a), t(u1) is a task.
A requirement can be mandatory, optional, or neither.
g(q2)M is a mandatory goal, which means that it must be
satisfied. g(p15)O is an optional goal, meaning that it is more
desirable that it is satisfied, than not, but we will still accept a
system which fails to satisfy g(p15)O. Requirements can be in
three binary or n-ary relations. The directed arrow in Figure
1(a) represents the inference relation [7], also understood
as a conditional, if-then relation, so that the line from t(u1)
to g(p2) abbreviates the formula k(t(u1) ! g(p2)), i.e., a
domain assumption according to which, if we can deduce
t(u1), then we can also deduce g(p2), or in other words, t(u1)
operationalizes g(p2). The inference relation stands for opera-
tionalization when it goes from tasks and domain assumptions
to goals; otherwise, it can be read as a refinement: in Figure
1(a), k(k(r1)^k(r2)^g(p1)^g(p2)^g(p3)^g(p4)! g(q2)M)
says that the domain assumptions k(r1) and k(r2), and the
goals g(p1) to g(p4) refine g(q2)M. Logically inconsistent
requirements are in the conflict relation: e.g., we assume
in Figure 1(a) that t(u2) cannot be satisfied together with
t(u4), which we draw with the bulleted line between them,
and this abbreviates the assumption k(t(u2) ^ t(u4)! ?):
if we can deduce both, then we will also conclude logical
inconsistency. Finally, we can have a preference relation
between requirements: e.g., t(u10) t(u13) in Figure 1(d)
reads that satisfying t(u10) is strictly more desirable than
satisfying t(u13).
B. Monitoring, Control, Probabilistic & Fuzzy Relaxation
Enabling adaptive behavior requires the monitoring of
requirements and control of behaviors intended to satisfy
requirements. Fickas & Feather [6] suggested that for
this we must start with a specification of all alternative
behaviors to be considered in a requirments model, that
is, alternative refinements and operationalizations of all
requirements. The model is then a source of monitored
variables, the observed values of which will trigger behaviors,
called reconciliation tactics, that are intended to change
the values of control variables, which can affect how one
operationalizes a requirement. This forms a control loop,
through which the system observes and reacts by switching
from one runtime configuration to another. For illustration,
consider the goal g(p3 : Check if double location) for LAS
in Figure 1(a), which is operationalized via two refinements:
one way to satisfy g(p3) is by executing both tasks t(u2) and
t(u3), the other is via t(u4). A reconciliation tactic could
be, e.g., if t(u2) fails, then operationalize g(p3) by t(u4).
Feather et al. [5] combined the requirements monitoring
mechanisms from Fickas & Feather with KAOS [4] to make
an RE framework, where requirements can be converted into
constraints on events, and events are monitored at runtime.
Robinson [11] suggested a requirements monitoring platform
that can be combined with a requirements modeling language
via translation rules between the expressions of the latter
and those accepted by the former, then suggested how to use
OCL as the modeling language for the platform [12].
An important characteristic of a reconciliation tactic (and
same applies to adaptation goals [2]), is that it is defined
in relation to local requirements, i.e., it says what to do
in relation to a single requirement which is not being
satisfied. There are two problems with defining adaptation
requirements by looking mainly at local requirements. First,
it is not clear that following any or every reconciliation
tactic will make sure that the new system configuration is
consistent with the requirements. It is not clear what happens
if the reconciliation tactic works locally, but activates, e.g.,
tasks which are inconsistent with some other already active
part of the system. The other problem is that one local
change may seem fine by itself, and may result in a new
Page 3
gM(q1: Ambulances arrive at their incident locations)
gM(q2: Emergency calls are responded to)
g(p5: Identify available ambulances)
g(p6: Choose ambulance)
g(p7: Assign ambulances)
g(p8: Mobilize ambulances)
g(p9: Confirm mobilization)
k(r1: Every call is switched to the ambulance dispatch center)
k(r2: No calls are dropped because of timeout)
g(p1: Receive emergency call)
g(p2: Identify incident locations)
g(p3: Check if double location)
g(p4: Fill out incident report)
g(p10: Receive confirmation of arrival to incident location)
g(p11: Close incident report form)
g(p12: Incident location identified automatically)
t(u1: Make the map searchable through the dispatch software )
g(p13: Manually identify location using paper map)
kM(r3: Callers report imprecise incident location)
g(p14: Dispatch software aids the identification of duplicate calls )
t(u2: List of open incident locations incidents visible in the
dispatch interface)
t(u3: Update the list of open incident locations every time
an open incident is added)
t(u4: Every control assistant manually keeps track of locations
of open incidents)
t(u5: Fill out incident report via the software)
t(u6: Fill out a paper incident report form)
t(u7: Make the list of all available and of all allocated ambulances
available through the dispatch interface)
t(u8: Update the list of all available and of all allocated ambulances
every time an ambulance is assigned to an incident )
t(u9: Every control assistant manually keeps track of available ambulances )
t(u10: Dispatch software ranks available ambulances from the most
appropriate for the incident location to the least appropriate )
t(u11: Dispatch software displays the ranking of available
ambulances to the control assistant)
t(u12: Control assistant chooses herself/himself an ambulance
among available ambulances)
k(r4: Control assistants use heuristics that are difficult to automate when
choosing an ambulance)
t(u13: Dispatch software makes no recommendations to the control
assistant on which ambulance to choose)
t(u14: Control assistant uses the dispatch software to select one of the
available ambulances and assign it to the incident )
t(u15: Control assistant verbally communicates to all other control
assistants which ambulance was chosen for assignment to the incident )
t(u16: Control assistant mobilizes the ambulance through radio
communication with the staff in the ambulance)
t(u17: Control assistant uses the dispatch software to mobilize the
ambulance without talking to the staff in the ambulance )
t(u18: Staff in the ambulance uses the dispatch software client in the
ambulance to confirm mobilization at the given incident location )
t(u19: Staff in the ambulance uses the dispatch software client in the
ambulance to confirm the arrival at the incident location)
t(u20: Staff in the ambulance use the radio to confirm the arrival at the
incident location)
t(u21: Close the incident report via the software)
t(u22: Manually close and put aside a paper incident report form )
gO(p15: Paper is not used in the control room)
k(r1)
k(r2)
kM(r3)
t(u1)
t(u2)
t(u3)
t(u5)
t(u7)
t(u8)
t(u10)
t(u11)
t(u12)
t(u14)
t(u17)
t(u19)
t(u21)
k(r4)
k(r1)
k(r2)
kM(r3)
t(u1)
t(u4)
t(u6)
t(u9)
t(u13)
t(u15)
t(u16)
t(u18)
t(u20)
t(u22)
k(r1)
k(r2)
kM(r3)
t(u1)
t(u2)
t(u3)
t(u6)
t(u7)
t(u8)
t(u10)
t(u11)
t(u12)
t(u14)
t(u16)
t(u20)
t(u22)
t(u18) t(u18)
g(p1)
g(p2)
g(p3)
g(p4)
g(p5)
g(p6)
g(p7)
g(p8)
g(p9)
g(p10)
g(p11)
gM(q1)
gM(q2)
S1 S2 S3
gO(p15)
t(u21) >
t(u22)
t(u19) >
t(u20)
t(u16) >
t(u17)
t(u14) >
t(u15)
t(u12)
t(u10) >
t(u13)
k( = 0 .6) >
k( = 0 .1)
t(u5) >
t(u6)
satisfaction
µ(tx)
s(w1: Quickly
establish if
double location)
k(µ (tx)
= 0.6)
q(P(e ≤0.10)
= 0.8)
0.10)
= 0.2)
q(tx =
30sec)
q(tx =
60sec)
time (tx)
s(w2: Make few errors
when identifying
available ambulances)
probability of
error P(e)
satisfaction
(P(e))
k(
= 0.1)
)) = 0.7) >
)) = 0.3)
k( (P(e)) =
0.7)
)) =
0.3)
µ (tx)
µ (tx)
µ (tx)
µ
µ k( (P(eµ
k( (P(eµ
k( (P(eµ
q(P(e ≤
(a) Early qualitative requirements (b) Mandatory goals (c) Req. configurations (d) Comparison criteria
Legend
xMConditional (if-then)
Conflict
Mandatory requirement
xO Optional requirement
g: Goal
k: Domain assumption
t: Task
q: Quality constraint
s: Softgoal
See text for interpretation. t(u21) >
t(u22)
Task t(u21) is strictly preferred to task t(u22).
Figure 1. Simple early requirements, requirements configurations, and comparison criteria for LAS.
and consistent configuration, but this new configuration may
be a dominated one: i.e., maybe instead of satisfying one
adaptation requirement and obtaining some quality level,
we could have used several adaptations, which result in a
configuration that ensures higher quality. The local approach
to the definition of adaptation requirements comes with the
risk of adapting to a sub-optimal or inconsistent configuration.
We therefore contend that instead of defining adaptation
requirements by considering their impact only on a small set
of requirements, adaptation requirements should be defined so
gM(q2: Emergency calls are responded to)
g(p5: Identify available ambulances)
g(p6: Choose ambulance)
g(p7: Assign ambulances)
g(p8: Mobilize ambulances)
g(p9: Confirm mobilization)
k(r1: Every call is switched to the ambulance dispatch center)
k(r2: No calls are dropped because of timeout)
g(p1: Receive emergency call)
g(p2: Identify incident locations)
g(p3: Check if double location)
g(p4: Fill out incident report)
g(p10: Receive confirmation of arrival to incident location)
g(p11: Close incident report form)
g(p12: Incident location identified automatically)
t(u1: Make the map searchable through the dispatch software )
g(p13: Manually identify location using paper map)
kM(r3: Callers report imprecise incident location)
g(p14: Dispatch software aids the identification of duplicate calls )
t(u2: List of open incident locations incidents visible in the
dispatch interface)
t(u3: Update the list of open incident locations every time
an open incident is added)
t(u4: Every control assistant manually keeps track of locations
of open incidents)
t(u5: Fill out incident report via the software)
t(u6: Fill out a paper incident report form)
t(u7: Make the list of all available and of all allocated ambulances
available through the dispatch interface)
t(u8: Update the list of all available and of all allocated ambulances
every time an ambulance is assigned to an incident )
t(u9: Every control assistant manually keeps track of available ambulances )
t(u10: Dispatch software ranks available ambulances from the most
appropriate for the incident location to the least appropriate )
t(u11: Dispatch software displays the ranking of available
ambulances to the control assistant)
t(u12: Control assistant chooses herself/himself an ambulance
among available ambulances)
k(r4: Control assistants use heuristics that are difficult to automate when
choosing an ambulance)
t(u13: Dispatch software makes no recommendations to the control
assistant on which ambulance to choose)
t(u14: Control assistant uses the dispatch software to select one of the
available ambulances and assign it to the incident )
t(u15: Control assistant verbally communicates to all other control
assistants which ambulance was chosen for assignment to the incident )
t(u16: Control assistant mobilizes the ambulance through radio
communication with the staff in the ambulance)
t(u17: Control assistant uses the dispatch software to mobilize the
ambulance without talking to the staff in the ambulance )
t(u18: Staff in the ambulance uses the dispatch software client in the
ambulance to confirm mobilization at the given incident location )
t(u19: Staff in the ambulance uses the dispatch software client in the
ambulance to confirm the arrival at the incident location)
t(u20: Staff in the ambulance use the radio to confirm the arrival at the
incident location)
t(u21: Close the incident report via the software)
t(u22: Manually close and put aside a paper incident report form )
gO(p15: Paper is not used in the control room)
k(r1)
k(r2)
kM(r3)
t(u1)
t(u2)
t(u3)
t(u5)
t(u7)
t(u8)
t(u10)
t(u11)
t(u12)
t(u14)
t(u17)
t(u19)
t(u21)
k(r4)
k(r1)
k(r2)
kM(r3)
t(u1)
t(u4)
t(u6)
t(u9)
t(u13)
t(u15)
t(u16)
t(u18)
t(u20)
t(u22)
k(r1)
k(r2)
kM(r3)
t(u1)
t(u2)
t(u3)
t(u6)
t(u7)
t(u8)
t(u10)
t(u11)
t(u12)
t(u14)
t(u16)
t(u20)
t(u22)
t(u18) t(u18)
g(p1)
g(p2)
g(p3)
g(p4)
g(p5)
g(p6)
g(p7)
g(p8)
g(p9)
g(p10)
g(p11)
gM(q1)
gM(q2)
S1 S2 S3
gO(p15)
t(u21) >
t(u22)
t(u19) >
t(u20)
t(u16) >
t(u17)
t(u14) >
t(u15)
t(u12)
t(u10) >
t(u13)
k( = 0 .6) >
k( = 0 .1)
t(u5) >
t(u6)
satisfaction
µ(tx)
s(w1: Quickly
establish if
double location)
k(µ (tx)
= 0.6)
q(P(e ≤0.10)
= 0.8)
0.10)
= 0.2)
q(tx =
30sec)
q(tx =
60sec)
time (tx)
s(w2: Make few errors
when identifying
available ambulances)
probability of
error P(e)
satisfaction
(P(e))
k(
= 0.1)
)) = 0.7) >
)) = 0.3)
k( (P(e)) =
0.7)
)) =
0.3)
µ (tx)
µ (tx)
µ (tx)
µ
µ k( (P(eµ
k( (P(eµ
k( (P(eµ
q(P(e ≤
(a) Early qualitative requirements (b) Mandatory goals (c) Req. configurations (d) Comparison criteria
Legend
xMConditional (if-then)
Conflict
Mandatory requirement
xO Optional requirement
g: Goal
k: Domain assumption
t: Task
q: Quality constraint
s: Softgoal
See text for interpretation. t(u21) >
t(u22)
Task t(u21) is strictly preferred to task t(u22).
Figure 1. Simple early requirements, requirements configurations, and comparison criteria for LAS.
and consistent configuration, but this new configuration may
be a dominated one: i.e., maybe instead of satisfying one
adaptation requirement and obtaining some quality level,
we could have used several adaptations, which result in a
configuration that ensures higher quality. The local approach
to the definition of adaptation requirements comes with the
risk of adapting to a sub-optimal or inconsistent configuration.
We therefore contend that instead of defining adaptation
requirements by considering their impact only on a small set
of requirements, adaptation requirements should be defined so
Page 4
as to ensure that the configuration obtained after adaptation
is desirable in its entirety in terms of various criteria
used to compare alternative requirements configurations
(including, for example, preferences over requirements,
probabilities of requirements satisfaction, and so on). This
has two consequences on the formulation of the problem and
solution concepts in adaptive system requirements. First, it
follows that we do not define adaptation requirements while
writing the requirements model, but compute them after we
have identified at least some configurations from a set of
alternatives, all of which satisfy some set of properties (e.g.,
are consistent) and satisfy some preferrence requirements.
Consider Figure 1(c), where each column S1, S2, and S3 is
a different requirements configuration, and each satisfies the
mandatory goals set in Figure 1(a) for the LAS system: e.g.,
if the system is configured according to S1, and t(u5) fails,
then it may be more desirable to adapt to S3 than to S2,
so that adaptation requirements can be identified directly by
comparing S1 to S3, and defined as the switch from t(u21)
to t(u22), from t(u19) to t(u20), from t(u17) to t(u16), and
from t(u5) to t(u6). Secondly, the local/global distinction has
an impact on how we select configurations: it is likely that the
system can adapt from one to one among several alternative
configurations; e.g., if t(u17) fails in Figure 1(c), both S2
and S3 use the alternative t(u18). Selection should take into
account the consequences of adapting to a configuration: e.g.,
perhaps configuration S1 is more desirable than S2 if only
these two are compared, but we may know that if we select
S1, then in the long term, e.g., it is not sustainable, in order
to keep satisfying some quality constraint. This means that
there can be preferences over sequences of configurations.
Adaptive behavior by definition means that the system
cannot satisfy all the specific requirements and meet the
desired quality levels, all of the time – it may do worse,
but it may also do better. Relaxation of requirements has
been suggested to cover both cases: a requirement can be
relaxed to allow the system to fail it, but we restrict how
often it can do so (via probabilistic relaxation), or to avoid
overly constraining the system when it may deliver higher
quality than expected (via fuzzy relaxation). Relaxation of
requirements is closely related to the evaluation of their
satifaction, as one aim of relaxation is to quantify the degree
of satisfaction of a requirement. Two broad approaches to
relaxation and satisfaction evaluation have been suggested,
based on objective criteria (where quantification is in terms
of measurable phenomena in the environment or the system)
or on subjective criteria (where a number is given to reflect
personal impression of satisfaction, regardless of measurable
phenomena in the domain).
An important approach to relaxation, based on objective
criteria, appears in Letier & van Lamsweerde [9], who
extended goal models from KAOS to allow the specification of
measures on system behaviors, and probability functions over
the values of these measures. Using such a formalism, they
can state, e.g., that in the LAS system, 95% of ambulances
should reach the designated place of incident in at most 14
minutes after an incident is reported. Values of measures
and probabilities are computed for every requirements
configuration, all of which are inputs to a decision-making
process that aims at selecting a single configuration.
Approaches based on subjective criteria were revived re-
cently for RE of adaptive systems. Whittle et al. [14] associate
fuzzy membership functions to qualitative requirements, in
order to allow and quantify departures from the ideal satisfac-
tion of such requirements. The fuzzy membership function
can be interpreted as a satisfaction function, and they use
modalities to relax requirements: e.g., to relax the task t(u18)
in Figure 1, we would write [As early as possible]t(u18).
This means that there is a function which returns a level
of satisfaction when given a duration between time “now”
and the time when t(u18) is executed, whereby “has its
maximum value at 0 (i.e., at the current point in time)
[and] tails off gradually ad infinitum (i.e., it has a triangular
membership graph that is asymptotic)” [14].
Baresi et al. [2] also use fuzzy membership functions
to treat qualitative requirements as quantitative ones. They
introduce degrees of satisfaction between the binary 0 (for
violated) and 1 (satisfied); thus, adjusted requirements are
associated to “adaptive” requirements that relate ranges of
values of the fuzzy membership function to trigger switching
between configurations. For example, if there is a quality
constraint q(v < 6hrs) here (a goal G(v < 6hrs) for them,
as they allow quantitative variables in goals), then relaxing
it would amount to replacing it with q(v <f 6hrs) (in their
notation, G(v <f 6hrs)), where f is a fuzzy operator.
Their interpretation of v <f 6hrs is that there is a fuzzy
membership function which returns the level of satisfaction
as a function of v, and the shape of is predefined (for <f
in G(v <f 6hrs), it is positive and constant until v = 6, then
decreases up to the satisfaction value 0 for some v > 6).
III. RPAS & ROADMAP CONCEPTS
The requirements problem for adaptive systems (RPAS) and
the corresponding roadmap concept need to be introduced
because monitoring, control, adaptive requirements, and
probabilistic and fuzzy relaxation cannot be formulated in
the traditional requirements problem and solution framework:
these features add information to the requirements problem,
which in turn affects the properties that solutions need to
satisfy, and influence the criteria used to compare alternative
solutions. The aim of this section is to present and discuss the
properties of the roadmap concept, as the solution concept
for RPAS; we later compare RPAS and roadmap concepts to
Zave & Jackson [16] and Techne [8] (cf., xIV).
A. Requirements Problem for Adaptive Systems
The requirements problem is a design and decision-making
problem. By design, we mean that alternative solutions to
is desirable in its entirety in terms of various criteria
used to compare alternative requirements configurations
(including, for example, preferences over requirements,
probabilities of requirements satisfaction, and so on). This
has two consequences on the formulation of the problem and
solution concepts in adaptive system requirements. First, it
follows that we do not define adaptation requirements while
writing the requirements model, but compute them after we
have identified at least some configurations from a set of
alternatives, all of which satisfy some set of properties (e.g.,
are consistent) and satisfy some preferrence requirements.
Consider Figure 1(c), where each column S1, S2, and S3 is
a different requirements configuration, and each satisfies the
mandatory goals set in Figure 1(a) for the LAS system: e.g.,
if the system is configured according to S1, and t(u5) fails,
then it may be more desirable to adapt to S3 than to S2,
so that adaptation requirements can be identified directly by
comparing S1 to S3, and defined as the switch from t(u21)
to t(u22), from t(u19) to t(u20), from t(u17) to t(u16), and
from t(u5) to t(u6). Secondly, the local/global distinction has
an impact on how we select configurations: it is likely that the
system can adapt from one to one among several alternative
configurations; e.g., if t(u17) fails in Figure 1(c), both S2
and S3 use the alternative t(u18). Selection should take into
account the consequences of adapting to a configuration: e.g.,
perhaps configuration S1 is more desirable than S2 if only
these two are compared, but we may know that if we select
S1, then in the long term, e.g., it is not sustainable, in order
to keep satisfying some quality constraint. This means that
there can be preferences over sequences of configurations.
Adaptive behavior by definition means that the system
cannot satisfy all the specific requirements and meet the
desired quality levels, all of the time – it may do worse,
but it may also do better. Relaxation of requirements has
been suggested to cover both cases: a requirement can be
relaxed to allow the system to fail it, but we restrict how
often it can do so (via probabilistic relaxation), or to avoid
overly constraining the system when it may deliver higher
quality than expected (via fuzzy relaxation). Relaxation of
requirements is closely related to the evaluation of their
satifaction, as one aim of relaxation is to quantify the degree
of satisfaction of a requirement. Two broad approaches to
relaxation and satisfaction evaluation have been suggested,
based on objective criteria (where quantification is in terms
of measurable phenomena in the environment or the system)
or on subjective criteria (where a number is given to reflect
personal impression of satisfaction, regardless of measurable
phenomena in the domain).
An important approach to relaxation, based on objective
criteria, appears in Letier & van Lamsweerde [9], who
extended goal models from KAOS to allow the specification of
measures on system behaviors, and probability functions over
the values of these measures. Using such a formalism, they
can state, e.g., that in the LAS system, 95% of ambulances
should reach the designated place of incident in at most 14
minutes after an incident is reported. Values of measures
and probabilities are computed for every requirements
configuration, all of which are inputs to a decision-making
process that aims at selecting a single configuration.
Approaches based on subjective criteria were revived re-
cently for RE of adaptive systems. Whittle et al. [14] associate
fuzzy membership functions to qualitative requirements, in
order to allow and quantify departures from the ideal satisfac-
tion of such requirements. The fuzzy membership function
can be interpreted as a satisfaction function, and they use
modalities to relax requirements: e.g., to relax the task t(u18)
in Figure 1, we would write [As early as possible]t(u18).
This means that there is a function which returns a level
of satisfaction when given a duration between time “now”
and the time when t(u18) is executed, whereby “has its
maximum value at 0 (i.e., at the current point in time)
[and] tails off gradually ad infinitum (i.e., it has a triangular
membership graph that is asymptotic)” [14].
Baresi et al. [2] also use fuzzy membership functions
to treat qualitative requirements as quantitative ones. They
introduce degrees of satisfaction between the binary 0 (for
violated) and 1 (satisfied); thus, adjusted requirements are
associated to “adaptive” requirements that relate ranges of
values of the fuzzy membership function to trigger switching
between configurations. For example, if there is a quality
constraint q(v < 6hrs) here (a goal G(v < 6hrs) for them,
as they allow quantitative variables in goals), then relaxing
it would amount to replacing it with q(v <f 6hrs) (in their
notation, G(v <f 6hrs)), where f is a fuzzy operator.
Their interpretation of v <f 6hrs is that there is a fuzzy
membership function which returns the level of satisfaction
as a function of v, and the shape of is predefined (for <f
in G(v <f 6hrs), it is positive and constant until v = 6, then
decreases up to the satisfaction value 0 for some v > 6).
III. RPAS & ROADMAP CONCEPTS
The requirements problem for adaptive systems (RPAS) and
the corresponding roadmap concept need to be introduced
because monitoring, control, adaptive requirements, and
probabilistic and fuzzy relaxation cannot be formulated in
the traditional requirements problem and solution framework:
these features add information to the requirements problem,
which in turn affects the properties that solutions need to
satisfy, and influence the criteria used to compare alternative
solutions. The aim of this section is to present and discuss the
properties of the roadmap concept, as the solution concept
for RPAS; we later compare RPAS and roadmap concepts to
Zave & Jackson [16] and Techne [8] (cf., xIV).
A. Requirements Problem for Adaptive Systems
The requirements problem is a design and decision-making
problem. By design, we mean that alternative solutions to
Page 5
the problem are not available, but need to be created: e.g., in
Figure 1(a), we start from two broad goals, g(q1) and g(q2),
so that we need to elicit further requirements and information,
refine goals, identify conflicts, define operationalizations, all
of which fall under design.1 Decision-making requires the
identification of criteria for the comparison of alternative
solutions, and the application of a decision rule to rank
alternative solutions from the most desirable to the least
desirable.
To provide definitions, we start with the notion of a
requirements database — a set of requirements (i.e.,
domain assumptions, goals, quality constraints, softgoals,
tasks) and relations between them (e.g., conjunction, in-
ference, refinement, conflict, preference). For example, the
requirements database for LAS in this paper includes all
labeled propositions in Figure 1.
For the remaining definitions, we start at the end (RPAS),
and explain one by one its component definitions. Hence
definitions unfold recursively.
RPAS is the problem of designing and ranking roadmaps.
Definition III.1. The requirements problem for adaptive
systems: Given a requirements database , design, find,
and rank roadmaps that can be defined from .
A roadmap is a sequence of requirements configurations
and adaptation requirements needed to switch between these
configurations.
Definition III.2. A requirements roadmap is a pair R =
(S;A), where S = (S1; : : : ; Sn) is a sequence of n
requirements configurations and A is a set of adaptation
requirements.
The novelty of the problem and roadmap concepts lies
in the properties of requirements configurations, adaptation
requirements, and in how roadmaps can be ranked. We discuss
these in turn below.
B. Properties of Requirements Configurations
Let us first look at the configurations appearing in a
roadmap.
Definition III.3. A configuration in a roadmap is a set
S of domain assumptions and tasks in such that S
satisfies the Consistency, Qualitative threshold achievement,
Quantitative threshold achievement, Conformity, Dominance,
and Minimality conditions defined below.
1) Consistency: Every requirements configuration S must
be consistent, i.e., S 6jv ?, where jv is the Techne
consequence relation [7]. With consistency, the adaptive
1Note that “design” is typically used for steps of systems development
that come after RE, such as architectural design. The term “design” is
used here in a broader sense, to encompass all activities (e.g., elicitation,
validation) which are necessary to make alternative options on which we
then need to decide.
system should work to satisfy a consistent set of requirements.
In Figure 1(c), every configuration is such that there are no
conflicts between its members. Remark that given a sequence
S = (S1; : : : ; Sn) in a road map,
S
S can, and will often
be inconsistent, as consecutive configurations need not be
consistent together. If we adapt from S1 to S2 in Figure
1(c), note that S1 [ S2 jv ?, since there are conflicts, e.g.,
between t(u16) and t(u17).
2) Qualitative Threshold Achievement: Every configura-
tion S should operationalize every mandatory goal in —
a set written as Mg. An operationlization defines tasks and
domain assumptions from which we can deduce (via jv ) the
goal. For example, in Figure 1(a), if the task t(u1) is satisfied,
then g(p2) is satisfied, so that the former operationalizes
the latter. Since a requirement can be operationalized by
alternative sets of tasks and domain assumptions, we have
a function Op(') which, which given a mandatory goal
' 2 Mg, returns the set of all operationalizations of '.
E.g., Op(g(p7)) includes two operationalizations of g(p7)
in Figure 1(a). The property is restricted to qualitative
requirements, for which satisfaction is binary, and thus to
goals, since a goal is either satisfied or not. The property
requires threshold satisfaction, since it requires only that all
mandatory goals be satisfied by a configuration.
A consistent set of requirements must meet both the
qualitative and quantitative thresholds, for it otherwise fails
to satisfy the requirements which must be satisfied.
3) Quantitative Threshold Achievement: Every config-
uration Sshould operationalize every mandatory quality
constraint in — a set written as Mq. Once again, the
function Ov('), returns all sets of operationalizations of
quality constraint ' = q( ), whereby some set is such
an operationalization iff it assigns values to variables in
which ensure that the constraint in is satisfied. Quality
constraints identify desirable values of quantitative variables.
E.g., qs may thus place constraints on values of measures of
some behavior of the system-to-be. In LAS, and in relation
to the response to emergency calls and the mobilization of
ambulances, the time that these activities take is a crucial
part of quality of service. We can use the following variables,
where c identifies a call and e a unique incident:
t1;c: Time the caller waits for a control assistant;
t2;c: Time to identify incident location;
t3;c: Time to fill out incident report;
t4;e: Time to mobilize an ambulance;
t5;e: Time for the mobilized ambulance to arrive and
confirm arrival at incident location.
Instead of defining bounds on all of these variables, a
government standard may not be as specific, and may impose
a maximal time over a subset of activities that need to be
executed between the placement of the emergency call and
the confirmation of arrival of an ambulance to location; e.g.:
q(t6;c 3min: t6;c is the duration between the
switching of the call c to the dispatch center to the
mobilization of the ambulance to the incident location;)
Figure 1(a), we start from two broad goals, g(q1) and g(q2),
so that we need to elicit further requirements and information,
refine goals, identify conflicts, define operationalizations, all
of which fall under design.1 Decision-making requires the
identification of criteria for the comparison of alternative
solutions, and the application of a decision rule to rank
alternative solutions from the most desirable to the least
desirable.
To provide definitions, we start with the notion of a
requirements database — a set of requirements (i.e.,
domain assumptions, goals, quality constraints, softgoals,
tasks) and relations between them (e.g., conjunction, in-
ference, refinement, conflict, preference). For example, the
requirements database for LAS in this paper includes all
labeled propositions in Figure 1.
For the remaining definitions, we start at the end (RPAS),
and explain one by one its component definitions. Hence
definitions unfold recursively.
RPAS is the problem of designing and ranking roadmaps.
Definition III.1. The requirements problem for adaptive
systems: Given a requirements database , design, find,
and rank roadmaps that can be defined from .
A roadmap is a sequence of requirements configurations
and adaptation requirements needed to switch between these
configurations.
Definition III.2. A requirements roadmap is a pair R =
(S;A), where S = (S1; : : : ; Sn) is a sequence of n
requirements configurations and A is a set of adaptation
requirements.
The novelty of the problem and roadmap concepts lies
in the properties of requirements configurations, adaptation
requirements, and in how roadmaps can be ranked. We discuss
these in turn below.
B. Properties of Requirements Configurations
Let us first look at the configurations appearing in a
roadmap.
Definition III.3. A configuration in a roadmap is a set
S of domain assumptions and tasks in such that S
satisfies the Consistency, Qualitative threshold achievement,
Quantitative threshold achievement, Conformity, Dominance,
and Minimality conditions defined below.
1) Consistency: Every requirements configuration S must
be consistent, i.e., S 6jv ?, where jv is the Techne
consequence relation [7]. With consistency, the adaptive
1Note that “design” is typically used for steps of systems development
that come after RE, such as architectural design. The term “design” is
used here in a broader sense, to encompass all activities (e.g., elicitation,
validation) which are necessary to make alternative options on which we
then need to decide.
system should work to satisfy a consistent set of requirements.
In Figure 1(c), every configuration is such that there are no
conflicts between its members. Remark that given a sequence
S = (S1; : : : ; Sn) in a road map,
S
S can, and will often
be inconsistent, as consecutive configurations need not be
consistent together. If we adapt from S1 to S2 in Figure
1(c), note that S1 [ S2 jv ?, since there are conflicts, e.g.,
between t(u16) and t(u17).
2) Qualitative Threshold Achievement: Every configura-
tion S should operationalize every mandatory goal in —
a set written as Mg. An operationlization defines tasks and
domain assumptions from which we can deduce (via jv ) the
goal. For example, in Figure 1(a), if the task t(u1) is satisfied,
then g(p2) is satisfied, so that the former operationalizes
the latter. Since a requirement can be operationalized by
alternative sets of tasks and domain assumptions, we have
a function Op(') which, which given a mandatory goal
' 2 Mg, returns the set of all operationalizations of '.
E.g., Op(g(p7)) includes two operationalizations of g(p7)
in Figure 1(a). The property is restricted to qualitative
requirements, for which satisfaction is binary, and thus to
goals, since a goal is either satisfied or not. The property
requires threshold satisfaction, since it requires only that all
mandatory goals be satisfied by a configuration.
A consistent set of requirements must meet both the
qualitative and quantitative thresholds, for it otherwise fails
to satisfy the requirements which must be satisfied.
3) Quantitative Threshold Achievement: Every config-
uration Sshould operationalize every mandatory quality
constraint in — a set written as Mq. Once again, the
function Ov('), returns all sets of operationalizations of
quality constraint ' = q( ), whereby some set is such
an operationalization iff it assigns values to variables in
which ensure that the constraint in is satisfied. Quality
constraints identify desirable values of quantitative variables.
E.g., qs may thus place constraints on values of measures of
some behavior of the system-to-be. In LAS, and in relation
to the response to emergency calls and the mobilization of
ambulances, the time that these activities take is a crucial
part of quality of service. We can use the following variables,
where c identifies a call and e a unique incident:
t1;c: Time the caller waits for a control assistant;
t2;c: Time to identify incident location;
t3;c: Time to fill out incident report;
t4;e: Time to mobilize an ambulance;
t5;e: Time for the mobilized ambulance to arrive and
confirm arrival at incident location.
Instead of defining bounds on all of these variables, a
government standard may not be as specific, and may impose
a maximal time over a subset of activities that need to be
executed between the placement of the emergency call and
the confirmation of arrival of an ambulance to location; e.g.:
q(t6;c 3min: t6;c is the duration between the
switching of the call c to the dispatch center to the
mobilization of the ambulance to the incident location;)
Page 6
where it is clear that the value of t6;c depends on t1;c, t2;c,
t3;c and t4;e. If we assume that t6;c = t1;c+ t2;c+ t3;c+ t4;e,
then we add this to the requirements database as a domain
assumption over quantitative variables, k(t6;c = t1;c + t2;c +
t3;c + t4;e). The domain assumption says that there is a
quantitative refinement relation between variables, and it
specifies the functional relation between the refined t6;c and
the variables refining it. In contrast to the refinement relation,
quantitative refinement is not over requirements, but variables
in requirements.
While it may be useful to set a precise bound on the
value of an aggregate variable, as t6;c above, it may be
more interesting to set bounds relative to the values of other
variables. E.g., if we want t2;c to be at most 110% of its
average value over the past three months, then we write
q(t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1));
k(v1;m = n(m) 1
Pn(m)
i=1
Pc(i)
c=1 t2;c), where m is the
month identifier, n(m) the number of days in m, c
is the call identifier on a given day, c(i) is the total
number of calls received on day i of month m;
where the domain assumption is a quantitative refinement of
v1;m, the average time, over a month, that it takes to identify
the location.
The quality constraints and quantitative refinements need
to be related to goals, tasks and domain assumptions in
order to determine if the former are satisfied. If there is
a running system, the values of t2;c are recorded, and
it is straightforward to check if the constraint t2;c
(1:1=3)(v1;m 3 + v1;m 2 + v1;m 1) is satisfied. Before
the system is in operation, we can simulate values of
t2;c, by assuming that t2;c is a random variable which
has some probability distribution, so that we would have
k(t2;c v N(60sec; 45sec2)) if we assume that t2;c follows
a normal distribution with mean 60sec and variance 45sec2
when the task t(u1) is satisfied, which we model by a
refinement k(t(u1) ! k(t2;c v N(60sec; 45sec2))). This
assumption may be based on data from a pilot study, from
expert opinion, or from data on systems which also satisfy
t(u1) and are already in operation.
4) Conformity: Every configuration S must include all
strict domain assumptions and all mandatory tasks, i.e.,
Mk [
M
t S. This property asks that all strict domain
assumptions are not violated and all mandatory tasks are
executed in every configuration.
The Qualitative and Quantitative threshold achievement
and Conformity properties ensure that a configuration satisfies
all that must be satisfied.
5) Dominance: Every configuration S must be maximal
w.r.t. optional requirements, i.e., 6 9S0 such that (i) both
satisfy the Consistency, Qualitative threshold achievement,
Quantitative threshold achievement, and Conformity condi-
tions, (ii) S S0, and (iii) S0 n S contains optional k or t
requirements.
This condition formalizes the idea of optional requirements,
which are desirable to satisfy, but can be violated. A
configuration should include as many such defeasible domain
assumptions and as many optional tasks, up to the point at
which adding any further defeasible domain assumptions
and/or optional tasks violates the Consistency, Qualitative
and Quantitative threshold achievement, and Conformity
properties. The Dominance property ensures that every
configuration is Pareto efficient with regards to optional
requirements, as this condition makes it impossible to add
optional domain assumptions and tasks to any S and still
ensure that S is a configuration.
6) Minimality: A set S satisfying all the above properties
must be minimal in order to qualify as a configuration.
Minimality requires that a configuration includes only the
domain assumptions and tasks which are needed to satisfy
exactly the Consistency, Qualitative threshold achievement,
Quantitative threshold achievement, Conformity, and Domi-
nance properties.
Configurations in Figure 1(c) satisfy all six properties.
C. Adaptation Requirements, Monitoring & Control
An adaptation requirement is meant to constrain suc-
cessive configurations in a roadmap. It does so by de-
scribing the presence/absence of certain requirements in
pairs of related configurations, and is triggerred by the
failure of monitored assumptions, tasks, or quality con-
straints. For example, in Figure 1(c), if task t(u21) fails,
we might want to replace ft(u19); t(u17); t(u5)g with
ft(u22); t(u20); t(u16); t(u6)g. In general, we will therefore
want to specify the conditions monitored for failure, and
the changes (additions, removals) that must be seen in
the successor configuration when failure occurs. The above
adaptation requirement can then tell us that if we are running
the configuration S1 in Figure 1(c), and the system fails to
satisfy t(u21), then it could adapt from S1 to S3. Note that
an adaptation requirement hT;A;Di might then be thought
of as a a simple operator in AI planning, where T is trigger
condition, while A and D are add/delete lists.
Definition III.4. An adaptation requirement is an operator
of the form hT;A;Di, where T is a set of requirements
present in the initial configuration (which are monitored to
fail) while A and D are, respectively, sets of requirements
that must be present and absent in the final configuration, if
the operator applies.
Note therefore that if operator hT;A;Di applied in going
from configuration Si to Si+1, then T [D Si and A \
Si = must hold, and analogously with Si+1. Note also that
it is quite acceptable that multiple operators apply at the
same time, when connecting Si to Si+1, and that (as with
the so-called ramification problem in AI), there may be
additional changes needed in Si+1 in order to make it a valid
configuration.
t3;c and t4;e. If we assume that t6;c = t1;c+ t2;c+ t3;c+ t4;e,
then we add this to the requirements database as a domain
assumption over quantitative variables, k(t6;c = t1;c + t2;c +
t3;c + t4;e). The domain assumption says that there is a
quantitative refinement relation between variables, and it
specifies the functional relation between the refined t6;c and
the variables refining it. In contrast to the refinement relation,
quantitative refinement is not over requirements, but variables
in requirements.
While it may be useful to set a precise bound on the
value of an aggregate variable, as t6;c above, it may be
more interesting to set bounds relative to the values of other
variables. E.g., if we want t2;c to be at most 110% of its
average value over the past three months, then we write
q(t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1));
k(v1;m = n(m) 1
Pn(m)
i=1
Pc(i)
c=1 t2;c), where m is the
month identifier, n(m) the number of days in m, c
is the call identifier on a given day, c(i) is the total
number of calls received on day i of month m;
where the domain assumption is a quantitative refinement of
v1;m, the average time, over a month, that it takes to identify
the location.
The quality constraints and quantitative refinements need
to be related to goals, tasks and domain assumptions in
order to determine if the former are satisfied. If there is
a running system, the values of t2;c are recorded, and
it is straightforward to check if the constraint t2;c
(1:1=3)(v1;m 3 + v1;m 2 + v1;m 1) is satisfied. Before
the system is in operation, we can simulate values of
t2;c, by assuming that t2;c is a random variable which
has some probability distribution, so that we would have
k(t2;c v N(60sec; 45sec2)) if we assume that t2;c follows
a normal distribution with mean 60sec and variance 45sec2
when the task t(u1) is satisfied, which we model by a
refinement k(t(u1) ! k(t2;c v N(60sec; 45sec2))). This
assumption may be based on data from a pilot study, from
expert opinion, or from data on systems which also satisfy
t(u1) and are already in operation.
4) Conformity: Every configuration S must include all
strict domain assumptions and all mandatory tasks, i.e.,
Mk [
M
t S. This property asks that all strict domain
assumptions are not violated and all mandatory tasks are
executed in every configuration.
The Qualitative and Quantitative threshold achievement
and Conformity properties ensure that a configuration satisfies
all that must be satisfied.
5) Dominance: Every configuration S must be maximal
w.r.t. optional requirements, i.e., 6 9S0 such that (i) both
satisfy the Consistency, Qualitative threshold achievement,
Quantitative threshold achievement, and Conformity condi-
tions, (ii) S S0, and (iii) S0 n S contains optional k or t
requirements.
This condition formalizes the idea of optional requirements,
which are desirable to satisfy, but can be violated. A
configuration should include as many such defeasible domain
assumptions and as many optional tasks, up to the point at
which adding any further defeasible domain assumptions
and/or optional tasks violates the Consistency, Qualitative
and Quantitative threshold achievement, and Conformity
properties. The Dominance property ensures that every
configuration is Pareto efficient with regards to optional
requirements, as this condition makes it impossible to add
optional domain assumptions and tasks to any S and still
ensure that S is a configuration.
6) Minimality: A set S satisfying all the above properties
must be minimal in order to qualify as a configuration.
Minimality requires that a configuration includes only the
domain assumptions and tasks which are needed to satisfy
exactly the Consistency, Qualitative threshold achievement,
Quantitative threshold achievement, Conformity, and Domi-
nance properties.
Configurations in Figure 1(c) satisfy all six properties.
C. Adaptation Requirements, Monitoring & Control
An adaptation requirement is meant to constrain suc-
cessive configurations in a roadmap. It does so by de-
scribing the presence/absence of certain requirements in
pairs of related configurations, and is triggerred by the
failure of monitored assumptions, tasks, or quality con-
straints. For example, in Figure 1(c), if task t(u21) fails,
we might want to replace ft(u19); t(u17); t(u5)g with
ft(u22); t(u20); t(u16); t(u6)g. In general, we will therefore
want to specify the conditions monitored for failure, and
the changes (additions, removals) that must be seen in
the successor configuration when failure occurs. The above
adaptation requirement can then tell us that if we are running
the configuration S1 in Figure 1(c), and the system fails to
satisfy t(u21), then it could adapt from S1 to S3. Note that
an adaptation requirement hT;A;Di might then be thought
of as a a simple operator in AI planning, where T is trigger
condition, while A and D are add/delete lists.
Definition III.4. An adaptation requirement is an operator
of the form hT;A;Di, where T is a set of requirements
present in the initial configuration (which are monitored to
fail) while A and D are, respectively, sets of requirements
that must be present and absent in the final configuration, if
the operator applies.
Note therefore that if operator hT;A;Di applied in going
from configuration Si to Si+1, then T [D Si and A \
Si = must hold, and analogously with Si+1. Note also that
it is quite acceptable that multiple operators apply at the
same time, when connecting Si to Si+1, and that (as with
the so-called ramification problem in AI), there may be
additional changes needed in Si+1 in order to make it a valid
configuration.
Page 7
In the above sense, requirements are monitored, while
adaptation requirements act as a control mechanism, which
guides adaptation by changing the target requirements
configuration that the adaptive system needs to satisfy.
D. Comparison Criteria & Ranking of Roadmaps
Ranking of roadmaps requires the identification of com-
parison criteria, and the application of a decision rule which
establishes a ranking on the basis of criteria. Comparison
criteria are either optional requirements or preferences.
Preferences can be individually added to , or can be
obtained through the relaxation of requirements, or from
softgoals. Preferences are illustrated in Figure 1(d), where,
e.g., t(u16) is strictly preferred to t(u17), which indicates
that, for this criterion only, a configuration having the former
task is strictly more desirable than the configuration having
the latter task.
1) Preferences through Probabilistic Relaxation: Contin-
uing the earlier example (cf., xIII-B3), the upper bound on
t2;c in q(t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1)) may
still be too idealistic, as callers may provide information of
very different quality about the incident location.
Probabilistic relaxation of a quality constraint is done in
two steps. Firstly, the variable constrained in q is redefined
as a random variable, and an assumption is made on the
probability distribution of that random variable. Adding
k(t2;c v N(60sec; 45sec2)) to makes of t2;c a random
variable which follows a normal distribution. Secondly, the
quality constraint to be relaxed is removed from , and a
new quality constraint is added. The new constraint specifies
a bound not on the value of the now random variable, but
on the probability that its value is in some range. Since we
made t2;c into a random variable in the first step, we now
replace q(t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1)) with
q(P (t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1)) 0:90),
that is, we now require that the minimal probability should be
0.90 for t2;c to be at most 110% of its three-month average.
Random variables and quality constraints thereon play
an important role in decision-making, as we use them
to set desired probability levels over random variables.
In more informal terms, this means that we can write
quality constraints and domain assumptions which reflect,
respectively, the confidence that we desire to reach in relation
to system behaviors, and confidence that we actually have.
Figures 1(c)–(d) indicate that t(u7) operationalizes the quality
constraint q(P (e 0:10) = 0:8), while t(u8) operationalizes
q(P (e 0:10) = 0:2). The two quality constraints suggest
that the two tasks result in different probabilities of having
less than 10% of erroneous identifications of available ambu-
lances. Figure 1(d) further indicates the level of satisfaction
with each of the two probability levels.
2) Preferences through Fuzzy Relaxation: Fuzzy relax-
ation of a quality constraint involves two steps. In the
first step, the quality constraint is removed, and a fuzzy
membership function is defined over the variable from the
removed quality constraint. In the second step, a softgoal
is defined over the variable from the relaxed requirement.
Consider again q(t2;c (1:1=3)(v1;m 3+v1;m 2+v1;m 1))
and we now apply fuzzy relaxation. We start by removing
this quality constraint from . A fuzzy membership function
over t2;c, denote it (t2;c), depends on how stakeholders
evaluate, in terms of desirability, the various values of t2;c.
E.g., we could use (t2;c) = e t2;c , so that the higher the
value of t2;c, the lower (t2;c) is, which reflect the idea
that the more time it takes to identify an incident location,
the more the stakeholders are dissatisfied, whereby their
satisfaction increases as t2;c approaches 0 (another example
of a satisfaction function is in the upper part of Figure 1(d)).
If we adopt as defined, we have removed the quality
constraint on t2;c and we quantify satisfaction as a function
of t2;c.
To finish with the fuzzy relaxation of the quality constraint
on t2;c, a softgoal needs to be added to the requirements
database over values of t2;c. Softgoals have had various
definitions in RE, but there seems to be agreement on their two
properties: (i) they are used for the comparison of alternatives,
and (ii) they are vague, as they refer to some desirable values
of variables, even though it may not be clear which exact
values, or of which variables. E.g., Response time should be
low is a typical softgoal, where the variable is suggested,
but it is not clear which specific range of its values qualify
as low; in the softgoal High safety, not only is it not clear
how to measure safety, it is also not apparent when safety is
high. When used in fuzzy relaxation, a softgoal is defined
over a known variable: in our example, it is reasonable to
prefer lower over higher values of t2;c, and we consequently
have the softgoal
s( LET x1
def
= VAL(S1; t2;c) AND x2
def
= VAL(S2; t2;c);
IF (x1) > (x2) THEN ADD
fk(t2;c = x1); k(t2;c = x2);
k(t2;c = x1) k(t2;c = x2)g
TO ; )
where VAL(S1; t2;c) returns the value of t2;c in S1. Although
the formulation above seems very different from saying
“Low t2;c”, this is precisely what it does, as long as (t2;c)
decreases as t2;c increases. denotes the strict preference
relation, and k(t2;c = x1) k(t2;c = x2) says that satisfying
k(t2;c = x1) is strictly more desirable than satisfying
k(t2;c = x2). The important point to see is that the softgoal
specifies a macro which generates domain assumptions and
preference relations. For any two configurations S1 and S2,
the macro compares the satisfaction (returned by satisfaction
function ) with values that t2;c has in each of those two
configurations. Depending on the comparison between these
values, the macro adds two domain assumptions and a
preference relation to . The reason we add them to
and not individual configurations is because we can add one
of these domain assumptions only if doing so does not violate
adaptation requirements act as a control mechanism, which
guides adaptation by changing the target requirements
configuration that the adaptive system needs to satisfy.
D. Comparison Criteria & Ranking of Roadmaps
Ranking of roadmaps requires the identification of com-
parison criteria, and the application of a decision rule which
establishes a ranking on the basis of criteria. Comparison
criteria are either optional requirements or preferences.
Preferences can be individually added to , or can be
obtained through the relaxation of requirements, or from
softgoals. Preferences are illustrated in Figure 1(d), where,
e.g., t(u16) is strictly preferred to t(u17), which indicates
that, for this criterion only, a configuration having the former
task is strictly more desirable than the configuration having
the latter task.
1) Preferences through Probabilistic Relaxation: Contin-
uing the earlier example (cf., xIII-B3), the upper bound on
t2;c in q(t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1)) may
still be too idealistic, as callers may provide information of
very different quality about the incident location.
Probabilistic relaxation of a quality constraint is done in
two steps. Firstly, the variable constrained in q is redefined
as a random variable, and an assumption is made on the
probability distribution of that random variable. Adding
k(t2;c v N(60sec; 45sec2)) to makes of t2;c a random
variable which follows a normal distribution. Secondly, the
quality constraint to be relaxed is removed from , and a
new quality constraint is added. The new constraint specifies
a bound not on the value of the now random variable, but
on the probability that its value is in some range. Since we
made t2;c into a random variable in the first step, we now
replace q(t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1)) with
q(P (t2;c (1:1=3)(v1;m 3 + v1;m 2 + v1;m 1)) 0:90),
that is, we now require that the minimal probability should be
0.90 for t2;c to be at most 110% of its three-month average.
Random variables and quality constraints thereon play
an important role in decision-making, as we use them
to set desired probability levels over random variables.
In more informal terms, this means that we can write
quality constraints and domain assumptions which reflect,
respectively, the confidence that we desire to reach in relation
to system behaviors, and confidence that we actually have.
Figures 1(c)–(d) indicate that t(u7) operationalizes the quality
constraint q(P (e 0:10) = 0:8), while t(u8) operationalizes
q(P (e 0:10) = 0:2). The two quality constraints suggest
that the two tasks result in different probabilities of having
less than 10% of erroneous identifications of available ambu-
lances. Figure 1(d) further indicates the level of satisfaction
with each of the two probability levels.
2) Preferences through Fuzzy Relaxation: Fuzzy relax-
ation of a quality constraint involves two steps. In the
first step, the quality constraint is removed, and a fuzzy
membership function is defined over the variable from the
removed quality constraint. In the second step, a softgoal
is defined over the variable from the relaxed requirement.
Consider again q(t2;c (1:1=3)(v1;m 3+v1;m 2+v1;m 1))
and we now apply fuzzy relaxation. We start by removing
this quality constraint from . A fuzzy membership function
over t2;c, denote it (t2;c), depends on how stakeholders
evaluate, in terms of desirability, the various values of t2;c.
E.g., we could use (t2;c) = e t2;c , so that the higher the
value of t2;c, the lower (t2;c) is, which reflect the idea
that the more time it takes to identify an incident location,
the more the stakeholders are dissatisfied, whereby their
satisfaction increases as t2;c approaches 0 (another example
of a satisfaction function is in the upper part of Figure 1(d)).
If we adopt as defined, we have removed the quality
constraint on t2;c and we quantify satisfaction as a function
of t2;c.
To finish with the fuzzy relaxation of the quality constraint
on t2;c, a softgoal needs to be added to the requirements
database over values of t2;c. Softgoals have had various
definitions in RE, but there seems to be agreement on their two
properties: (i) they are used for the comparison of alternatives,
and (ii) they are vague, as they refer to some desirable values
of variables, even though it may not be clear which exact
values, or of which variables. E.g., Response time should be
low is a typical softgoal, where the variable is suggested,
but it is not clear which specific range of its values qualify
as low; in the softgoal High safety, not only is it not clear
how to measure safety, it is also not apparent when safety is
high. When used in fuzzy relaxation, a softgoal is defined
over a known variable: in our example, it is reasonable to
prefer lower over higher values of t2;c, and we consequently
have the softgoal
s( LET x1
def
= VAL(S1; t2;c) AND x2
def
= VAL(S2; t2;c);
IF (x1) > (x2) THEN ADD
fk(t2;c = x1); k(t2;c = x2);
k(t2;c = x1) k(t2;c = x2)g
TO ; )
where VAL(S1; t2;c) returns the value of t2;c in S1. Although
the formulation above seems very different from saying
“Low t2;c”, this is precisely what it does, as long as (t2;c)
decreases as t2;c increases. denotes the strict preference
relation, and k(t2;c = x1) k(t2;c = x2) says that satisfying
k(t2;c = x1) is strictly more desirable than satisfying
k(t2;c = x2). The important point to see is that the softgoal
specifies a macro which generates domain assumptions and
preference relations. For any two configurations S1 and S2,
the macro compares the satisfaction (returned by satisfaction
function ) with values that t2;c has in each of those two
configurations. Depending on the comparison between these
values, the macro adds two domain assumptions and a
preference relation to . The reason we add them to
and not individual configurations is because we can add one
of these domain assumptions only if doing so does not violate
Page 8
the conditions that a configuration must satisfy (i.e., adding
one of these domain assumptions may make a configuration
inconsistent, and thus no longer a configuration at all). The
macro above ensures that if we compare two configurations,
S1 and S2, t2;c obtains the value x1 in S1 and the value x2
in S2, then we will prefer over this criterion (independently
of other criteria) the configuration in which t2;s obtains the
value which results in higher satisfaction. The macro thus
conveys the idea that, whenever we are given two values of
t2;c, we prefer the one that we are more satisfied with.
Fuzzy relaxation of a quality constraint over a variable
v thus works by (i) removing the quality constraint on v,
(ii) adding a fuzzy membership function (v) on v, (iii)
interpreting (v) as the level of satisfaction with the value v,
and (iv) adding a softgoal macro which generates preference
relations that reflect the shape of .
3) Preferences from Softgoals: Not all softgoals are
macros used in fuzzy relaxation. A softgoal can be introduced
in even if we do now know the exact variable it refers
to, or the exact range of values that it makes desirable. Very
broad softgoals are allowed, such as
s(~p17: Ambulances should quickly arrive at incidents)
where we write ~p because the content of the softgoal is not a
propositional variable as in a goal or task, since it is not clear
from ~p17 how to measure the time of arriving to incident
scenes (e.g., does it begin at call reception, or at ambulance
mobilization?) and it is not clear when a time to arrive at an
incident counts as quick. There are two ways to approximate
such softgoals: by refinement or by satisfaction functions,
and both can result in preferences being added to .
When a softgoal is refined, it is treated just as any other
requirement. E.g., we may define the following refinement
of s(~p17)
q(t7;e 15min);
k(q(t7;e 15min)! s(~p17));
k(t7;e = t1;c + t2;c + t3;c + t4;e + t5;e);
where we refined the softgoal with the quality constraint
over the quantitative variable t7;e (i.e., if we satisfy q(t7;e
15min) then the if-then domain assumption above, with
implication, tells us to deduce s(~p17)), which is itself a
function of times introduced before. We could find another
refinement of s(~p17), and have a preference between the two.
A softgoal can be approximated using a satisfaction func-
tion, and by proceeding in a similar way to fuzzy relaxation.
Given s(~p17), we decide which variable it refers to, and we
assume it is t7;e, such that k(q(t7;e 15min) ! s(~p17)).
Secondly, we remove the softgoal s(~p17). Thirdly, we define a
function 1(t7;e), and we interpret the value given by 1(t7;e)
as the level of satisfaction with the value t7;e. Fourthly, we
add a softgoal macro over t7;e:
s( LET x1
def
= VAL(S1; t7;e) AND x2
def
= VAL(S2; t7;e);
IF 1(x1) > 1(x2) THEN ADD
fk(t7;e = x1); k(t7;e = x2);
k(t7;e = x1) k(t7;e = x2)g
TO ; )
This case is also illustrated with the softgoal s( ~w1) and
function (tx) in Figure 1(d).
4) Use of Criteria for Ranking: Given a set of criteria
and roadmaps, two kinds of decision rules are needed: (i) to
establish a ranking of configurations, from the most desirable
to the least desirable, in a roadmap; (ii) to establish a ranking
of roadmaps. RPAS, roadmap, and configuration concepts
specify no particular decision rule. This is intentional, as no
universal decision rule can be given: every decision rule gives
one or more criteria priority over others, so that domain-
and/or project-independent decision rules should be much
more interesting. Note that the decision rule to apply will
depend on how tradeoffs are resolved, through, among others,
stakeholder negotiations, these concerns remain outside the
scope of the general problem definition.
Various decision rules for configuration ranking can be
used, such as one of the following:
R1: Rank highest the configuration S if S maximizes the
quantitative variable v, and rank other configurations
in a descending order by value of v that each achieves:
i.e., S s.t., MAX(v) iff 8S0, S0 is a configuration and
max(VAL(S; v)) max(VAL(S0; v)), where max returns
the largest constant in a given set.
R2: Same as R1, but rank highest the configuration which
minimizes v, i.e., rank from MIN(v) to configuration
which results in the highest value of v.
R3: Same as R1, augmented for the following condition:
the chosen configuration should satisfy the maximal
number of optional and preferred requirements, where
in a preference relation or , is the
preferred requirement.
R1 and R2 ignore preferences and optional requirements
which are independent of v, and both give highest priority to
the value of a chosen variable. In that case, the decision rule
requires us to solve a single-objective optimization problem.
The third rule is significantly different, as it has two high
priorities, namely the value of the chosen quantitative variable
and the number of optional and preferred requirements. The
application of the third rule above requires the resolution of
a multi-objective optimization problem.
The decision-rules that ranks roadmaps focuses on the
properties of entire roadmaps. Maximization or minimization
of a quantitative variable can now be extended over an entire
roadmap, whereby we may ask that optimization satisfies
constraints on efficiency of adaptations. E.g., the decision
rule may be as follows:
R4: Choose roadmap R if (i) it maximizes the sum of values
of the quantitative variable v over all configurations in
R, under the constraints that (ii) v must never fall below
one of these domain assumptions may make a configuration
inconsistent, and thus no longer a configuration at all). The
macro above ensures that if we compare two configurations,
S1 and S2, t2;c obtains the value x1 in S1 and the value x2
in S2, then we will prefer over this criterion (independently
of other criteria) the configuration in which t2;s obtains the
value which results in higher satisfaction. The macro thus
conveys the idea that, whenever we are given two values of
t2;c, we prefer the one that we are more satisfied with.
Fuzzy relaxation of a quality constraint over a variable
v thus works by (i) removing the quality constraint on v,
(ii) adding a fuzzy membership function (v) on v, (iii)
interpreting (v) as the level of satisfaction with the value v,
and (iv) adding a softgoal macro which generates preference
relations that reflect the shape of .
3) Preferences from Softgoals: Not all softgoals are
macros used in fuzzy relaxation. A softgoal can be introduced
in even if we do now know the exact variable it refers
to, or the exact range of values that it makes desirable. Very
broad softgoals are allowed, such as
s(~p17: Ambulances should quickly arrive at incidents)
where we write ~p because the content of the softgoal is not a
propositional variable as in a goal or task, since it is not clear
from ~p17 how to measure the time of arriving to incident
scenes (e.g., does it begin at call reception, or at ambulance
mobilization?) and it is not clear when a time to arrive at an
incident counts as quick. There are two ways to approximate
such softgoals: by refinement or by satisfaction functions,
and both can result in preferences being added to .
When a softgoal is refined, it is treated just as any other
requirement. E.g., we may define the following refinement
of s(~p17)
q(t7;e 15min);
k(q(t7;e 15min)! s(~p17));
k(t7;e = t1;c + t2;c + t3;c + t4;e + t5;e);
where we refined the softgoal with the quality constraint
over the quantitative variable t7;e (i.e., if we satisfy q(t7;e
15min) then the if-then domain assumption above, with
implication, tells us to deduce s(~p17)), which is itself a
function of times introduced before. We could find another
refinement of s(~p17), and have a preference between the two.
A softgoal can be approximated using a satisfaction func-
tion, and by proceeding in a similar way to fuzzy relaxation.
Given s(~p17), we decide which variable it refers to, and we
assume it is t7;e, such that k(q(t7;e 15min) ! s(~p17)).
Secondly, we remove the softgoal s(~p17). Thirdly, we define a
function 1(t7;e), and we interpret the value given by 1(t7;e)
as the level of satisfaction with the value t7;e. Fourthly, we
add a softgoal macro over t7;e:
s( LET x1
def
= VAL(S1; t7;e) AND x2
def
= VAL(S2; t7;e);
IF 1(x1) > 1(x2) THEN ADD
fk(t7;e = x1); k(t7;e = x2);
k(t7;e = x1) k(t7;e = x2)g
TO ; )
This case is also illustrated with the softgoal s( ~w1) and
function (tx) in Figure 1(d).
4) Use of Criteria for Ranking: Given a set of criteria
and roadmaps, two kinds of decision rules are needed: (i) to
establish a ranking of configurations, from the most desirable
to the least desirable, in a roadmap; (ii) to establish a ranking
of roadmaps. RPAS, roadmap, and configuration concepts
specify no particular decision rule. This is intentional, as no
universal decision rule can be given: every decision rule gives
one or more criteria priority over others, so that domain-
and/or project-independent decision rules should be much
more interesting. Note that the decision rule to apply will
depend on how tradeoffs are resolved, through, among others,
stakeholder negotiations, these concerns remain outside the
scope of the general problem definition.
Various decision rules for configuration ranking can be
used, such as one of the following:
R1: Rank highest the configuration S if S maximizes the
quantitative variable v, and rank other configurations
in a descending order by value of v that each achieves:
i.e., S s.t., MAX(v) iff 8S0, S0 is a configuration and
max(VAL(S; v)) max(VAL(S0; v)), where max returns
the largest constant in a given set.
R2: Same as R1, but rank highest the configuration which
minimizes v, i.e., rank from MIN(v) to configuration
which results in the highest value of v.
R3: Same as R1, augmented for the following condition:
the chosen configuration should satisfy the maximal
number of optional and preferred requirements, where
in a preference relation or , is the
preferred requirement.
R1 and R2 ignore preferences and optional requirements
which are independent of v, and both give highest priority to
the value of a chosen variable. In that case, the decision rule
requires us to solve a single-objective optimization problem.
The third rule is significantly different, as it has two high
priorities, namely the value of the chosen quantitative variable
and the number of optional and preferred requirements. The
application of the third rule above requires the resolution of
a multi-objective optimization problem.
The decision-rules that ranks roadmaps focuses on the
properties of entire roadmaps. Maximization or minimization
of a quantitative variable can now be extended over an entire
roadmap, whereby we may ask that optimization satisfies
constraints on efficiency of adaptations. E.g., the decision
rule may be as follows:
R4: Choose roadmap R if (i) it maximizes the sum of values
of the quantitative variable v over all configurations in
R, under the constraints that (ii) v must never fall below
Page 9
value x in R, and (ii) no configuration in R differs from
the configuration which immediately precedes it by more
than y requirements.
R4 is a decision rule pattern, where a concrete rule is
obtained by setting x and y to constants. R4 illustrates that
constraints need not be limited on individual configurations,
but also on the structure of the roadmap, as it limits the
number of changes that can be performed, which may reflect
the necessity to conserve resources during adaptations.
It is important to note that the choice of a roadmap
does not impose the sequence of configurations that the
system should follow: adaptive behavior means that, e.g.,
if we adopt rule R4 above, the system will start from the
configuration in which the domain assumptions are consistent
with the conditions in the environment of the system. It will
then adapt according to the satisfaction/failure of monitored
requirements. It may be relevant to dynamically (at runtime)
compute new configurations, the discussion of which we
leave as an open issue.
IV. DEPARTURES FROM PRIOR WORK
The widely accepted general requirements problem def-
inition is Zave & Jackson’s [16] (ZJ hereafter), stating
that RE should produce a specification (S) of a design of
the system-to-be, which ensures that the system-to-be is
consistent with domain assumptions (K) and together with
them entails requirements (R): i.e., that K;S ` R. This
definition emphasizes two properties: (i) consistency, in that
the operationalization of requirements, i.e., K [ S must be
consistent; and (ii) achievement of requirements, as K [ S
are only acceptable if they are sufficient to deduce R.
For an example of ZJ problem and solution, cf., Figure
1(a). Assume that all goals there are the set R0, all domain
assumptions K 0, and all tasks S0. Given R0 and D0 initially,
the ZJ problem says that we should find tasks S S0 which
satisfy a consistent subset D D0 of domain assumptions,
and a consistent subset of requirements R R0. Any one
column among S1, S2, and S3 in Figure 1(c) is a consistent
set of domain assumptions and tasks which satisfy a set of
consistent goals (i.e., 8i; 1 i 3, Si = K [ S), so that
any one of these is a solution to the ZJ requirements problem.
This can be verified by looking at the conflict and conditional
relations in Figures 1(a)–(c).
There is in the ZJ problem formulation no information to
define comparison criteria. We offered a revised definition of
the requirements problem [8] (JMF hereafter), which has a
richer ontology (to account for concepts that have established
themselves in RE, such as, e.g., goals and softgoals), allows
inconsistencies between alternative configurations (each of
which satisfies ZJ conditions), introduces preferences to allow
the comparison of configurations in terms of desirability, and
we argued that logical consequence in early RE is more
adequately described by a nonmonotonic and paraconsistent
consequence relation jv [7] than ` from classical logic. These
revisions make it impossible to synthesize the requirements
problem as K;S ` R, since consistency and achievement
become only a part of the conditions that a solution should
satisfy. Note that alternative solutions are indistinguishable
in ZJ because of the absence of comparison criteria.
Both the ZJ and JMF formulations of the requirements
problem place considerable emphasis on properties which
can be established from qualitative variables alone. With
ZJ, the aim was to design one solution which is consistent
and achieves requirements. With JMF, the aim was to design
several configurations, all of which are consistent and achieve
a threshold (i.e., all mandatory requirements), then proceed to
decision-making, that is, compare configurations in terms of
which preferred and optional requirements they satisfy, then
choose one of them. Now, the aim is to choose roadmaps,
whereby the configurations in a roadmap all are consistent
and achieve requirements (as in ZJ), but also distinguish
mandatory from optional requirements and can be compared
in terms of preference (as in JMF). By satisfying Consistency
and Qualitative threshold achievement, each configuration in a
roadmap satisfies the ZJ conditions. By satisfying Conformity
in addition, every configuration satisfies all properties that
a candidate solution should satisfy in JMF. From there on,
the departures of the configuration, adaptation requirement,
roadmap, and RPAS concepts from ZJ and JMF are:
1) A configuration satisfies Quantitative threshold achieve-
ment, Dominance, and Minimality, in addition to
Consistency, Qualitative threshold achievement, and
Conformity.
2) Decision rules for the ranking of configurations and
of roadmaps can be formulated as an optimization
problem, where the aim is to optimize one or more
quantitative variables. This was not of interest in ZJ,
and was very limited in JMF.
3) There are new kinds of preferences and tradeoffs to
consider. While a configuration may give an optimal
value of a variable in one roadmap, we may prefer
another roadmap, which fails to include that config-
uration, but ensures some suboptimal, but acceptable
value of the variable over several configurations in
the roadmap. Instead of focusing on the desirability
of individual solutions, it is necessary to look at the
desirability of roadmaps.
As the problem of designing, finding, and ranking
roadmaps, RPAS reflects the consequences of adaptation
behavior: a roadmap is a set of configurations, which need
not have a predefined sequence, but adaptation requirements,
while the system needs to be designed so as to be able to
monitor requirements, and satisfy adaptation requirements
by controlling its behavior, whereby it switches between the
highest ranking, yet feasible configurations.
the configuration which immediately precedes it by more
than y requirements.
R4 is a decision rule pattern, where a concrete rule is
obtained by setting x and y to constants. R4 illustrates that
constraints need not be limited on individual configurations,
but also on the structure of the roadmap, as it limits the
number of changes that can be performed, which may reflect
the necessity to conserve resources during adaptations.
It is important to note that the choice of a roadmap
does not impose the sequence of configurations that the
system should follow: adaptive behavior means that, e.g.,
if we adopt rule R4 above, the system will start from the
configuration in which the domain assumptions are consistent
with the conditions in the environment of the system. It will
then adapt according to the satisfaction/failure of monitored
requirements. It may be relevant to dynamically (at runtime)
compute new configurations, the discussion of which we
leave as an open issue.
IV. DEPARTURES FROM PRIOR WORK
The widely accepted general requirements problem def-
inition is Zave & Jackson’s [16] (ZJ hereafter), stating
that RE should produce a specification (S) of a design of
the system-to-be, which ensures that the system-to-be is
consistent with domain assumptions (K) and together with
them entails requirements (R): i.e., that K;S ` R. This
definition emphasizes two properties: (i) consistency, in that
the operationalization of requirements, i.e., K [ S must be
consistent; and (ii) achievement of requirements, as K [ S
are only acceptable if they are sufficient to deduce R.
For an example of ZJ problem and solution, cf., Figure
1(a). Assume that all goals there are the set R0, all domain
assumptions K 0, and all tasks S0. Given R0 and D0 initially,
the ZJ problem says that we should find tasks S S0 which
satisfy a consistent subset D D0 of domain assumptions,
and a consistent subset of requirements R R0. Any one
column among S1, S2, and S3 in Figure 1(c) is a consistent
set of domain assumptions and tasks which satisfy a set of
consistent goals (i.e., 8i; 1 i 3, Si = K [ S), so that
any one of these is a solution to the ZJ requirements problem.
This can be verified by looking at the conflict and conditional
relations in Figures 1(a)–(c).
There is in the ZJ problem formulation no information to
define comparison criteria. We offered a revised definition of
the requirements problem [8] (JMF hereafter), which has a
richer ontology (to account for concepts that have established
themselves in RE, such as, e.g., goals and softgoals), allows
inconsistencies between alternative configurations (each of
which satisfies ZJ conditions), introduces preferences to allow
the comparison of configurations in terms of desirability, and
we argued that logical consequence in early RE is more
adequately described by a nonmonotonic and paraconsistent
consequence relation jv [7] than ` from classical logic. These
revisions make it impossible to synthesize the requirements
problem as K;S ` R, since consistency and achievement
become only a part of the conditions that a solution should
satisfy. Note that alternative solutions are indistinguishable
in ZJ because of the absence of comparison criteria.
Both the ZJ and JMF formulations of the requirements
problem place considerable emphasis on properties which
can be established from qualitative variables alone. With
ZJ, the aim was to design one solution which is consistent
and achieves requirements. With JMF, the aim was to design
several configurations, all of which are consistent and achieve
a threshold (i.e., all mandatory requirements), then proceed to
decision-making, that is, compare configurations in terms of
which preferred and optional requirements they satisfy, then
choose one of them. Now, the aim is to choose roadmaps,
whereby the configurations in a roadmap all are consistent
and achieve requirements (as in ZJ), but also distinguish
mandatory from optional requirements and can be compared
in terms of preference (as in JMF). By satisfying Consistency
and Qualitative threshold achievement, each configuration in a
roadmap satisfies the ZJ conditions. By satisfying Conformity
in addition, every configuration satisfies all properties that
a candidate solution should satisfy in JMF. From there on,
the departures of the configuration, adaptation requirement,
roadmap, and RPAS concepts from ZJ and JMF are:
1) A configuration satisfies Quantitative threshold achieve-
ment, Dominance, and Minimality, in addition to
Consistency, Qualitative threshold achievement, and
Conformity.
2) Decision rules for the ranking of configurations and
of roadmaps can be formulated as an optimization
problem, where the aim is to optimize one or more
quantitative variables. This was not of interest in ZJ,
and was very limited in JMF.
3) There are new kinds of preferences and tradeoffs to
consider. While a configuration may give an optimal
value of a variable in one roadmap, we may prefer
another roadmap, which fails to include that config-
uration, but ensures some suboptimal, but acceptable
value of the variable over several configurations in
the roadmap. Instead of focusing on the desirability
of individual solutions, it is necessary to look at the
desirability of roadmaps.
As the problem of designing, finding, and ranking
roadmaps, RPAS reflects the consequences of adaptation
behavior: a roadmap is a set of configurations, which need
not have a predefined sequence, but adaptation requirements,
while the system needs to be designed so as to be able to
monitor requirements, and satisfy adaptation requirements
by controlling its behavior, whereby it switches between the
highest ranking, yet feasible configurations.
Page 10
V. FORMALIZATION
The aim in this section is to define the modeling language
used throughout the preceding sections, then define additional
tools necessary to present the formal definition of the
configuration concept.
A. Language
The set of requirements L is the union of four disjoint sets
of formulas: simple requirements on propositional variables
LP , simple requirements on quantitative variables LN , simple
softgoals LS , and complex requirements LC .
Every simple requirement on a propositional variable,
i.e., every a 2 LP , satisfies the following BNF specification:
a ::= k(p) j g(p) j t(p) (V.1)
where p is a symbol for a propositional variable. A re-
quirement over a propositional variable can be a domain
assumption (k), a goal (g), or a task (t). The informal reading
of the members of LP is
k(p): it is believed that p is satisfied;
g(p): it is desired that p be satisfied;
t(p): the execution of the task makes p satisfied.
In the readings above, “can be” is replaced by “is” when
the requirement is mandatory (see Complex requirements
below).
Every simple requirement on a quantitative variable,
i.e., every b 2 LN , satisfies this BNF specification:
x ::= n j v j x+ x j x x j x x j x=x j xx (V.2)
y ::= x > x j x < x j x = x j x x
j x x j x 6= x j x v pdf (V.3)
b ::= k(y) j q(y) j t(y) (V.4)
where n is a real number, v is a quantitative variable, and
pdf is a probability density function. The informal reading
is:
k(y): it is believed that the condition y is satisfied;
q(y): it is desired that the condition y be satisfied;
t(y): the execution of the task makes y satisfied.
Again, “can be” is replaced by “is” above, when the
requirement is mandatory.
Simple softgoals are kept outside LP and LN because the
natural language statement in a softgoal (e.g., High usability,
High performance), denoted ~p, refers to some desirable values
of variables in such a way that it is not clear which exact
values, or how the values of these variables can be observed
or measured. Every c 2 LS satisfies:
c ::= s(~p): (V.5)
An ~p is called the content of a softgoal, and is a vague
proposition. By being vague, ~p is neither a propositional
variable, nor a quantitative variable, nor a condition on
quantitative variables. The symbol used is intentionally
different from those inside domain assumptions, goals, quality
constraints, and tasks.
A complex requirement relates simple requirements
and/or softgoals, or is a mandatory or optional requirement.
Every h 2 LC satisfies the BNF specification
d ::= a j b j c (V.6)
e ::=
m1^
i=1
di ! d j
m2^
i=1
di ! ? (V.7)
f ::= k(e) (V.8)
g ::= d j f (V.9)
h ::= f j gM j gO (V.10)
The specification of complex requirements introduces the
convention that every complex requirement that has the
implication connective is a domain assumption, as we assume
that requirements or variables are related in refinement,
conflict, or otherwise. Note that the quantitative refinement
relation is specified as k(y), where y is a condition in which a
quantitative variable is equated to a function over quantitative
variables.
We use lowercase letters of the Greek alphabet to denote
generic requirements, members of L = LP [ LN [ LS [
LC . Uppercase Greek letters denote sets of requirements.
Preferences over simple requirements and softgoals are kept
in the separate set.
The set of preferences P includes all preference relations
over simple requirements and/or softgoals; every w 2 P
satisfies the specification
w ::= d d j d d j d d: (V.11)
Note from this specification that we do not allow preferences
between complex requirements, and we not allow a preference
to be mandatory or optional, to participate in a refinement,
or in a conflict.
Definition V.1. The language is the tuple (P;R; V; ~P ;L;P),
where L the set of requirements which satisfy the BNF
specification in Equations V.1–V.10 and P is the set of
preferences which satisfy the BNF specification in Equation
V.11, whereby the propositional variables in requirements
and preferences come from the set P , numbers from the set
R of real numbers, quantitative variables from V , and vague
propositions from ~P .
Definition V.2. Any L[P is a requirements database.
B. Consequence Relation
We use the Techne consequence relation.
Definition V.3. The consequence relation [7] jv is such
that, for L, 2 L and x 2 f ;?g:
jv if 2 , or
jv x if 81 n, jv i and k(
Vn
i=1 i ! x)
y 2 ,
for y 2 f“empty”; O; Mg.
The aim in this section is to define the modeling language
used throughout the preceding sections, then define additional
tools necessary to present the formal definition of the
configuration concept.
A. Language
The set of requirements L is the union of four disjoint sets
of formulas: simple requirements on propositional variables
LP , simple requirements on quantitative variables LN , simple
softgoals LS , and complex requirements LC .
Every simple requirement on a propositional variable,
i.e., every a 2 LP , satisfies the following BNF specification:
a ::= k(p) j g(p) j t(p) (V.1)
where p is a symbol for a propositional variable. A re-
quirement over a propositional variable can be a domain
assumption (k), a goal (g), or a task (t). The informal reading
of the members of LP is
k(p): it is believed that p is satisfied;
g(p): it is desired that p be satisfied;
t(p): the execution of the task makes p satisfied.
In the readings above, “can be” is replaced by “is” when
the requirement is mandatory (see Complex requirements
below).
Every simple requirement on a quantitative variable,
i.e., every b 2 LN , satisfies this BNF specification:
x ::= n j v j x+ x j x x j x x j x=x j xx (V.2)
y ::= x > x j x < x j x = x j x x
j x x j x 6= x j x v pdf (V.3)
b ::= k(y) j q(y) j t(y) (V.4)
where n is a real number, v is a quantitative variable, and
pdf is a probability density function. The informal reading
is:
k(y): it is believed that the condition y is satisfied;
q(y): it is desired that the condition y be satisfied;
t(y): the execution of the task makes y satisfied.
Again, “can be” is replaced by “is” above, when the
requirement is mandatory.
Simple softgoals are kept outside LP and LN because the
natural language statement in a softgoal (e.g., High usability,
High performance), denoted ~p, refers to some desirable values
of variables in such a way that it is not clear which exact
values, or how the values of these variables can be observed
or measured. Every c 2 LS satisfies:
c ::= s(~p): (V.5)
An ~p is called the content of a softgoal, and is a vague
proposition. By being vague, ~p is neither a propositional
variable, nor a quantitative variable, nor a condition on
quantitative variables. The symbol used is intentionally
different from those inside domain assumptions, goals, quality
constraints, and tasks.
A complex requirement relates simple requirements
and/or softgoals, or is a mandatory or optional requirement.
Every h 2 LC satisfies the BNF specification
d ::= a j b j c (V.6)
e ::=
m1^
i=1
di ! d j
m2^
i=1
di ! ? (V.7)
f ::= k(e) (V.8)
g ::= d j f (V.9)
h ::= f j gM j gO (V.10)
The specification of complex requirements introduces the
convention that every complex requirement that has the
implication connective is a domain assumption, as we assume
that requirements or variables are related in refinement,
conflict, or otherwise. Note that the quantitative refinement
relation is specified as k(y), where y is a condition in which a
quantitative variable is equated to a function over quantitative
variables.
We use lowercase letters of the Greek alphabet to denote
generic requirements, members of L = LP [ LN [ LS [
LC . Uppercase Greek letters denote sets of requirements.
Preferences over simple requirements and softgoals are kept
in the separate set.
The set of preferences P includes all preference relations
over simple requirements and/or softgoals; every w 2 P
satisfies the specification
w ::= d d j d d j d d: (V.11)
Note from this specification that we do not allow preferences
between complex requirements, and we not allow a preference
to be mandatory or optional, to participate in a refinement,
or in a conflict.
Definition V.1. The language is the tuple (P;R; V; ~P ;L;P),
where L the set of requirements which satisfy the BNF
specification in Equations V.1–V.10 and P is the set of
preferences which satisfy the BNF specification in Equation
V.11, whereby the propositional variables in requirements
and preferences come from the set P , numbers from the set
R of real numbers, quantitative variables from V , and vague
propositions from ~P .
Definition V.2. Any L[P is a requirements database.
B. Consequence Relation
We use the Techne consequence relation.
Definition V.3. The consequence relation [7] jv is such
that, for L, 2 L and x 2 f ;?g:
jv if 2 , or
jv x if 81 n, jv i and k(
Vn
i=1 i ! x)
y 2 ,
for y 2 f“empty”; O; Mg.
Page 11
The consequence relation jv is sound with regards to
standard entailment ` in classical propositional logic, but is
incomplete in two ways: it only considers deducing positive
atomic facts, and no ordinary proofs based on arguing by
contradiction go through, thus being paraconsistent.
C. Operationalization Functions
We have two operationalization functions, respectively for
requirements over qualitative and over quantitative variables.
The purpose of an operationalization function is, given a
requirement and a set of requirements X , to return, if
it exists, every set Y X which satisfies the following
conditions. If is a requirement over a qualitative variable,
then Y includes only those domain assumptions and tasks
which are necessary to deduce . If is a requirement over
a quantitative variable, then Y includes only those domain
assumptions and tasks which ensure that the condition in
is satisfied, when all of the variables in that condition
are replaced by the values that they are assigned by the
requirements in Y .
To define operationalization functions, we define below
the Select function and one useful set. We assume that O =
fk; g; q; s; tg and we denote }(X) the powerset of X .
Definition V.4. The select function
Select : O f“empty”; O; Mg }(L) ! }(L) (V.12)
is defined as follows, for x 2 O, y 2 f“empty”; O; Mg, and
L:
Select(x; y;)
def
= f j x( )y 2 g: (V.13)
To simplify notation, we use the following abbreviation:
Select(x; y;) yx: (V.14)
Given a set of expressions, the Select function returns its
subset, in which all members have the labels x 2 O and
y 2 f“empty”; O; Mg.
Definition V.5. Useful set: Let L and x 2 O:
CON() def= f j 6jv ? and
[
8x
Mx g (V.15)
CON() is the set of all consistent subsets of , whereby
every one of these subsets must include all mandatory
requirements from .
The reason why every 2 CON() must include
all mandatory requirements is that we require the set of
mandatory requirments to be consistent and, as we will see
below, to be included in all operationalizations, because an
operationalization must not be inconsistent with mandatory
requirements.
Definition V.6. The qualitative operationalization function
Op :
[
8x;y
yx ! }
0
@}
0
@
[
8z;w
wz
1
A
1
A (V.16)
for y;w 2 f“empty”; O; Mg, x 2 fg; q; sg, and z 2 fk; tg, is
defined as follows:
Op
0
@ 2
[
8x;y
yx
1
A def=f 2 CON() j jv
and n f g
[
8z;w
wz ;
and 6 9 ; jv g: (V.17)
Every member of the set Op( ) is a minimal consistent
set of tasks and domain assumptions that is sufficient to
operationalize the goal, quality constraint, or softgoal .
Informally, Op( ) tells us all ways in (i.e., subsets of) of
satisfying a goal, quality constraint, or softgoal, which are
consistent with all mandatory requirements.
There can be cases when is a requirement over quan-
titative variables and is satisfied, but the function Op finds
no operationalizations thereof. This happens if there are
no qualitative refinements of . We use the quantitative
operationalization function to identify requirements which
satisfy an 2 LN .
Definition V.7. The quantitative operationalization func-
tion
Ov : (LN \) ! }
0
@}
0
@
[
8z;w
wz
1
A
1
A (V.18)
for y;w 2 f“empty”; O; Mg, x 2 fk; q; tg, and z 2 fk; tg.
Let 8i; ni 2 R; vi 2 V , where every vi is a variable
which appears in and there are m such variables in ,
i.e., 1 i m. Ov is defined as follows.
2 Ov
2 LN
if and only if:
1) 2 CON(), i.e., is consistent,
2) fx(vi = ni)y 2 LN j 1 i mg , i.e.,
includes a set of requirements over the m quantitative
variables in ,
3) 81 i m, one or more of the following hold
a) x(vi = ni)y 2
S
8z;w
w
z , i.e., x(vi = ni)
y is
among domain assumptions and tasks in ,
b) 9 2 Ov(x(vi = ni)y) s.t. , i.e., a subset
of is a quantitative operationalization of x(vi =
ni)y,
c) 9 2 Op(x(vi = ni)y) s.t. , i.e., a subset
of is a qualitative operationalization of x(vi =
ni)y,
4) and if we replace every variable vi in with the
constant ni, then the condition in holds.
standard entailment ` in classical propositional logic, but is
incomplete in two ways: it only considers deducing positive
atomic facts, and no ordinary proofs based on arguing by
contradiction go through, thus being paraconsistent.
C. Operationalization Functions
We have two operationalization functions, respectively for
requirements over qualitative and over quantitative variables.
The purpose of an operationalization function is, given a
requirement and a set of requirements X , to return, if
it exists, every set Y X which satisfies the following
conditions. If is a requirement over a qualitative variable,
then Y includes only those domain assumptions and tasks
which are necessary to deduce . If is a requirement over
a quantitative variable, then Y includes only those domain
assumptions and tasks which ensure that the condition in
is satisfied, when all of the variables in that condition
are replaced by the values that they are assigned by the
requirements in Y .
To define operationalization functions, we define below
the Select function and one useful set. We assume that O =
fk; g; q; s; tg and we denote }(X) the powerset of X .
Definition V.4. The select function
Select : O f“empty”; O; Mg }(L) ! }(L) (V.12)
is defined as follows, for x 2 O, y 2 f“empty”; O; Mg, and
L:
Select(x; y;)
def
= f j x( )y 2 g: (V.13)
To simplify notation, we use the following abbreviation:
Select(x; y;) yx: (V.14)
Given a set of expressions, the Select function returns its
subset, in which all members have the labels x 2 O and
y 2 f“empty”; O; Mg.
Definition V.5. Useful set: Let L and x 2 O:
CON() def= f j 6jv ? and
[
8x
Mx g (V.15)
CON() is the set of all consistent subsets of , whereby
every one of these subsets must include all mandatory
requirements from .
The reason why every 2 CON() must include
all mandatory requirements is that we require the set of
mandatory requirments to be consistent and, as we will see
below, to be included in all operationalizations, because an
operationalization must not be inconsistent with mandatory
requirements.
Definition V.6. The qualitative operationalization function
Op :
[
8x;y
yx ! }
0
@}
0
@
[
8z;w
wz
1
A
1
A (V.16)
for y;w 2 f“empty”; O; Mg, x 2 fg; q; sg, and z 2 fk; tg, is
defined as follows:
Op
0
@ 2
[
8x;y
yx
1
A def=f 2 CON() j jv
and n f g
[
8z;w
wz ;
and 6 9 ; jv g: (V.17)
Every member of the set Op( ) is a minimal consistent
set of tasks and domain assumptions that is sufficient to
operationalize the goal, quality constraint, or softgoal .
Informally, Op( ) tells us all ways in (i.e., subsets of) of
satisfying a goal, quality constraint, or softgoal, which are
consistent with all mandatory requirements.
There can be cases when is a requirement over quan-
titative variables and is satisfied, but the function Op finds
no operationalizations thereof. This happens if there are
no qualitative refinements of . We use the quantitative
operationalization function to identify requirements which
satisfy an 2 LN .
Definition V.7. The quantitative operationalization func-
tion
Ov : (LN \) ! }
0
@}
0
@
[
8z;w
wz
1
A
1
A (V.18)
for y;w 2 f“empty”; O; Mg, x 2 fk; q; tg, and z 2 fk; tg.
Let 8i; ni 2 R; vi 2 V , where every vi is a variable
which appears in and there are m such variables in ,
i.e., 1 i m. Ov is defined as follows.
2 Ov
2 LN
if and only if:
1) 2 CON(), i.e., is consistent,
2) fx(vi = ni)y 2 LN j 1 i mg , i.e.,
includes a set of requirements over the m quantitative
variables in ,
3) 81 i m, one or more of the following hold
a) x(vi = ni)y 2
S
8z;w
w
z , i.e., x(vi = ni)
y is
among domain assumptions and tasks in ,
b) 9 2 Ov(x(vi = ni)y) s.t. , i.e., a subset
of is a quantitative operationalization of x(vi =
ni)y,
c) 9 2 Op(x(vi = ni)y) s.t. , i.e., a subset
of is a qualitative operationalization of x(vi =
ni)y,
4) and if we replace every variable vi in with the
constant ni, then the condition in holds.
Page 12
Every member of Ov( ) is a consistent set which includes
all requirements which (i) are operationalized, (ii) assign
values to every quantitative variable v1; : : : ; vm in , and (iii)
assign such constants n1; : : : ; nm to the variables v1; : : : ; vm
that the functional relation specified over these variables in
holds. Ov( ) tells us all combinations of requirements
which assign such constants to all variables in that is
satisfied.
D. Macros
Macros automatically change the requirements database
when it already contains some specific requirements, or when
specific values of quantitative variables are observed. There
are softgoal macros and quantitative conflict macros.
Macros rely on the special monitoring function VAL. Given
a set of requirements X , and a quantitative variable
v, if there are tasks and domain assumptions in X which
assign a value n 2 R to v (e.g., a task such that t(v = n)
where n is a constant), then n 2 VAL(X; v).
Definition V.8. The monitoring function
VAL : }() V ! }(R) (V.19)
is defined as follows, for X , v 2 V , x 2 fk; q; tg, and
y 2 f“empty”; O; Mg:
VAL(X; v) =fn 2 R j 9Y X s.t.
Y 2 Ov(x(v = n)y) [Op(x(v = n)y)g
(V.20)
VAL(X; v) is a set of all constants that are assigned through
qualitative or quantitative operationalizations in X to v.
The quantitative conflict macro applies to any quan-
titative variable v for which VAL(; v) 6= ;. As long as
jVAL(; v)j 2, the macro adds a conflict relation between
every pair of assignments of different values to v. E.g., if
VAL(; v) = f3; 7g, this means that there is at least one
operationalization which assigns the constant 3 to v, and at
least one other operationalization which assigns the constant
7 to v. The macro will add two quality constraints, q(v = 3)
and q(v = 7) to , and will add the mandatory conflict
k(q(v = 3) ^ q(v = 7)! ?)M.
Definition V.9. For every quantitative variable v 2 V such
that VAL(; v) 6= ;, there is the following quantitative
conflict macro:
k( IF jVAL(; v)j 2 THEN 8x1; x2 2 VAL(; v) ADD
fq(v = x1);q(v = x2);
k(q(v = x1) ^ q(v = x2)! ?)Mg
TO ; ).
The purpose of the quantitative conflict macro is to ensure
that no quantitative variable obtains two different assignments
in one configuration.
The softgoal macro applies to any quantitative variable
v for which VAL(; v) 6= ; and for which there is a
satisfaction function (v). This is the case when there is
in an operationalization of a requirement which assigns
a value to v and a domain assumption which defines a
variable v0 as the output of the satisfaction function on v,
i.e., 9k(v0 = (v)) 2 . The softgoal macro automatically
adds preference relations between sets of requirements
which operationalize requirements that assign constants to
v, whereby the preferences are defined to reflect the values
returned by .
Definition V.10. For every quantitative variable v 2 V such
that VAL(; v) 6= ; and 9k(v0 = (v)) 2 , where is
informally interpreted as a satisfaction function, there is the
following softgoal macro:
s( 8x1; x2 2 VAL(; v)
IF (x1) = (x2) THEN ADD
fk(v = x1); k(v = x2),
k(v = x1) k(v = x2)g
TO ;
IF (x1) > (x2) THEN ADD
fk(v = x1); k(v = x2);
k(k(v = x1) ^ k(v = x2)! ?);
k(v = x1) k(v = x2)g
TO ; ).
Two remarks are in order. Firstly, note that the preferences
are added to reflect the values not of v but of the satisfaction
level (v) on v. When the satisfaction levels are different (the
second case in the softgoal macro), then a conflict relation
is introduced as well, which will ensure that a configuration
does not satisfy two assignments of different constants x1 and
x2 to v whereby these different assignments are not equally
preferred (i.e., (x1) 6= (x2)). Secondly, note the difference
between the definition of the softgoal macro above, and the
macro we used earlier (cf., xIII-D2): there, the macro was
simpler because if made two assumptions which we do not
make above, namely, (i) we assumed that we already knew the
configurations, and (ii) we assumed that each configuration
was such that the variable v was assigned exactly one constant
in each of the configurations.
E. Configuration Concept
Definition V.11. A configuration S, defined from the re-
quirements database , is a set
S
[
8x;y
yx; for x 2 fk; tg; y 2 f“empty”; O; Mg (V.21)
of domain assumptions and tasks, which satisfies the follow-
ing properties:
1) Consistency: S 6jv ?;
2) Qualitative threshold achievement:
8 2 Mz, z 2 fg; sg, 9 2 Op( ) such that S;
3) Quantitative threshold achievement:
8 2 Mq, 9 2 Ov( ) such that S;
4) Conformity: Mk [
M
t S;
all requirements which (i) are operationalized, (ii) assign
values to every quantitative variable v1; : : : ; vm in , and (iii)
assign such constants n1; : : : ; nm to the variables v1; : : : ; vm
that the functional relation specified over these variables in
holds. Ov( ) tells us all combinations of requirements
which assign such constants to all variables in that is
satisfied.
D. Macros
Macros automatically change the requirements database
when it already contains some specific requirements, or when
specific values of quantitative variables are observed. There
are softgoal macros and quantitative conflict macros.
Macros rely on the special monitoring function VAL. Given
a set of requirements X , and a quantitative variable
v, if there are tasks and domain assumptions in X which
assign a value n 2 R to v (e.g., a task such that t(v = n)
where n is a constant), then n 2 VAL(X; v).
Definition V.8. The monitoring function
VAL : }() V ! }(R) (V.19)
is defined as follows, for X , v 2 V , x 2 fk; q; tg, and
y 2 f“empty”; O; Mg:
VAL(X; v) =fn 2 R j 9Y X s.t.
Y 2 Ov(x(v = n)y) [Op(x(v = n)y)g
(V.20)
VAL(X; v) is a set of all constants that are assigned through
qualitative or quantitative operationalizations in X to v.
The quantitative conflict macro applies to any quan-
titative variable v for which VAL(; v) 6= ;. As long as
jVAL(; v)j 2, the macro adds a conflict relation between
every pair of assignments of different values to v. E.g., if
VAL(; v) = f3; 7g, this means that there is at least one
operationalization which assigns the constant 3 to v, and at
least one other operationalization which assigns the constant
7 to v. The macro will add two quality constraints, q(v = 3)
and q(v = 7) to , and will add the mandatory conflict
k(q(v = 3) ^ q(v = 7)! ?)M.
Definition V.9. For every quantitative variable v 2 V such
that VAL(; v) 6= ;, there is the following quantitative
conflict macro:
k( IF jVAL(; v)j 2 THEN 8x1; x2 2 VAL(; v) ADD
fq(v = x1);q(v = x2);
k(q(v = x1) ^ q(v = x2)! ?)Mg
TO ; ).
The purpose of the quantitative conflict macro is to ensure
that no quantitative variable obtains two different assignments
in one configuration.
The softgoal macro applies to any quantitative variable
v for which VAL(; v) 6= ; and for which there is a
satisfaction function (v). This is the case when there is
in an operationalization of a requirement which assigns
a value to v and a domain assumption which defines a
variable v0 as the output of the satisfaction function on v,
i.e., 9k(v0 = (v)) 2 . The softgoal macro automatically
adds preference relations between sets of requirements
which operationalize requirements that assign constants to
v, whereby the preferences are defined to reflect the values
returned by .
Definition V.10. For every quantitative variable v 2 V such
that VAL(; v) 6= ; and 9k(v0 = (v)) 2 , where is
informally interpreted as a satisfaction function, there is the
following softgoal macro:
s( 8x1; x2 2 VAL(; v)
IF (x1) = (x2) THEN ADD
fk(v = x1); k(v = x2),
k(v = x1) k(v = x2)g
TO ;
IF (x1) > (x2) THEN ADD
fk(v = x1); k(v = x2);
k(k(v = x1) ^ k(v = x2)! ?);
k(v = x1) k(v = x2)g
TO ; ).
Two remarks are in order. Firstly, note that the preferences
are added to reflect the values not of v but of the satisfaction
level (v) on v. When the satisfaction levels are different (the
second case in the softgoal macro), then a conflict relation
is introduced as well, which will ensure that a configuration
does not satisfy two assignments of different constants x1 and
x2 to v whereby these different assignments are not equally
preferred (i.e., (x1) 6= (x2)). Secondly, note the difference
between the definition of the softgoal macro above, and the
macro we used earlier (cf., xIII-D2): there, the macro was
simpler because if made two assumptions which we do not
make above, namely, (i) we assumed that we already knew the
configurations, and (ii) we assumed that each configuration
was such that the variable v was assigned exactly one constant
in each of the configurations.
E. Configuration Concept
Definition V.11. A configuration S, defined from the re-
quirements database , is a set
S
[
8x;y
yx; for x 2 fk; tg; y 2 f“empty”; O; Mg (V.21)
of domain assumptions and tasks, which satisfies the follow-
ing properties:
1) Consistency: S 6jv ?;
2) Qualitative threshold achievement:
8 2 Mz, z 2 fg; sg, 9 2 Op( ) such that S;
3) Quantitative threshold achievement:
8 2 Mq, 9 2 Ov( ) such that S;
4) Conformity: Mk [
M
t S;
Page 13
5) Dominance: 6 9S0 s.t. both S and S0 satisfy conditions
1–4 above, S S0, and 9Ox = S
0 n S, s.t. Ox 6= ;
and x 2 fk; tg;
6) Minimality: 6 9S0 such that S0 satisfies the conditions
1–5 above and S0 S.
The Threshold achievement property requires that a
configuration satisfies all mandatory goals, quality constraints,
and softgoals. Satisfaction depends on the presence of
operationalizations in S, for each of the mandatory goals,
quality constraints, and softgoals.
The Conformity property asks that all strict domain
assumptions are not violated and all mandatory tasks are
executed. The Achievement and Conformity properties ensure
that the configuration satisfies all that must be satisfied.
According to the Dominance property, every configuration
will be maximal with regards to optional requirements. This
property formalizes the idea of the optional relation, as
holding on requirements which are desirable to satisfy, but
can be violated. A configuration should include as many
defeasible domain assumptions and as many optional tasks,
up to the point at which adding any further defeasible domain
assumptions and/or optional tasks violates the Consistency,
Qualitative and Quantitative threshold achievement, Confor-
mity, or Minimality properties. The Dominance condition
ensures that every configuration is Pareto efficient with
regards to optional requirements, as this condition makes it
impossible to add optional domain assumptions and tasks to
any S and still ensure that S is a configuration.
The Minimality property requires that a configuration
includes only the domain assumptions and tasks which
are needed to satisfy exactly the Consistency, Threshold
achievement, Conformity, and Dominance properties.
F. Related Work & Discussion
We have illustrated throughout the paper how the contri-
butions here depart from prior efforts in the understanding
of the requirements problem and solution concepts. The
roadmap concept is inspired by our discussion of the role of
contexts, time, and resources in the requirements problem for
adaptive systems [10]. We have used Techne [7] here as a
starting point and extended its syntax to allow requirements
which place constraints on quantitative variables. This has
resulted in a more general treatment of operationalization, as
we have both qualitative operationalization and quantitative
operationalization functions. As in the case of Techne, the
formalism here does not provide a visual syntax, and is
thus not itself a model language for early requirements
in the same sense that, e.g., KAOS goal models [4] and
i* actor models [15] are. In this sense, same remarks
apply as those that we had made when comparing Techne
to KAOS, Tropos, and i*. Two limitations of Techne are
overcome here. Firstly, we can make explicit the constraints
on quantitative variables. Secondly, Techne was informally
criticized that it is blind to the distinction between stable facts
and defeasible information: this is not the case, as optional
domain assumptions here behave like defeasible information,
while mandatory domain assumptions act like stable facts.
In the rest of this section, we look at how the language
presented in this paper can be used to model information
that was recognized as crucial in the research into the
relaxation of requirements [9], [14], [2], the evaluation of
their partial satisfaction [9], and the monitoring and control
of requirements [5], [12]. The aim is not to suggest the
language here as a general modeling language, but to show
that it covers the main ideas presented in relation to the said
topics.
Fuzzy Relaxation. Baresi et al. associate every fuzzy
operator with a predefined membership function. For example,
if there is a quality constraint q(v < 6hrs) here (a goal
G(v < 6hrs) for them, as they allow quantitative variables
in goals), then relaxing it would amount to replace it with
q(v <f 6hrs) (in their notation, G(v <f 6hrs)), where f
is a fuzzy operator. Their interpretation of v <f 6hrs is
that there is a fuzzy membership function which returns
the level of satisfaction as a function of v, and the shape
of is predefined (for <f , it is positive and constant until
v = 6, then decreases up to the satisfaction value 0 for some
v > 6). The operator <f can be defined in our language
by reproducing, in a domain assumption a function which
has the form of the fuzzy membership function for <f , as
defined by Baresi et al. We can define as follows a macro
which takes a fuzzy goal of the form G(v <f n), with n 2 R,
and transforms it into requirements that can be added to our
requirements database :
8G(v <f n) WHERE v 2 V AND n 2 R
ADD fk(v0 = (v))g TO , AND APPLY THE
SOFTGOAL MACRO ON and v,
where v0 is a quantitative variable, i.e., v 2 V , and is a
function which is defined according to the function pattern
defined by Baresi et al. for the fuzzy operator <f . It is
straightforward to define similar macros for all other fuzzy
operators defined by Baresi et al.
Baresi et al. also define binary connectives, such as fuzzy
conjunction. These can be defined here as well, as functions
of those variables, which are defined using fuzzy membership
functions. Each binary fuzzy operator gives one function
specified in a domain assumption and using an approximation
relation. In the formalism from Baresi et al., one way to define
fuzzy conjunction ^f between two variables v1 and v2, each
of which has an accompanying fuzzy membership function
(v1) and (v2), is as follows: (v1 ^f v2) = (v1) (v2).
In our language, (v1) and (v2) give satisfaction levels. The
fuzzy conjunction connective between two quality constraints,
respectively over variables v1 and v2 is introduced in as
the domain assumption k(v3 = (v1) (v2)), where v3 is
the joint level of satisfaction over variables v1 and v2.
Probabilistic Relaxation. To handle idealistic requirements,
1–4 above, S S0, and 9Ox = S
0 n S, s.t. Ox 6= ;
and x 2 fk; tg;
6) Minimality: 6 9S0 such that S0 satisfies the conditions
1–5 above and S0 S.
The Threshold achievement property requires that a
configuration satisfies all mandatory goals, quality constraints,
and softgoals. Satisfaction depends on the presence of
operationalizations in S, for each of the mandatory goals,
quality constraints, and softgoals.
The Conformity property asks that all strict domain
assumptions are not violated and all mandatory tasks are
executed. The Achievement and Conformity properties ensure
that the configuration satisfies all that must be satisfied.
According to the Dominance property, every configuration
will be maximal with regards to optional requirements. This
property formalizes the idea of the optional relation, as
holding on requirements which are desirable to satisfy, but
can be violated. A configuration should include as many
defeasible domain assumptions and as many optional tasks,
up to the point at which adding any further defeasible domain
assumptions and/or optional tasks violates the Consistency,
Qualitative and Quantitative threshold achievement, Confor-
mity, or Minimality properties. The Dominance condition
ensures that every configuration is Pareto efficient with
regards to optional requirements, as this condition makes it
impossible to add optional domain assumptions and tasks to
any S and still ensure that S is a configuration.
The Minimality property requires that a configuration
includes only the domain assumptions and tasks which
are needed to satisfy exactly the Consistency, Threshold
achievement, Conformity, and Dominance properties.
F. Related Work & Discussion
We have illustrated throughout the paper how the contri-
butions here depart from prior efforts in the understanding
of the requirements problem and solution concepts. The
roadmap concept is inspired by our discussion of the role of
contexts, time, and resources in the requirements problem for
adaptive systems [10]. We have used Techne [7] here as a
starting point and extended its syntax to allow requirements
which place constraints on quantitative variables. This has
resulted in a more general treatment of operationalization, as
we have both qualitative operationalization and quantitative
operationalization functions. As in the case of Techne, the
formalism here does not provide a visual syntax, and is
thus not itself a model language for early requirements
in the same sense that, e.g., KAOS goal models [4] and
i* actor models [15] are. In this sense, same remarks
apply as those that we had made when comparing Techne
to KAOS, Tropos, and i*. Two limitations of Techne are
overcome here. Firstly, we can make explicit the constraints
on quantitative variables. Secondly, Techne was informally
criticized that it is blind to the distinction between stable facts
and defeasible information: this is not the case, as optional
domain assumptions here behave like defeasible information,
while mandatory domain assumptions act like stable facts.
In the rest of this section, we look at how the language
presented in this paper can be used to model information
that was recognized as crucial in the research into the
relaxation of requirements [9], [14], [2], the evaluation of
their partial satisfaction [9], and the monitoring and control
of requirements [5], [12]. The aim is not to suggest the
language here as a general modeling language, but to show
that it covers the main ideas presented in relation to the said
topics.
Fuzzy Relaxation. Baresi et al. associate every fuzzy
operator with a predefined membership function. For example,
if there is a quality constraint q(v < 6hrs) here (a goal
G(v < 6hrs) for them, as they allow quantitative variables
in goals), then relaxing it would amount to replace it with
q(v <f 6hrs) (in their notation, G(v <f 6hrs)), where f
is a fuzzy operator. Their interpretation of v <f 6hrs is
that there is a fuzzy membership function which returns
the level of satisfaction as a function of v, and the shape
of is predefined (for <f , it is positive and constant until
v = 6, then decreases up to the satisfaction value 0 for some
v > 6). The operator <f can be defined in our language
by reproducing, in a domain assumption a function which
has the form of the fuzzy membership function for <f , as
defined by Baresi et al. We can define as follows a macro
which takes a fuzzy goal of the form G(v <f n), with n 2 R,
and transforms it into requirements that can be added to our
requirements database :
8G(v <f n) WHERE v 2 V AND n 2 R
ADD fk(v0 = (v))g TO , AND APPLY THE
SOFTGOAL MACRO ON and v,
where v0 is a quantitative variable, i.e., v 2 V , and is a
function which is defined according to the function pattern
defined by Baresi et al. for the fuzzy operator <f . It is
straightforward to define similar macros for all other fuzzy
operators defined by Baresi et al.
Baresi et al. also define binary connectives, such as fuzzy
conjunction. These can be defined here as well, as functions
of those variables, which are defined using fuzzy membership
functions. Each binary fuzzy operator gives one function
specified in a domain assumption and using an approximation
relation. In the formalism from Baresi et al., one way to define
fuzzy conjunction ^f between two variables v1 and v2, each
of which has an accompanying fuzzy membership function
(v1) and (v2), is as follows: (v1 ^f v2) = (v1) (v2).
In our language, (v1) and (v2) give satisfaction levels. The
fuzzy conjunction connective between two quality constraints,
respectively over variables v1 and v2 is introduced in as
the domain assumption k(v3 = (v1) (v2)), where v3 is
the joint level of satisfaction over variables v1 and v2.
Probabilistic Relaxation. To handle idealistic requirements,
Page 14
Letier & van Lamsweerde [9] suggest the association of
probability estimates to constraints on quantitative variables.
This is what we allow in the language, and this has been
illustrated earlier (cf., xIII-D1).
Monitoring & Control Variables. It is on the basis of
the ontology for requirements that we identify controlled
variables: if a variable appears in a task, it is a controlled
variable. Any variable can be monitored, but all variables in
goals, quality constraints, and domain assumptions need to
be monitored.
Adaptation Rules, or equivalently, reconciliation tactics
[5], adaptive goals [2], adaptivity mechanisms [13]. We have
not discussed how they ought to be specified or actually
implemented, but we have suggested how they can be
identified. The roadmap adopted for a system gives a set
of configurations. It consequently indicates what changes
between two configurations, i.e., which requirements are
dropped, which become optional, which others become
mandatory, and so on. Differences between every two
consecutive configurations in the roadmap specify the effect
that adaptation rules should have, regardless of how they are
specified or implemented.
Limitations. While it may be possible to specify time
and temporal constraints by having a quantitative variable,
the values of which are defined by a clock and to map
every configuration to a temporal interval, this would clearly
not be to a convenient way to model temporal constraints
on roadmaps. More appropriate in this respect may be
requirements modeling languages built on top of linear
temporal logic [4] or branching temporal logic [14]. It is,
however, not clear at all how requirements models built
with such languages relate to roadmaps, that is, are these
requirements models describing constraints on a single
configuration, or on parts of roadmaps. Techne has already
been criticized for ignoring the notion of agent, and the fact
that requirements belong to individuals which may thus be
modeled as agents. We continue to ignore them here, mainly
because they can be introduced in a straightforward manner,
yet would complicate notation and presentation, without
adding much to the main purpose of this paper. To add agents,
consider first why they need to be added. If the aim is to
help figure out who needs to negotiate requirements conflicts,
then assume there is a set of identifiers for agents, and add a
function which returns, for every requirement, one or more
agents who agree on it. If the aim is to assign responsibilities
of tasks to agents, then assume a set of identifiers for these
agents, and define a function which maps every task to one
or more agents responsible for its execution. Either of the
two uses of agents has no influence on the structure of the
roadmap problem, other than suggesting that RE does involve
negotiation and the assignment of responsibilities.
VI. CONCLUSIONS, LIMITATIONS & OPEN ISSUES
We have presented two results. Firstly, by defining the
configuration, adaptation requirement, and roadmap concepts,
we have suggested a precise definition of the requirements
problem for adaptive systems. We have related these concepts
to the key notions from RE of adaptive systems, namely,
monitoring, control, adaptation requirements, probabilistic
and fuzzy relaxation. This led us to argue that there are
fundamental differences between Zave & Jackson’s and our
conceptions of the requirements problem, and the require-
ments problem for adaptive systems, its solution concepts,
and the decision rules used to rank solutions. Secondly, we
have used a simple modeling framework throughout the paper,
based on Techne, and which serves as a proto-framework,
being an illustration of features needed in future requirements
modeling languages for early RE of adaptive systems.
In addition to limitations, there is a number of interesting
open issues. The shift to configurations and roadmaps
suggests that research into extended planning and single-
and multi-objective optimization may be a source for further
advances in RE frameworks and tool support. It is necessary
to look into how the roadmap requirements problem relates
to mixed-integer programming, and mixed-variable program-
ming, how to make adaptation rules on the basis of roadmaps,
what decision rules may be relevant for decision-making in
RE. Work is needed on the integration of probabilistic and
fuzzy relaxation, monitoring and control within practical
modeling languages, for early and late requirements phases.
This paper will hopefully inform these future efforts.
REFERENCES
[1] Anonymous. Report of the Inquiry Into The London Am-
bulance Service. Technical report, The Communications
Directorate, South West Thames Regional Authority, 1993.
[2] L. Baresi, L. Pasquale, and P. Spoletini. Fuzzy Goals for
Requirements-driven Adaptation. In IEEE Int. Req. Eng. Conf.,
2010.
[3] B. H. C. Cheng, R. de Lemos, H. Giese, P. Inverardi, and
J. Magee, editors. Software Engineering for Self-Adaptive
Systems [outcome of a Dagstuhl Seminar], volume 5525 of
Lecture Notes in Computer Science. Springer, 2009.
[4] A. Dardenne, A. van Lamsweerde, and S. Fickas. Goal-
directed requirements acquisition. Sci. Comput. Program.,
20(1-2):3–50, 1993.
[5] M. S. Feather, S. Fickas, A. Van Lamsweerde, and C. Ponsard.
Reconciling system requirements and runtime behavior. In
IWSSD, page 50, Washington, DC, USA, 1998. IEEE Com-
puter Society.
[6] S. Fickas and M. S. Feather. Requirements monitoring in
dynamic environments. In IEEE Int. Req. Eng. Conf., pages
140–147. IEEE Computer Society, 1995.
probability estimates to constraints on quantitative variables.
This is what we allow in the language, and this has been
illustrated earlier (cf., xIII-D1).
Monitoring & Control Variables. It is on the basis of
the ontology for requirements that we identify controlled
variables: if a variable appears in a task, it is a controlled
variable. Any variable can be monitored, but all variables in
goals, quality constraints, and domain assumptions need to
be monitored.
Adaptation Rules, or equivalently, reconciliation tactics
[5], adaptive goals [2], adaptivity mechanisms [13]. We have
not discussed how they ought to be specified or actually
implemented, but we have suggested how they can be
identified. The roadmap adopted for a system gives a set
of configurations. It consequently indicates what changes
between two configurations, i.e., which requirements are
dropped, which become optional, which others become
mandatory, and so on. Differences between every two
consecutive configurations in the roadmap specify the effect
that adaptation rules should have, regardless of how they are
specified or implemented.
Limitations. While it may be possible to specify time
and temporal constraints by having a quantitative variable,
the values of which are defined by a clock and to map
every configuration to a temporal interval, this would clearly
not be to a convenient way to model temporal constraints
on roadmaps. More appropriate in this respect may be
requirements modeling languages built on top of linear
temporal logic [4] or branching temporal logic [14]. It is,
however, not clear at all how requirements models built
with such languages relate to roadmaps, that is, are these
requirements models describing constraints on a single
configuration, or on parts of roadmaps. Techne has already
been criticized for ignoring the notion of agent, and the fact
that requirements belong to individuals which may thus be
modeled as agents. We continue to ignore them here, mainly
because they can be introduced in a straightforward manner,
yet would complicate notation and presentation, without
adding much to the main purpose of this paper. To add agents,
consider first why they need to be added. If the aim is to
help figure out who needs to negotiate requirements conflicts,
then assume there is a set of identifiers for agents, and add a
function which returns, for every requirement, one or more
agents who agree on it. If the aim is to assign responsibilities
of tasks to agents, then assume a set of identifiers for these
agents, and define a function which maps every task to one
or more agents responsible for its execution. Either of the
two uses of agents has no influence on the structure of the
roadmap problem, other than suggesting that RE does involve
negotiation and the assignment of responsibilities.
VI. CONCLUSIONS, LIMITATIONS & OPEN ISSUES
We have presented two results. Firstly, by defining the
configuration, adaptation requirement, and roadmap concepts,
we have suggested a precise definition of the requirements
problem for adaptive systems. We have related these concepts
to the key notions from RE of adaptive systems, namely,
monitoring, control, adaptation requirements, probabilistic
and fuzzy relaxation. This led us to argue that there are
fundamental differences between Zave & Jackson’s and our
conceptions of the requirements problem, and the require-
ments problem for adaptive systems, its solution concepts,
and the decision rules used to rank solutions. Secondly, we
have used a simple modeling framework throughout the paper,
based on Techne, and which serves as a proto-framework,
being an illustration of features needed in future requirements
modeling languages for early RE of adaptive systems.
In addition to limitations, there is a number of interesting
open issues. The shift to configurations and roadmaps
suggests that research into extended planning and single-
and multi-objective optimization may be a source for further
advances in RE frameworks and tool support. It is necessary
to look into how the roadmap requirements problem relates
to mixed-integer programming, and mixed-variable program-
ming, how to make adaptation rules on the basis of roadmaps,
what decision rules may be relevant for decision-making in
RE. Work is needed on the integration of probabilistic and
fuzzy relaxation, monitoring and control within practical
modeling languages, for early and late requirements phases.
This paper will hopefully inform these future efforts.
REFERENCES
[1] Anonymous. Report of the Inquiry Into The London Am-
bulance Service. Technical report, The Communications
Directorate, South West Thames Regional Authority, 1993.
[2] L. Baresi, L. Pasquale, and P. Spoletini. Fuzzy Goals for
Requirements-driven Adaptation. In IEEE Int. Req. Eng. Conf.,
2010.
[3] B. H. C. Cheng, R. de Lemos, H. Giese, P. Inverardi, and
J. Magee, editors. Software Engineering for Self-Adaptive
Systems [outcome of a Dagstuhl Seminar], volume 5525 of
Lecture Notes in Computer Science. Springer, 2009.
[4] A. Dardenne, A. van Lamsweerde, and S. Fickas. Goal-
directed requirements acquisition. Sci. Comput. Program.,
20(1-2):3–50, 1993.
[5] M. S. Feather, S. Fickas, A. Van Lamsweerde, and C. Ponsard.
Reconciling system requirements and runtime behavior. In
IWSSD, page 50, Washington, DC, USA, 1998. IEEE Com-
puter Society.
[6] S. Fickas and M. S. Feather. Requirements monitoring in
dynamic environments. In IEEE Int. Req. Eng. Conf., pages
140–147. IEEE Computer Society, 1995.
Page 15
[7] I. J. Jureta, A. Borgida, N. A. Ernst, and J. Mylopoulos.
Techne: Towards a New Generation of Requirements Mod-
eling Languages with Goals, Preferences, and Inconsistency
Handling. In IEEE Int. Req. Eng. Conf., 2010.
[8] I. J. Jureta, J. Mylopoulos, and S. Faulkner. Revisiting the
core ontology and problem in requirements engineering. In
IEEE Int. Req. Eng. Conf., 2008.
[9] E. Letier and A. van Lamsweerde. Reasoning about partial
goal satisfaction for requirements and design engineering. In
SIGSOFT FSE, pages 53–62, 2004.
[10] N. A. Qureshi, I. J. Jureta, and A. Perini. Requirements
Engineering for Self-Adaptive Systems: Core Ontology and
Problem Statement. In Accepted for CAiSE, 2011.
[11] W. N. Robinson. A requirements monitoring framework for
enterprise systems. Requir. Eng., 11(1):17–41, 2006.
[12] W. N. Robinson. Extended OCL for Goal Monitoring.
ECEASST, 9, 2008.
[13] V. E. S. Souza, A. Lapouchnian, W. N. Robinson, and
J. Mylopoulos. Awareness Requirements for Adaptive Systems.
Technical report, DISI, University of Trento, 2010.
[14] J. Whittle, P. Sawyer, N. Bencomo, B. H. C. Cheng, and J.-M.
Bruel. RELAX: a language to address uncertainty in self-
adaptive systems requirements. Requir. Eng., 15(2):177–196,
2010.
[15] E. S. K. Yu and J. Mylopoulos. Understanding ”Why” in
Software Process Modelling, Analysis, and Design. In Proc.
16th Int. Conf. Software Eng., pages 159–168, 1994.
[16] P. Zave and M. Jackson. Four dark corners of requirements
engineering. ACM T. Softw. Eng. Methodol., 6(1):1–30, 1997.
Techne: Towards a New Generation of Requirements Mod-
eling Languages with Goals, Preferences, and Inconsistency
Handling. In IEEE Int. Req. Eng. Conf., 2010.
[8] I. J. Jureta, J. Mylopoulos, and S. Faulkner. Revisiting the
core ontology and problem in requirements engineering. In
IEEE Int. Req. Eng. Conf., 2008.
[9] E. Letier and A. van Lamsweerde. Reasoning about partial
goal satisfaction for requirements and design engineering. In
SIGSOFT FSE, pages 53–62, 2004.
[10] N. A. Qureshi, I. J. Jureta, and A. Perini. Requirements
Engineering for Self-Adaptive Systems: Core Ontology and
Problem Statement. In Accepted for CAiSE, 2011.
[11] W. N. Robinson. A requirements monitoring framework for
enterprise systems. Requir. Eng., 11(1):17–41, 2006.
[12] W. N. Robinson. Extended OCL for Goal Monitoring.
ECEASST, 9, 2008.
[13] V. E. S. Souza, A. Lapouchnian, W. N. Robinson, and
J. Mylopoulos. Awareness Requirements for Adaptive Systems.
Technical report, DISI, University of Trento, 2010.
[14] J. Whittle, P. Sawyer, N. Bencomo, B. H. C. Cheng, and J.-M.
Bruel. RELAX: a language to address uncertainty in self-
adaptive systems requirements. Requir. Eng., 15(2):177–196,
2010.
[15] E. S. K. Yu and J. Mylopoulos. Understanding ”Why” in
Software Process Modelling, Analysis, and Design. In Proc.
16th Int. Conf. Software Eng., pages 159–168, 1994.
[16] P. Zave and M. Jackson. Four dark corners of requirements
engineering. ACM T. Softw. Eng. Methodol., 6(1):1–30, 1997.
Sign up today - FREE
Mendeley saves you time finding and organizing research. Learn more
- All your research in one place
- Add and import papers easily
- Access it anywhere, anytime
Start using Mendeley in seconds!
Readership Statistics
22 Readers on Mendeley
by Discipline
5% Education
by Academic Status
73% Ph.D. Student
9% Student (Master)
5% Lecturer
by Country
18% United States
14% Canada
14% Germany