Information Technology Reference
In-Depth Information
over requirements, that they are interested in choosing among candidate solutions to
the requirements problem, that potentially many candidate solutions exist (as in the
case of service-/agent-oriented systems, where different services/agents may compete
in offering the same functions), and that requirements are not fixed, but change with
new information from the stakeholders or the operational environment. In absence of
preferences, it is (i) not clear how candidate solutions to the requirements problem can
be compared, (ii) what criteria (should) serve for comparison, and (iii) how these criteria
are represented in requirements models.
Techne [8], an abstract requirements modeling language was recently introduced as
a starting point for the development of new requirements modeling languages that can
be used to represent information and perform reasoning needed to solve the require-
ments problem. Techne is abstract in that it assumes no particular visual syntax (e.g.,
diagrammatic notation such as present in Tropos [14]), and it includes only the min-
imum concepts and relations needed to formalize the requirements problem and the
properties of its solutions. Techne is a convenient formalism for the formulation of the
runtime requirements adaptation problem, as it is adapted to the concepts, such as goal,
task, domain assumption, and relations (e.g. Consequence, Preference, Is-mandatory, Is-
optional) that remain relevant for the RE of SAS. To keep the discussion simple in this
paper, we assume that requirements and other information is available in propositional
form, so that every proposition is nothing but a natural language sentence. We overview
below the requirements problem formulation using parts of Techne that we need in the
rest of the paper. In [15], we provide definitions of the consequence relation
|
τ
used in
the definition of the candidate solution below.
Definition 1.
Requirements problem: Given
the elicited or otherwise acquired: do-
main assumptions (in the set
K
),tasks in
T
,goals in
G
, quality constraints in
Q
, softgoals
in
S
, and preference, is-mandatory and is-optional relations in
A
,
find
all
candidate so-
lutions
to the requirements problem and compare them using preference and is-optional
relations from
A
to identify the most desirable candidate solution.
Definition 2.
Candidate solution:
Asetoftasks
T
∗
and a set of domain assumptions
K
∗
are a
candidate solution
to the requirements problem if and only if:
1.
K
∗
and
T
∗
are not inconsistent,
2.
K
∗
,
T
∗
|
τ
G
∗
,
Q
∗
,where
G
∗
⊆
G
and
Q
∗
⊆
Q
,
3.
G
∗
and
Q
∗
include, respectively, all mandatory goals and quality constraints, and
4. all mandatory softgoals are approximated by the consequences of
K
∗
∪
T
∗
, so that
K
∗
,
T
∗
|
τ
S
M
,where
S
M
is the set of mandatory softgoals.
We start below from the CORE ontology and problem formulation in Techne, and add
concepts specific to the RE for SAS, which leads us to an ontology for requirements
in SAS and the formulation of the
requirements problem in context
for SAS. We sub-
sequently show how to formulate the
runtime requirements adaptation problem
as a
dynamic RE problem of changing (e.g. switching, re-configuring, optimizing) the SAS
from one requirements problem to another requirements problem, whereby the chang-
ing is due to change in requirements, context conditions, and/or resource availability.
