This article was originally published in a journal published by
Elsevier, and the attached copy is provided by Elsevier for the
author’s benefit and for the benefit of the author’s institution, for
non-commercial research and educational use including without
limitation use in instruction at your institution, sending it to specific
colleagues that you know, and providing a copy to your institution’s
administrator.
All other uses, reproduction and distribution, including without
limitation commercial reprints, selling or licensing copies or access,
or posting on open internet sites, your personal or institution’s
website or repository, are prohibited. For exceptions, permission
may be sought for such use through Elsevier’s permissions site at:
http://www.elsevier.com/locate/permissionusematerial
Knowledge-Based Systems 18 (2005) 353–365
www.elsevier.com/locate/knosys
co
p
y
Integration of behavioural requirements specification
within compositional knowledge engineering
Daniela E. Herlea Damiana, Catholijn M. Jonkerb, Jan Treurb,*, Niek J.E. Wijngaardsa,b
b
a
University of Calgary, Software Engineering Research Network, 2500 University Drive NW, Calgary, Alta, Canada T2N 1N4
Vrije Universiteit Amsterdam, Department of Artificial Intelligence, De Boelelaan 1081a, 1081 HV, Amsterdam, The Netherlands
al
Received 21 February 2002; accepted 31 May 2005
Available online 11 July 2005
Abstract
rs
on
In this paper it is shown how specification of behavioural requirements from informal to formal can be integrated within knowledge
engineering. The integration of requirements specification has addressed, in particular: the integration of requirements acquisition and
specification with ontology acquisition and specification, the relations between requirements specifications and specifications of task models
and problem solving methods, and the relation of requirements specification to verification.
q 2005 Elsevier B.V. All rights reserved.
1. Introduction
Au
th
or
’s
pe
Requirements Engineering (RE) addresses the development and validation of methods for eliciting, representing,
analysing, and confirming system requirements and with
methods for transforming requirements into more formal
specifications for design and implementation. Requirements
Engineering is one of the early but important phases in the
software development life cycle. Numerous studies have
revealed the misidentification of requirements as one of the
most significant sources of customer dissatisfaction with
delivered systems [1,2,3]. However, it is a difficult process,
as it involves the elicitation, analysis and documentation of
knowledge from multiple stakeholders of the system. There
is an increased need to involve the users at this stage of the
development life-cycle [4,5]. It is recognised that the users
are the experts in their work and a thorough understanding
of the requirements is achieved only by promoting effective
communication with them during the requirements engineering process [6]. It is also argued that an effective
requirements definition requires involvement and mutual
* Corresponding author. Tel.: C20 598 7763; fax: C20 598 7653.
E-mail addresses: danah@cpsc.ucalgary.ca (D.E. Herlea Damian),
jonker@nici.ru.nl (C.M. Jonker), treur@few.vu.nl (J. Treur).
URLs: http://www.nici.ru.nl/~catholj (C.M. Jonker), http://www.few.
vu.nl/~treur (J. Treur).
0950-7051/$ - see front matter q 2005 Elsevier B.V. All rights reserved.
doi:10.1016/j.knosys.2005.05.002
control of the process by all players, and that a good
partnership between users and designers enables a high
quality of the resulting system [7].
Requirements express intended properties of the system,
and scenarios specify use-cases of the intended system (i.e.
examples of intended user interaction traces), usually
employed to clarify requirements. The process of requirements engineering within software development is an
iterative process, in which a sharp borderline between
defining requirements and constructing the system design is
not always easy to draw. When an effective stakeholderdeveloper communication link is in place, on the basis of a
(partially) constructed design description of the system,
additional information may be elicited from the stakeholders (i.e. domain experts, users, system customers,
managers). Furthermore, detailed requirements and scenarios can be developed which refer to this design
description. Requirements can be expressed in various
degrees of formality, ranging from unstructured informal
representations (usually during initial requirements acquisition) to more structured semi-formal representations and
formal representations.
The interleaving of the process of requirements
engineering and the process of design is emphasised in
current research in the area of AI and Design, e.g. [8,9]. It is
put forward that realistic design processes include both
the manipulation of requirement specifications and the manipulation of design object specifications, resulting in a
detailed description of a design object and a good
354
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
Section 4 briefly summarizes the relations between
requirements and scenarios. Section 5 concludes the paper
with a discussion.
2. Representation of requirements and scenarios
on
al
co
p
y
In the approach presented in this paper, the processes of
requirements engineering and system development are
integrated by a careful specification of the co-operation
between the two. The manipulation process of a set of
requirements and scenarios, and the manipulation process of
a design object description (i.e. a description of the system)
are intertwined in the following way. First the set of
requirements and scenarios is made as precise as possible.
This requires multiple interaction with and among the
stakeholders. Based on that set a possible (partial)
description is made of the system. The description of the
system is used not only to validate the understanding of the
current set of requirements and scenarios, but also to elicit
additional information from the stakeholders. This leads to
more requirements and scenarios and to more detailed
requirements and scenarios. The process continues, alternating between manipulating a set of requirements and
scenarios, and manipulating a description of a system.
Adequate representations of requirements and scenarios are
required for each part of the overall process, and, therefore,
the relations between the different representation forms of
the same requirement or scenario need to be carefully
documented.
One of the underlying assumptions on the approach
presented in this paper is that a compositional design
method will lead to designs that are transparent, maintainable, and can be (partially) reused within other designs. The
construction of a compositional design description of the
system that properly respects the requirements and
scenarios entails making choices between possible solutions
and possible system configurations. Such choices can be
made during the manipulation of the set of requirements and
scenarios, but also during the manipulation of the design
object description. Each choice corresponds to an abstraction level. For each component of the system design further
requirements and scenarios are necessary to ensure that the
combined system satisfies the overall system requirements
and scenarios. The different abstraction levels in requirements are reflected as levels of process abstraction in the
design description during the manipulation of the compositional design description.
Different representations of requirements and scenarios
are discussed in Sections 2.1–2.3. The use of process
abstraction levels is explained further in Section 3. An
overview of the relations between representations of
requirements and scenarios, and different levels of process
abstraction is presented in Section 4.
In Requirements Engineering the role of scenarios, in
addition to requirements, has gained more importance, both
pe
rs
understanding of the requirements. This perspective on
design, applied in particular to the design of knowledgeintensive software, is employed throughout the paper. This
is in contrast with the tradition in software engineering to
separate the activity of manipulating software requirements
from the ‘design of software’, the actual construction of the
system design [10]; Sommerville 1985; [11–13,42].
Principled model-based methodologies for knowledge
engineering, are, for example, Desire [14–16] and
CommonKads [17] or Mike [18]. Here the emphasis is on
specification of the (conceptual) model of the system being
developed and not on specification of required behaviour
properties of a system to be developed. A transparent
distinction between specification of the structure of a system
(or task or problem solving method) and its (behavioural)
properties is not made. For example, in the AI and Design
community a specification of the structure of a design object
is often distinguished from a specification of function or
behaviour; e.g. [8,9]. In recent research in knowledge
engineering, identification and formalisation of properties
of knowledge-intensive systems is addressed, usually in the
context of verification or competence assessment [19–23].
Such properties can be used as a basis for requirement
specifications. In this paper it is shown how specification of
behavioural requirements from informal to formal can be
integrated within knowledge engineering.
From the basic ingredients in knowledge engineering
methodologies the following are especially relevant to the
integration of requirements specification:
† knowledge level approaches to problem solving
methods, e.g. [21],
† ontologies, e.g. [24] and
† verification, e.g. [19,20].
or
’s
It has to be defined how requirements specification
relates to these basic ingredients. Therefore, integration of
requirements specification within a principled knowledge
engineering methodology has to address, in particular:
Au
th
† behavioural requirements and ontologies. Integration of
requirements acquisition and specification with ontology
acquisition and specification
† behavioural requirements and compositionality. Relations between requirements specifications and specifications of task models with tasks and problem solving
methods at different levels of (process) composition
† behavioural requirements and verification. Relation of
requirements specification to verification
These aspects are addressed in this paper. The different
forms of representation of requirements and scenarios are
presented in Section 2, for reasons of presentation illustrated
by a simple example. In Section 3 refinement of
requirements related to different proces abstraction levels
(e.g. as in task or task/method hierarchies) is addressed.
355
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
co
p
y
other hand, an advantage of using formal descriptions is that
they can be manipulated automatically in a mathematical
way, for example in the context of verification and the
detection of inconsistencies. Furthermore, the process of
formalising the representations contributes to disambiguation of requirements and scenarios (in contact with
stakeholders). At the same time however, a formal
representation is less appropriate as a communication
means with the stakeholders. Therefore, in our approach
in the overall development process, different representations
and relations between them are used:
† informal or structured semi-formal representations
(obtained during the process of formalisation) in contact
with stakeholders and designers of the system, and
† related formal representations to be used by the
designers during the construction of the design.
on
al
Independent of the measure of formality, each requirement and each scenario can be represented in a number of
different ways, and/or using different representation
languages. Examples are given below. When manipulating
requirements and scenarios, different activities can be
distinguished (see Fig. 1). Requirements and scenarios are
† elicited from the stakeholders,
† checked for ambiguities and inconsistencies;
† they are reformulated in a more precise or more
structured form, and
† represented in different forms (informal, semi-formal,
and formal) to suit different purposes like communication with stakeholders or the construction of a design
description, and
† they are refined across process abstraction levels (which
is addressed in Section 3).
2.1. Informal representations
Different informal representations can be used to express
the same requirement or scenario. Representations can be
made, for example, in a graphical representation language,
Au
th
or
’s
pe
rs
in academia and industry practice [25,26]. Scenarios or use
cases are examples of interaction sessions between the users
and the system [26,27]; they are often used during the
requirement engineering, being regarded as effective ways
of communicating with the stakeholders (i.e. domain
experts, users, system customers, managers, and developers). The initial scenarios can serve to verify (i.e. check
the validity in a formal manner) the requirements
specification and (later) the system prototypes. Evaluating
the prototypes helps detecting misunderstandings between
the domain experts and system designers if, for example, the
system designers made the wrong abstractions based on the
initial scenarios. In our approach requirements and
scenarios both are explicitly represented, and play a role
of equal importance. Having them both in a requirements
engineering process, provides the possibility of mutual
comparison. The requirements can be verified against the
scenarios, and the scenarios can be verified against the
requirements. By this mutual verification process, ambiguities and inconsistencies within and between the existing
requirements or scenarios may be identified, but also the
lack of requirements or scenarios. In particular, scenarios
may be identified for which no requirements were
formulated yet, and requirements may be identified for
which no scenarios were formulated yet.
As stated above, requirements and scenarios are seen as
effective ways of communicating with the stakeholders.
This can only be true if requirements and scenarios are
represented in a well-structured and easy to understand
manner and are precise enough and detailed enough to
support the development process of the system. Unfortunately, no standard language exists for the representation of
requirements and scenarios. Formats of varying degrees of
formality are used in different approaches [13]. Informally
represented requirements and scenarios are often best
understood by the stakeholders (although also approaches
exist using formal representations of requirements in early
stages as well [28]). Therefore, continual participation of
stakeholders in the process is possible. A drawback is that
the informal descriptions are less appropriate when they are
used as input to actually construct a system design. On the
Fig. 1. Representations from informal to formal.
356
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
A reformulation can lead to structured requirements in a
semi-formal form that provide more detail, for example R1
can be reformulated to R1.1, but also to two parts:
or a natural language, or in combinations of these languages.
Scenarios, for instance, can be represented using a format
that supports branching points in the process, or in a
language that only takes linear structures into account. A
simple example of a requirement R1 on a system to control a
chemical process is the following:
A requirement is a general statement about the (required)
behaviour of the system to be designed. This statement is
required to hold for every instance of behaviour of the system.
In contrast to this, a scenario is a description of a behaviour
instance (e.g. to be read as an instance of a system trace the
system has to show, given the user behaviour in the scenario).
An example of an informal representation of a scenario is:
Requirement R1b.1:
at any point in time
if the system provided as output an indication that the
situation is explosive and after this the user gave an input
that it has to be resolved,
then the system shall generate output that the heater is
turned off
al
co
p
y
Requirement R1
For situations that the temperature and pressure are high
the system shall give a red alert and turn the heater off.
Requirement R1a.1:
at any point in time
if the system received input that the temperature is high
and the pressure is high
then the system shall generate as output a red alert and
an indication that the situation is explosive
2.2. Structured semi-formal representations
pressure is high
pe
Both requirements and scenarios can be reformulated to
more structured and precise forms.
th
or
’s
2.2.1. Requirements
To check requirements for ambiguities and inconsistencies, an analysis that seeks to identify the parts of a given
requirement formulation that refer to the input and output of
the system is useful. Such an analysis often provokes a
reformulation of the requirement into a more structured
form, in which the input and output references are made
explicitly visible in the structure of the formulation.
Moreover during such an analysis process the concepts
that relate to input can be identified and distinguished from
the concepts that relate to the output of the system. Possibly
the requirement splits in a natural manner into two or more
simpler requirements. This often leads to a number of new
(representations of) requirements and/or scenarios. For
example, the following requirement may be found as a
result of such an analysis:
Au
temperature is high
rs
Note that this scenario describes one of the behaviour
instances for which requirement R1 holds.
Requirement R1a.1 can also be represented graphically,
for example, by (here each of the pairs of arrows means that
both arrows of the pair occur at the same time):
on
Scenario S1
The temperature and pressure are high.
A red alert is generated and the heater is turned off.
Requirement R1.1:
at any point in time
if the system received input that the temperature is high
and the pressure is high
then the system shall generate as output a red alert and an
indication that the situation is explosive, and after the
user gives an input that it has to be resolved, the system
gives output that the heater is turned off
red alert
system
situation is explosive
As a specific case, also requirements referring only to
input or only to output can be encountered. For requirements
formulated in such a structured manner the following
classification can be made:
† requirements on input only, independent of output (input
requirements),
† requirements on output only, independent of input
(output requirements), and
† requirements relating output to input
The latter type of requirements can be categorised as:
† function or behaviour requirement (output is dependent
on input: input-output-dependency)
† environmental requirement or assumption (input is
dependent on output: output-input-dependency)
The environment is not within the scope of the software
development; it cannot be ‘tuned’ to exhibit particular
properties. Therefore, when stating properties of the
environment (which includes users) of the system (output–
input–dependency), the term ‘requirement’ is avoided and
the term ‘assumption’ is used. As such, only assumptions
can be made on its behaviour and properties. The term
‘requirements’ is used for those parts of the system that are
within the scope of designable parts of the system.
In addition, requirements can be categorised according to
the kind of properties they refer to:
357
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
† static requirements, or
† dynamic requirements.
† represent the temporal structure described implicitly in
the sequence of events.
For nontrivial dynamic requirements a temporal structure
has to be reflected in the representation. This entails that
terms such as ‘at any point in time’, ‘at an earlier point in
time’, ‘after’, ‘before’, ‘since’, ‘until’, ‘next’ are used to
clarify the temporal relationships between different fragments in the requirement.
The input and output terms used in the structured
reformulations form the basis of an ontology of input and
output concepts. Construction of this ontology takes place
during the reformulation of requirements. Acquisition of a
(domain or task or method) ontology is then integrated
within requirements engineering (requirements engineering
contributes at least to part of the ontology acquisition). For
the requirements engineering process it is very useful to
construct ontology of input and output concepts. For
example, in R1b.1 the concepts indicated below in bold
can be acquired.
The scenario S1 shown earlier is reformulated into a
structured semi-formal representation S1.1:
y
co
p
on
al
This scenarion covers both requirements given above
Notice that from this scenario it is not clear whether or not
always an input to be resolved leads to the heater being
turned off, independent of what preceded this input, or
whether this should only happen when the history actually
was as described in the first two lines of the scenario. If the
second part of the scenario is meant to be history
independent, this second part is better specified as a separate
scenario. However, we assume that in this example at least
the previous output of the system situation is explosive on
which the user reacts is a condition for the second part of the
scenario (as also expressed in the requirements above).
These considerations lead to the splitting of scenario S1.1
into the following two (temporally) independent scenarios
S1a.1 and S1b.1:
Scenario S1a.1
–input: temperature is high, pressure is high
–output: red alert, situation is explosive
Scenario S1b.1
–output: situation is explosive
–input: to be resolved
–output heater is turned off
rs
pe
Requirement R1b.1:
at any point in time
if the system provided as output
an indication that the situation is explosive,
and after this the user gave an input
that it has to be resolved,
then the system shall generate output
that the heater is turned off
Scenario S1.1
–input: temperature is high, pressure is high
–output: red alert, situation is explosive
–input: to be resolved
–output: heater is turned off
or
’s
This ontology later facilitates the formalisation of
requirements and scenarios, as the input and output concepts
are already defined.
In summary, to obtain a structured semi-formal
representation of a requirement, the following is to be
performed:
Au
th
† explicitly distinguish input and output concepts in the
requirement formulation
† define (domain and task/method) ontologies for input
and output information
† classify the requirement according to the categories
above
† make the temporal structure of the statement explicit
using words like, ‘at any point in time’, ‘at an earlier
point in time’, ‘after’, ‘before’, ‘since’, ‘until’, ‘next’.
2.2.2. Scenarios
For scenarios, a structured semi-formal representation is
obtained by performing the following:
† explicitly distinguish input and output concepts in the
scenario description
† define (domain) ontologies for the input and output
information
2.3. Formal representations
A formalisation of a scenario can be made by using
formal ontologies for the input and output, and by
formalising the sequence of events as a temporal trace.
Thus a formal temporal model is obtained, for example as
defined in [16,19,20]. To obtain formal representations of
requirements, the input and output ontologies have to be
chosen as formal ontologies. In the example this can be
done, for example by formalising a conceptual relation of
the form A is B, with as meaning that the object A has
property B, in a predicate form B(A). For example ‘the
situation is explosive’ is formalised by explosive(situation),
where situation is an object and explosive a predicate. This
format can be used within an appropriate subset or extension
of predicate logic. For example, requirement R1a.1 can also
be represented formally in combined symbolic and
graphical form by the following:
358
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
temperature(high)
To summarise, formalisation of a requirement or
scenario on the basis of a structured semi-formal representation is achieved by:
red alert
system
explosive(situation)
y
al
co
p
This results in a temporal formula F for a requirement
and in a temporal model M for a scenario.
Checking a temporal formula, which formally represents a requirement, against a temporal model, formally
representing a scenario, means that formal verification of
requirements against scenarios can be done by model
checking. A formal representation M of a scenario S and a
formal representation F of a requirement are compatible if
the temporal formula is true in the model. For example, the
temporal formula R1b.2 is indeed true for the model S1.
2, i.e. the explosive situation occurred at time point 2 in
the scenario, at time point 3 (which is later than 2) the
system received input to_be_resolved, and at time
point 4 (again later than 3), the system has as output
turn_off(heater).
However, requirement R1b.2 would also be true in the
following two scenarios. Scenario S2 is an example of a
situation in which the system turns off the heater when this
is not appropriate, scenario S3 is an example of a situation in
which the system waits too long before it turns off the heater
(which might lead to an explosion).
or
’s
pe
rs
In addition, the temporal structure, if present in a semiformal representation, has to be expressed in a formal manner.
Using the formal ontologies, and a formalisation of the
temporal structure, a mathematical language is obtained to
formulate formal requirement representations. The semantics
are based on compositional information states, which evolve
over time. An information state M of a component D is an
assignment of truth values {true, false, unknown} to the set of
ground atoms that play a role within D. The compositional
structure of D is reflected in the structure of the information
state. The set of all possible information states of D is denoted
by IS(D). A trace M of a component D is a sequence of
information states (Mt)t2N in IS(D).
The Temporal Trace Language TTL is a language in the
family of languages to which also situation calculus [29],
event calculus [30], and fluent calculus [31] belong. It is
defined as follows. Given a trace M of component D, the
information state of the input interface of component C at time
point t of the component D is denoted by stateD(M, t,
input(C)), where C is either D or a sub-component of D.
Analogously, stateD(M, t, output(C)), denotes the
information state of the output interface of component C at
time point t of the component D. These formalised
information states can be related to statements via the formally
defined satisfaction relation ~, comparable to the Holdspredicate in situation calculus. Behavioural properties can be
formulated in a formal manner, using quantifiers over time and
the usual logical connectives such as not, &, 0. An alternative
formal representation of temporal properties (using modal and
temporal operators) within Temporal Multi-Epistemic Logic
can be found in [47]. For example, in TTL the requirement
R1b.1 can be represented formally by:
† choosing formal ontologies for the input and output
information
† formalisation of the temporal structure
on
pressure(high)
Au
th
In this formalisation of R1b.1 the word ‘after’ is
represented by indicating that the time point t at which
to_be_resolved appeared on the input is greater than
some time point t 0 at which the system reported that the
situation is explosive on its output.
Scenario S1.1 can be represented formally by the
temporal model that is defined as follows:
Scenario S2
The temperature and the pressure are high
The system generates a red alert and turns off the heater,
The temperature and the pressure are medium
The temperature is low and the pressure is medium
The system turns off the heater
Scenario S3
The temperature and the pressure are high
The system generates a red alert and turns off the heater,
The system increases the heater
The system increases the heater
An explosion occurs
The system turns off the heater
Furthermore, the requirement would also be true in a
scenario in which the system waited with turning off the
heater, maybe even first increasing the heater for some time
(Scenario S4).
Scenario S4
The temperature and the pressure are high
The system indicates an explosive situation and a red
alert
The user indicates that the situation is to be resolved
The system increases the heater
The system again increases the heater
359
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
An explosion occurs
The system turns off the heater.
Based on these reformulations (that also affect the
ontologies), the requirement engineers made the following
representation of R1b.2 in TTL:
This last scenario has semi-formal scenario S4.1 and is
formalised as scenario S4.2:
Scenario S4.1
–input: temperature high
pressure high
–output: explosive situation
red alert
–input: to be resolved
–output: increase heater
– output:increase heater
–input: explosion occurred
– output:turn off heater.
co
p
y
Requirement R1b.4 is true in scenario S1.2 (let prev be
the function: n/nK1 and succ: n/nC1), but is not true in
the sketched unwanted scenarios like S3.1.
3. Requirements refinement and process composition
levels
on
al
The requirements engineering process considers the
system as a whole, in interaction with its stakeholders.
However, during a design process, often a form of
structuring of the system is used. Sub-processes are
distinguished, for example in relation to development or
selection of a task or task/method hierarchy. For the
processes at the next lower process abstraction level, also
requirements can be expressed. Thus a distinction is made
between
† stakeholder requirements and stakeholder scenarios
(for the top level of the system, elicited from
stakeholders, such as users, customers) and
† designer requirements and designer scenarios (for the
lower process abstraction levels, constructed by
requirement engineers and designers).
rs
or
’s
pe
In other words, requirement R1b.2 leaves too many
possibilities for the system’s behaviour, and, being a
formalisation of R1b.1, so do the requirements that form
the reason for formulating R1b.1, i.e. R1a.1, and R1.1.
During the requirement engineering process this has to be
resolved in contact with the stakeholders. In this case, the
semi-formal R1.1 and R1a.1, and the formal R1b.2 have to
be reformulated. After a discussion with the stakeholders,
R1.1 is reformulated into:
Au
th
Requirement R1.2:
at any point in time
if the system received input that the temperature is high
and the pressure is high
then at the next point in time the system shall generate as
output a red alert and an indication that the situation is
explosive, and at the next point in time after the user
gives an input that it has to be resolved, the system gives
output that the heater is turned off
And requirement R1b.1 is reformulated into:
Requirement R1b.3:
at any point in time
if the system provided as output
an indication that the situation is explosive,
and at the next time point after the user gave an input
that the situation has to be resolved,
then the system shall generate output
that the heater is turned off
Designer requirements and scenarios are dependent on a
description of the system. Requirements on properties of a
sub-component of a system reside at a next lower level of
process abstraction compared to the level of requirements on
properties of the system itself. Often sets of requirements at a
lower level are chosen in such a way that they realise a next
higher-level requirement. This defines a process abstraction
level refinement relation between requirements. These process
abstraction refinement relationships can also be used to verify
requirements. For example, if the refinements of a requirement
to the next lower process abstraction level all hold for a given
system description, then the refined requirement can be proven
to hold for that system description. Similarly, scenarios can be
refined to lower process abstraction levels by adding the
interactions between the sub-processes. At each level of
abstraction, requirements and scenarios employ the terminology defined in the ontology for that level. In the example used
above, for the structured semi-formal requirements two
processes can be distinguished:
interpret process info
input information of type: temperature is high, pressure
is high
output information of type: situation is explosive
360
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
generate actions
input information of type: situation is explosive
output information of type: red alert, heater is turned off
y
At the next lower abstraction level of these two processes
the following requirements can be formulated, as a
refinement of the requirements given earlier:
interpret process info (IPI)
Requirement R1int.1:
at any point in time
if the component received input that the temperature is
high and the pressure is high
then the component shall generate as output an indication
that the situation is explosive
co
p
Furthermore, scenarios S1a.1 and S1b.1 given earlier can
be refined to
The semi-formal scenarios S1inta.1 and S1intb.1 are
reformulated into formal scenarios S1inta.2 and S1intb.2,
respectively. These formal scenarios are shown below:
pe
rs
Requirement R1actb.1:
at any point in time
if the component received input that the situation is
explosive,
and after this it received an input that it has to be resolved,
then the component shall generate output that the heater is
turned off
on
Requirement R1acta.1:
at any point in time
if the component received input that the situation is
explosive,
then the component shall generate as output a red alert
al
generate actions (GA)
Au
th
or
’s
The semi-formal requirements R1int.1, R1acta.1, and
R1actb.1 are reformulated in the formal requirements R1int.
2, R1acta.2, and R1actb.2, respectively. These formal
requirements are given below:
Fig. 2. Process abstraction level refinements
361
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
† between scenarios at different process abstraction levels
(Fig. 2),
† between requirements and scenarios at the same process
abstraction level (Figs. 1–3)
† among requirements at the same level of formality
(Fig. 3)
† between requirements and scenarios at the same level
of formality (Fig. 3).
4. Traceability relations for requirements and scenarios
y
As requirements and scenarios form the basis for
communication among stakeholders (including the system
developers), it is important to maintain a document in which
the requirements and scenarios are organised and structured in
a comprehensive way. This document is also important for
maintenance of the system once it has been taken into
operation. Due to the increase in system complexity nowadays, more complex requirements and scenarios result in
documents that are more and more difficult to manage. The
different activities in requirements engineering lead to an often
large number of inter-related representations of requirements
and scenarios.
In this section an overview is given of the traceability
relations, after which the traceability relations in the example
are shown, and finally the use of traceability relations for
verification is described.
co
p
These relationships are often adequately specified using
hyperlinks. This offers traceability; i.e. relating relevant
requirements and scenarios as well as the possibility to
‘jump’ to definitions of relevant requirements and scenarios.
Thus requirements and scenarios resulting from an extensive
case-study have been placed in a hyperlinked structure [32];
see Fig. 3, which combines Figs. 1 and 2.
al
4.2. Traceability relations for the example
rs
The explicit representation of these traceability relations
is useful in keeping track of the connections; traceability
relationships can be made explicit:
The diagram shown in Fig. 3 can be used to depict the
current relationships of the requirements and scenarios. In
Fig. 4 the relationships are depicted which are explained in
Section 2, right up to the point when R1b.2 is determined to
be incorrect. In this figure alternative reformulations are
shown for both R1 and S1. For example R1 can be
reformulated into R1.1, but also in two requirements R1a.1
and R1b.1. The following relationships between requirements
and scenarios hold (not depicted in Fig. 4):
on
4.1. Overview of traceability relations
requirement R1 is true in scenario S1
requirement R1.1 is true in scenario S1.1
Au
th
or
’s
pe
† among requirements at the same process abstraction level
(Fig. 1),
† between requirements at different process abstraction
levels (Fig. 2),
† among scenarios at the same process abstraction level
(Fig. 1),
Fig. 3. Traceability relations.
362
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
process
abstraction
level 1
form
sem
l
rma
info
l
rma
i-fo
{
al
R1b.2
R1b.1
R1a.1 }
R1.1
R1
S1b.1
S1.1
S1
S2
S3
S4.2
S1.2
{ S1a.1 }
S4.1
S4
form
sem
l
rma
info
l
rma
i-fo
{
al
R1b.4
R1b.3
R1a.1 }
R1.2
R1
S1
S2
S3
S4.2
S1.2
S1b.1
S1.1
co
p
process
abstraction
level 1
y
Fig. 4. Traceability relationships depicting the situation when R1b.2 is determined to be incorrect.
{ S1a.1 }
S4.1
S4
al
Fig. 5. Traceability relationships depicting the correct requirements and scenarios.
Fig. 6 depicts the relations between requirements and
scenarios at different levels of process abstraction. As shown,
requirement R1.2 at process abstraction level 1 is refined into
requirements R1int.1, R1acta.1, and R1actb.1 at process
abstraction level 2. The same holds for the set of
requirements consisting of R1a.1 and R1b.3. These are
refined by the same set of requirements as R1.2. The
scenarios S1a.1 and S1b.1 at process abstraction level 1 are
refined by the scenarios Sinta.1 and S1intb.1 at process
abstraction level 2, respectively. At process abstraction level
the semi-formal scenarios S1inta.1 and S1intb.1 are
reformulated into the formal scenarios S1inta.2 and S1intb.
2, respectively.
on
requirement R1a.1 is true in scenario S1a.1 (not shown)
requirement R1b.1 is true in scenario S1b.1 (not shown)
requirement R1b.2 is true in scenario S1.2
requirement R1b.2 is true in scenario S4.2 (unwanted
scenario)
pe
rs
After the discovery of the incorrect requirement R1b.2 a
number of requirements is reformulated, resulting in the
situation depicted in Fig. 5. The requirements R1.2, R1b.3
and R1b.4 replace requirements R1.1, R1b.1 and R1b.2 of
Fig. 4, respectively. The following relationships between
requirements and scenarios hold in Fig. 5:
or
’s
requirement R1 is true in scenario S1
requirement R1.2 is true in scenario S1.1
requirement R1a.1 is true in scenario S1a.1 (not shown)
requirement R1b.3 is true in scenario S1b.1 (not shown)
requirement R1b.4 is true in scenario S1.2
requirement R1b.4 is not true in scenario S4.2 (unwanted
scenario).
th
process
abstraction
level 1
sem
Au
l
rma
info
sem
l
rma
i-fo
R1b.4
S1.1
S1
form
Verification of requirements and scenarios is facilitated by
keeping track of traceability relations. Traceability relations
over process abstraction levels (vertical direction in Fig. 3)
al
l
R1b.3
rma
i-fo
{R1a.1 }
R1.2
R1
process
abstraction
level 2
rma
info
form
4.3. Traceability relations and verification
S2
S3
al
R1acta.1
R1int.1
R1actb.1
S4.2
S1.2
S1b.1
{S1a.1
}
S4.1
S4
S1inta.2
S1inta.1
S1intb.2
S1intb.1
l
Fig. 6. Traceability relationships for two levels of process abstraction.
363
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
5. Discussion
or
’s
co
p
on
pe
rs
Examples of ‘horizontal’ verification.
When the formal scenario S1.2 is fulfilled, then it can be
concluded that the semi-formal scenario S1b.1 is also
fulfilled.
The scenario S2 is an ‘isolated’ scenario: it is not related to
any requirement.
The informal scenario S2 is an ‘unreformulated’ scenario:
it is not related to a semi-formal scenario.
Verification of requirement R1b.2 against the (unwanted)
scenarios (e.g. S4.2) caused the reformulation of that
requirement, resulting in requirement R1b.3.
al
Example of ‘vertical’ verification.
When requirements R1int.1, R1acta.1 and R1actb.1 are all
fulfilled, then it can be concluded that requirement R1.2 is
also fulfilled.
Traceability relations among requirements and scenarios
at one process abstraction level (horizontal direction in
Fig. 3) enable verification of requirements and scenarios in
terms of each other. Scenarios can be employed to verify
requirements, requirements can be employed to verify
scenarios, isolated requirements and scenarios can be
detected, et cetera.
Requirements Engineering is today a well-studied field
of research within Software Engineering; e.g. [1,2]. In
recent years requirements engineering for distributed and
agent systems has been studied, e.g. [33,34]. The
requirements specification language ALBERT II [28,34],
based on real-time temporal logic, has been developed for
the area of real-time distributed systems, but has been
tuned to the agent perspective as well. Reusable
requirements patterns play an important role. In [33,35,
36] the KAOS approach to Requirements Engineering of
composite systems is described. In this approach a
requirement for the overall system is called a goal.
What is called a requisite is a requirement on part of the
dynamics controllable by a single agent or (given)
environment component. Goal refinement is used to
decompose goals into requisites via AND/OR graphs.
This can be compared to our notion of requirements
refinement over process abstraction levels. The term
assumption is used to indicate requisites on (given)
environmental components.
The process of making requirements more precise is
supported by using both semi-formal and formal representations for requirements. Part of this process is to relate
concepts used in requirements to input and output of the
system. Since requirement specifications need system-related
concepts, it has been shown how the acquisition and
specification of requirements goes hand in hand with the
acquisition and specification of ontologies. Examples of
known properties (based on ontologies) that can be related to
requirements are properties of problem solving methods for
diagnosis [19,20,37], and properties of propose-and-revise
problem solving methods [23].
The formalisation of behaviour requirements has to
address the semantics of the evolution of the system (input
and output) states over time. In this paper the semantics of
properties of compositional systems is based on the temporal
semantics approach, which can be found in the development
of a compositional verification method for knowledgeintensive systems. For diagnostic process models, see [19,
20]; for co-operative information gathering agents, see [14];
for negotiating agents, see [46]. By adopting the semantical
approach underlying the compositional verification method, a
direct integration of requirements engineering with the
specification of properties of problem solving methods and
their verification could easily be established.
The temporal trace language TTL used in our approach is
much more expressive than standard or extended modal
temporal logics as described, for example, in [39–41,45], in a
number of respects. In the first place, it has order-sorted
predicate logic expressivity, whereas the standard temporal
logics are propositional. Secondly, the explicit reference to
time points and time durations offers the possibility of
modelling the dynamics of real-time phenomena, which may
be useful for the development of knowledge-based systems for
real-time applications, just as the languages ALBERT II and
KAOS discussed above are.
y
enable a compositional approach to verification. Requirements and scenarios at a specific process abstraction level are
verified in terms of requirements and scenarios at the next
(lower) process abstraction level [19,20]. Requirements and
scenarios which are not further decomposed in requirements
and scenarios at a lower process abstraction level are
considered to be ‘primitive’, and need to be verified in the
specification of the system. Ideally these requirements and
scenarios are easier to verify than the more complex, broadly
stated requirements and scenarios higher up in the process
abstraction levels.
Au
th
Requirements describe the required properties of a system
(this includes the functions of the system, structure of the
system, static properties, and dynamic properties). In
applications to agent-based systems, the dynamics or
behaviour of the system plays an important role in description
of the successful operation of the system. Requirements
specification has both to be
† informal or semi-formal (to be able to discuss them with
stakeholders), and
† formal (to disambiguate and analyse them and establish
whether or not a constructed model for a system satisfies
them).
Typical software requirements engineering practices are
geared toward the development of a formal requirements
specification.
364
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
References
on
al
co
p
y
[1] A.M. Davis, Software requirements: Objects, Functions, and States,
Prentice Hall, New Jersey, 1993.
[2] I. Sommerville, P. Sawyer, Requirements Engineering: a Good Practice
Guide, Wiley, Chicester, England, 1997.
[3] G. Kontonya, I. Sommerville, Requirements Engineering: Processes
and Techniques, Wiley, New York, 1998.
[4] C. Clavadetscher, User involvement: key to success, IEEE Software,
Requirements Engineering Issue (1998) 30–33.
[5] The Standish Group, (1995): The High Cost of Chaos: http://www.
standishgroup.com.
[6] H.R. Beyer, K. Holtzblatt, Apprenticing with the customer, Communications of the ACM 38 (5) (1995) 45–52.
[7] K. Holzblatt, K.R. Beyer, Requirements gathering: the human factor,
Communications of the ACM 38 (5) (1995) 31.
[8] J.S. Gero (Ed.), Artificial Intelligence in Design’96, Kluwer Academic
Publishers, Dordrecht, 2002.
[9] J.S. Gero, F. Sudweeks (Eds.), Artificial Intelligence in Design’98,
Kluwer Academic Publishers, Dordrecht, 1998.
[10] M.A. Jackson, Principles of Program Design, Academic Press, New
York, 1975.
[11] G. Booch, Object Oriented Design with Applications, Benjamins
Cummins Publishing Company, Redwood City, 1991.
[12] J.C. van Vliet, Software Engineering: Principles and Practice, Wiley,
Chicester, 1993.
[13] R.S. Pressman, Software Engineering: A practitioner’s approach
McGraw-Hill Series in Computer Science, Fourth ed., McGraw-Hill
Companies Inc., New York, 1997.
[14] C.M. Jonker, J. Treur, Compositional Verification of multi-agent
systems: a formal analysis of pro-activeness and reactiveness in: W.P.
de Roever, H. Langmaack, A. Pnueli (Eds.), Proceedings of the
International Workshop on Compositionality, COMPOS’97 Lecture
Notes in Computer Science vol. 1536, Springer Verlag, Berlin, 1998,
pp. 350–380. [Extended version in Int. J. Cooperat. Inform. Syst., vol.
11, 2002, pp. 51–92].
[15] F.M.T. Brazier, C.M. Jonker, J. Treur, Principles of component-based
design of intelligent agents, Data and Knowledge Engineering, Vol. 41,
pp1–28, (2002).
[16] F.M.T. Brazier, J. Treur, N.J.E. Wijngaards, M. Willems, Temporal
semantics of compositional task models and problem solving methods,
Data and Knowledge Engineering 29 (1) (1999) 17–42; Preliminary
version in: B.R. Gaines, M.A. Musen (eds.), Proceedings of the 10th
Banff Knowledge Acquisition for Knowledge-based Systems workshop, KAW’96, Calgary: SRDG Publications, Department of Computer
Science, University of Calgary, 1996, pp. 15/1–15/17
[17] A.Th. Schreiber, B.J. Wielinga, J.M. Akkermans, W.van.de Velde, R.
de Hoog, CommonKads: a comprehensive methodology for KBS
development, IEEE Expert 9 (6) (1994).
[18] J. Angele, D. Fensel, D. Landes, R. Studer, Developing knowledgebased systems with MIKE, Journal of Automated Software (1998).
[19] F. Cornelissen, C.M. Jonker, J. Treur, Compositional verification of
knowledge-based systems: a case study in diagnostic reasoning in: E.
Plaza, R. Benjamins (Eds.), Knowledge Acquisition, Modelling and
Management, Proceedings of the 10th European Knowledge Acquisition Workshop, EKAW’97 Lecture Notes in AI vol. 1319, Springer,
Berlin, 1997, pp. 65–80.
[20] F. Cornelissen, C.M. Jonker, J. Treur, Compositional Verification of
Knowledge-Based Task Models and Problem Solving Methods.
Knowledge and Information Systems Journal, Vol. %, 2003, pp. 337–
367.
[21] D. Fensel, Assumptions and limitations of a problem solving method: a
case study in: B.R. Gaines, M.A. Musen (Eds.), Proceedings of the 9th
Banff Knowledge Acquisition for Knowledge-based Systems Workshop, KAW’95, SRDG Publications, Department of Computer Science,
University of Calgary, Calgary, 1995.
pe
rs
Third, the possibility to quantify over traces allows for
specification of more complex dynamics. As within most
temporal logics, reactiveness and pro-activeness properties
can be specified. In addition, in our language also
properties expressing different types of adaptive behaviour
can be expressed. For example an adaptive property such
as ‘exercise improves skill’, or ‘the better the experiences,
the higher the trust’ (trust monotonicity) which both are a
relative property in the sense that it involves the
comparison of two alternatives for the history. This type
of adaptive property can be expressed in our language,
whereas in standard forms of temporal logic different
alternative histories cannot be compared. The same
difference applies to situation calculus [29], event calculus
[30], and fluent calculus [31]. Therefore, TTL is more
suitable for requirements specification within the development of adaptive knowledge-based systems, than standard
temporal logics, or KAOS, ALBERT II or these other
calculi mentioned.
Fourth, in TTL it is possible to define local languages
for parts of a system. Especially in a compositional
approach to Knowledge Engineering as in DESIRE, the
distinctions between components, and between input and
output and internal languages are crucial. They are
supported by treating them as first class citizens in the
language, which also entails the possibility to quantify
over system parts and changing system parts over time.
For example, this allows for specification of system
configuration modification over time; cf. [43].
For some example systems requirements and scenarios
have been elicited, analysed, manipulated, and formalised.
The lessons learned from these case studies are:
Au
th
or
’s
† The process of achieving an understanding of a
requirement involves a large number of different
formulations and representations, gradually evolving
from informal to semi-formal and formal.
† Scenarios and their formalisation are, compared to
requirements, of equal importance.
† Categorisation of requirements on input, output and
function or behaviour requirements, and distinguishing
these from assumptions on the environment clarifies the
overall picture.
† Grouping requirements and scenarios in clusters gives a
more global insight.
† Keeping track on the various relations between
different representations of requirements, between
requirements and clusters, between requirements and
scenarios, and many others, is supported by hyperlink
specifications within a requirements document.
In current and future research, further integration of
requirements engineering in the compositional design
method for multi-agent systems, Desire and, in particular,
in its software environment is addressed.
365
D.E. Herlea Damian et al. / Knowledge-Based Systems 18 (2005) 353–365
on
al
co
p
y
[36] A. van Lamsweerde, R. Darimont, E. Letier (1998), Managing Conflicts
in Goal-Driven Requirements Engineering. IEEE Transactions on
Software Engineering, Special Issue on Managing Inconsistency in
Software Engineering.
[37] V.R. Benjamins, Problem Solving Methods for Diagnosis. PhD Thesis,
University of Amsterdam, Amsterdam, The Netherlands, 1993.
[38] F.M.T. Brazier, C.M. Jonker, J. Treur, Principles of Compositional
Multi-agent System Development in: J. Cuena (Ed.),, Conference on
Information Technology and Knowledge Systems, IT&KNOWS’98
Proceedings of the 15th IFIP World Computer Congress, WCC’98
(1998), pp. 347–360.
[39] M. Fisher, A survey of concurrent metateM—the language and its
applications in: D.M. Gabbay, H.J. Ohlbach (Eds.), Temporal Logic—
Proceedings of the First International Conference Lecture Notes in AI
vol. 827 (1994), pp. 480–505.
[40] E.M. Clarke, O. Grumberg, D.A. Peled, Model Checking, MIT Press,
Cambridge, MA, 2000.
[41] Z. Manna, A. Pnueli, Temporal Verification of Reactive Systems:
Safety, Springer Verlag, Berlin, 1995.
[42] A.P. Sage, J.D. Palmer, Software Systems Engineering, Wiley, New
York, 1990.
[43] M. Dastani, C.M. Jonker, J. Treur, A requirement specification
language for configuration dynamics of multi-agent systems in: M.
Wooldridge, G. Weiss, P. Ciancarini (Eds.), Proceedings of the Second
International Workshop on Agent-Oriented Software Engineering,
AOSE’01 Lecture Notes in Computer Science vol. 2222, Springer
Verlag, Berlin, 2002, pp. 169–187. Extended version in: Int.J. of
Intelligent System, vol. 19 (2004), pp. 277–300.
[44] D. Herlea, C.M. Jonker, J. Treur, N.J.E. Wijngaards, Integration of
behavioural requirements specification within knowledge engineering
in: D. Fensel, R. Studer (Eds.), Proceedings of the 11th European
Workshop on Knowledge Acquisition, Modelling and Management,
EKAW’99 Lecture Notes in AI vol. 1621, Springer Verlag, Berlin,
1999, pp. 173–190.
[45] C. Stirling, Modal and Temporal Properties of Processes, Springer
Verlag, Berlin, 2001.
[46] F.M.T. Brazier, F. Cornelissen, R. Gustavsson, C.M. Jonker, O.
Lindeberg, B. Polak, J. Treur, Compositional Design and Verification of
a Multi-Agent System for One-to-Many Negotiation, Proceedings of
the Third International Conference on Multi-Agent Systems,
ICMAS’98, IEEE Computer Society Press, California, 1998. pp. 49–
56 [Extended version in: Journal of Applied Intelligence, vol. 20
(2004), pp. 95–117.
[47] J. Engelfriet, C.M. Jonker, J. Treur, Compositional Verification of
Multi-Agent Systems in Temporal Multi-Epistemic Logic. In: J.P.
Mueller, M.P. Singh, A.S. Rao (eds.), Intelligent Agents V. Lecture
Notes in AI, Springer Verlag. Extended version in Journal of Logic,
Language and Information, vol. 11, 2002, pp. 195–225. Extented
version in: Journal of Logic, Language and Information, vol. 11 (2002),
pp.195–225
Au
th
or
’s
pe
rs
[22] D. Fensel, R. Benjamins, Assumptions in model-based diagnosis in:
B.R. Gaines, M.A. Musen (Eds.), Proceedings of the 10th Banff
Knowledge Acquisition for Knowledge-based Systems workshop
KAW’96, SRDG Publications, Department of Computer Science,
University of Calgary, Calgary, 1996, pp. 5/1–5/18.
[23] D. Fensel, A. Schonegge, R. Groenboom, B. Wielinga, Specification
and verification of knowledge-based systems in: B.R. Gaines, M.A.
Musen (Eds.), Proceedings of the 10th Banff Knowledge Acquisition
for Knowledge-based Systems workshop KAW’96, SRDG Publications, Department of Computer Science, University of Calgary,
Calgary, 1996, pp. 4/1–4/20.
[24] M. Musen, Ontology Oriented Design and Programming: a New
Kind of OO in: J. Cuena (Ed.), Proceedings of the 15th IFIP
World Computer Congress, WCC’98 Conference on Information
Technology and Knowledge Systems, IT&KNOWS’98 (1998),
pp. 17–20.
[25] M. Erdmann, R. Studer, Use-cases and scenarios for developing
knowledge-based systems in: J. Cuena (Ed.), Proceedings of the IFIP
World Computer Congress, WCC’98 Conference on Information
Technologies and Knowledge Systems, IT&KNOWS (1998),
pp. 259–272.
[26] K. Weidenhaupt, M. Pohl, M. Jarke, P. Haumer, Scenarios in system
development: current practice IEEE Software,March/April 1998 pp.
34–45.
[27] Potts, C., Takahashi, K. and ANton, A. Inquiry based requirements
analysis, IEEE Software, 11(2), 1994.
[28] E. Dubois, E. Yu, M. Petit, in: E. Dubois, E. Yu, M. Petit (Eds.), From
Early to Late Formal Requirements Proceedings of the IWSSD’98,
IEEE Computer Society Press, California, 1998.
[29] J. McCarthy, P. Hayes, Some philosophical problems from the
standpoint of artificial intelligence, Machine Intelligence 4 (1969)
463–502.
[30] R. Kowalski, M. Sergot, A logic-based calculus of events, New
Generation Computing 4 (67–95) (1986) 1986.
[31] S. Hölldobler, M. Thielscher, A new deductive approach to planning,
New Generation Computing 8 (225-244) (1990) 1990.
[32] Herlea, D., Jonker, C.M., Treur, J., Wijngaards, N.J.E. A Case
Study in Requirements Engineering: a Personal Internet Agent.
Technical Report, Vrije Universiteit Amsterdam, Department of
Artificial Intelligence. 1998.
[33] A. Dardenne, A. van Lamsweerde, S. Fickas, Goal-directed requirements acquisition, Science in Computer Programming 20 (1993) 3–50.
[34] E. Dubois, P. Du Bois, J.M. Zeippen, A Formal Requirements
Engineering Method for Real-Time, Concvurrent, and Distributed
Systems Proceedings of the Real-Time Systems Conference, RTS’95,
1995.
[35] R. Darimont, A. van Lamsweerde, Formal refinement patterns for goaldriven requirements elaboration, Proc. Fourth ACM Symp. Foundation
Software Eng. (FSE4) (1996) 179–190.