![](bg2.png)
unsatisfactory. The software-to-be will be integrated
into this environment to solve this problem. Then,
the behaviour of the environment will be satisfactory.
The software-to-be and its environment, together, re-
present the system. There are three types of state-
ments about the system, the software-to-be, and the
environment: the specification S, the domain know-
ledge D, and the requirements R. Based on these sta-
tements, the satisfaction argument is defined as fol-
lows: S, D ` R. The argument says that, if a software
is developed which satisfies S and is integrated into
an environment as described by D, and S and D are
consistent with each other, then R is satisfied.
KAOS Goal Models. Van Lamsweerde (van Lam-
sweerde, 2009) calls S software requirements and R
system requirements. As regards domain knowledge,
he distinguishes between: domain properties, dom-
ain hypotheses, and expectations. Domain properties
are facts about the environment (e.g. physical laws),
while domain hypotheses and expectations are both
assumptions about the environment. A domain hypot-
hesis is a descriptive statement about the environment
which simply needs to hold. An expectation is a pres-
criptive statement about the environment and, in con-
trast to domain hypotheses which are to be satisfied
by the environment in general, can be assigned to a
concrete agent in the environment who is responsible
for satisfying it (e.g. to a sensor, actuator, the user).
A KAOS goal model is an AND/OR graph. An
example is shown in Figure 9. Nodes of the graph are
multi-agent goals (i.e. goals that are further refined),
single-agent goals (i.e. leaf goals which are either as-
signed to the software-to-be (then they are software
requirements) or to the environment (then they are ex-
pectations)), domain properties, or domain hypothe-
ses. The AND/OR-refinement relationships between
the nodes show which subgoals need to be satisfied
and which domain properties and domain hypotheses
need to be valid to satisfy a parent goal. Thus, the
goal refinement structure reflects Zave and Jackson’s
satisfaction argument.
Problem Diagrams. Problem diagrams have been
suggested by Jackson (Jackson, 2001). They show the
software-to-be, the requirement to be satisfied in the
environment, and the part of the environment which
is relevant for satisfying the requirement. The nota-
tion is shown in Figure 1 and an example of a pro-
blem diagram is shown in Figure 6. The software-
to-be is shown as a so-called machine domain, the
environment is shown in terms of so-called problem
domains (material and immaterial objects in the en-
vironment) which are directly or indirectly connected
to the machine domain, and the requirement is shown
as a dashed oval connected to some problem dom-
ains. Three types of connections are differentiated:
interfaces, requirement references, and constraining
references. Interfaces exist between problem and ma-
chine domains where phenomena (events, states, va-
lues) are shared. Sharing means that one domain ob-
serves the phenomena, while the other controls them.
The controlling domain is annotated at the interface
(using an abbreviation followed by an exclamation
mark) as well as the phenomena. Requirement refe-
rences and constraining references, each connect the
requirement with problem domains. A requirement
reference is used to express that the requirement refers
to phenomena of the problem domain. A constraining
reference is used to express that the requirement con-
strains phenomena of the problem domain.
The Six-Variable Model. The Six-Variable Mo-
del (Ulfat-Bunyadi et al., 2016) is based on the
well-known Four-Variable Model (Parnas and Madey,
1995) and focuses on control systems. A control sy-
stem consists of some control software which uses
sensors and actuators to monitor/control certain quan-
tities in the environment. The Four-Variable Model
differentiates between four variables: monitored va-
riables m (environmental quantities the control soft-
ware monitors through input devices), controlled va-
riables c (environmental quantities the control soft-
ware controls through output devices), input variables
i (data items that the control software needs as input),
and output variables o (quantities that the control soft-
ware produces as output).
Frequently, it is not possible to monitor/control
exactly those variables one is interested in. Instead,
a different set of variables is monitored/controlled,
whose variables are related to the ones of real inte-
rest. The Six-Variable Model demands that the vari-
ables of real interest should be documented as well
(beside the classical four variables). The two addi-
tional variables are r and d. r (referenced) variables
are environmental quantities that should originally be
observed in the environment. Originally means before
deciding which sensors/actuators/other systems to use
for monitoring/controlling. d (desired) variables are
environmental quantities that should originally be in-
fluenced in the environment. The Six-Variable Model
is depicted in Figure 1 as a problem diagram.
For problem diagrams created based on the Six-
Variable model, the domain hypotheses, expectations,
and software requirements can be made explicit as
shown in Figure 2. DH-MD is a hypothesis about the
monitored domain, which needs to be true. Exp-SE
is an expectation to be satisfied by the sensors, Exp-
AC is an expectation to be satisfied by the actuators,
and Exp-CD is an expectation to be satisfied by the
controlled domain. SOF represents the software re-
Supporting the Systematic Goal Refinement in KAOS using the Six-Variable Model
103