Dealing with Known Unknowns: Towards a Game-Theoretic Foundation for Software Requirement Evolution - Advanced Information Systems Engineering - page 64

In our work, we define the satisfaction relationship in terms of usefulness.
That an element set X is useful to another element set Y depends on the ability
to satisfy (or fulfill) Y if X is satisfied. We define a predicate useful(X, Y) which is
true (1) if X can satisfy all elements of Y, otherwise false (0). The implementation
of useful depends on the specific requirement model. For examples:

- Goal models [20]: useful corresponds to Decomposition and Means-end re-
lationships. The former denotes a goal can be achieved by satisfying its
subgoals. The later refers to achieving an (end) goal by doing (means) tasks.
- Problem frames [13]: useful corresponds to requirement references and domain
interfaces relationships. Requirements are imposed by machines, which con-
nect to problem world via domain interfaces . Problem world in turn connects
to requirements via requirement references .

For evolutionary software systems which may evolve under some circumstances
( e.g., changes in requirements due to changes in business agreements, regula-
tions, or domain assumption), their requirement models should be able to ex-
press as much as possible the information about known unknowns i.e. potential
changes. These potential changes are analyzed by evolution assessment algo-
rithms to contribute to the decision making process, where a designer decides
what would be in the next phase of the development process.
Based on the actor who can decide which evolution would happen, we cate-
gorize requirement evolutions into two classes:

- controllable evolution is under control of designer to meet high level require-
ments from stakeholder.
- observable evolution is not under control of designer, but its occurrence can
be estimated with a certain level of confidence.

Controllable evolutions, in other words, are designer's moves to identify differ-
ent design alternatives to implement a system. The designer then can choose
the most “optimal” one based on her experience and some analyses on these
alternatives. In this sense, controllable evolution is also known as design choice.
Observable ones, in contrast, correspond to potential evolutions of which real-
ization is outside the control of the designer. They are moves of reality to decide
how a requirement model looks like in the future. Therefore, the stakeholder
and designer have to forecast the reality's choice with a level of uncertainty. The
responses are then incorporated into the model.
We capture the evolution in terms of evolution rule. We have controllable rule
and observable rule corresponding to controllable and observable evolution.

Definition 1. A controllable rule r c is a set of tuples RM, RM i that consists

of an original model RM and its possible design alternative RM i .

RM

n

r c = → RM i

i