AWRE’04 9th Australian Workshop on Requirements Engineering
Capturing Informal Requirements as Formal Models
Rubens Fernandes
University of South Australia
Rubens.Fernandes@postgrads.unisa.edu.au
Abstract
We present a requirements engineering tool and associated
methodology that converts natural language and graphical
requirements to models expressed in a process algebra
formalism. Natural language requirements are automat-
ically converted into the concrete syntax of the process
algebra using reconfigurable parsing and transformations.
Graphical requirements in the form of finite state dia-
grams are changed into textual form before parsing and
generation of the formal models. Analysis of the formal
models by a requirements engineer can lead to iterative
refinement of the natural language requirements and the
tool configuration. The motivation for this work comes
from the possible reduction in reworking when formal
methods are used early in the development life cycle.
Our framework allows the coexistence of an user-friendly
document that is suitable for non-technical users and a
formal model suitable for verification and reasoning.
1. Introduction
Commercial software projects have always faced the
difficult goal of releasing products of quality on time and
within budget. However, an increasingly competitive mar-
ket puts projects under more pressure by demanding higher
quality, shorter turnaround cycles and cheaper software.
The number of errors found during development have a
strong influence on the software metrics mentioned above.
The sooner a problem is identified and fixed, the less it
costs the project [1]. When an error that was introduced
in requirements engineering is found during testing, en-
gineers must fix the incorrect requirements, check all of
the ramifications through design and implementation and
finally retest the product.
In the light of the above discussion, requirements
engineering is critical to the success of any project. It
certainly pays to verify requirements as thoroughly as
possible before they are used for design or testing purposes.
However this is not easily achieved.
Requirements engineering consists of the following
tasks [2]:
3.1
Alex J. Cowie
University of South Australia
Alex.Cowie@unisa.edu.au
• elicitation
• analysis
• specification
• validation/verification
• management
Each one of these activities has very distinct social and
technological aspects [3]. Analysis and elicitation demand
a great deal of customer contact, domain knowledge,
experience and creativity [4], making them more difficult to
systematise than the subsequent design or implementation
activities. On the other hand, requirements management,
specification and verification can certainly benefit from the
use of tools and well defined methodologies.
Our work tries to address the technological aspect
of requirements engineering by creating a framework to
assist the analysis and verification of requirements by the
developer. In this paper, we outline an approach that makes
use of Formal Methods1, natural language processing and
graphical notation. We also describe a software tool cur-
rently in development that is based on this approach, and
conclude with an illustrative example.
2. Formal Methods and Natural Language
Restricted forms of natural language are widely used as
a notation for software requirements specifications. Natural
language is convenient because it allows non-technical
users to understand the product requirements. On the other
hand, the lack of precise semantics increases the possibility
of errors being introduced due to interpretation mistakes
and inherent ambiguity. Under or over specification are
also common problems when using natural language.
Formal methods have been advocated as one way to de-
fine requirements with mathematical precision and rigour
[5]. They provide the means to build system models by
specifying their structure and behaviour. When used in
conjunction with tools support, automated verification of
properties for complex models is also possible.
1 In this paper, the term “formal” means “having precise semantics with
mathematical basis”, rather than the more general meaning of “being
organised in a formal way”.
AWRE’04 9th Australian Workshop on Requirements Engineering
The usefulness of formal methods relies on models
being faithful representations of the essential aspects of the
informal system. Determining this is something that cannot
be done entirely in the formal framework, and requires
comparison of the formal representation with the original
requirements. This inherently precludes the existence of
completely automated frameworks, since some degree of
human analysis is always necessary.
Many requirements specifications are built by decom-
posing a system into smaller components, whose behaviour
can be more easily captured. It is then necessary to define
the interaction between those components, an aspect that is
captured in structural requirements. The internal dynamics
of components is specified by behavioural requirements.
This modelling approach is supported by features present
in many formal methods.
Although formal methods have been applied success-
fully in industry and research projects, they are still not
widely used today. Being based on mathematical frame-
works and notations, they are not as intuitive to the general
audience as natural language.
One proposed solution to this is the translation of re-
quirements written in natural language to a formal notation.
Flake et al. [6] [7] [8] proposed the use of a subset of
English to specify temporal properties. Requirements are
mechanically converted to temporal logic formulae. The
main issue with this type of approach is that it is quite
restrictive in terms of the subset of the language that
can be used in properties, making the requirements sound
somewhat artificial.
The conversion of natural language to formal notations
raises the issue of synchronisation between the two forms.
Hünle et al. [9] introduced a tool that allows simultaneous
manipulation of requirements in multiple concrete nota-
tions. The tool stores requirements in an internal abstract
model that is presented to the user via a graphical interface
in both English and UML’s Object Constraint Language
[10]. The user can modify any of these two concrete
representations, and the tool is responsible for propagating
the changes to the model and back to the user interface.
One problem noted by the authors was that the generated
English text followed the structure of the internal abstract
tree, which could result in non-intuitive sentences. The tool
also suffered from being too restrictive in terms of the
English input grammar.
Ambriola and Gervasi [11] developed a system that
addresses the lack of parsing flexibility found in other
approaches. Circe is an environment composed of a parser
(Cico), a storage mechanism based on general purpose
tuple-based data structures and a number of internal pro-
grams to manipulate data. Requirements are parsed by Cico
using a technique called fuzzy matching, which makes it
possible to match certain variations of grammar patterns
3.2
without the need for specifying all of them explicitly. Parse
trees are stored in the tuple space. A group of related tuples
constitute a T-model.
Using Circe’s browser-based interface, an user can
request the generation of different concrete views of the
data stored in the tuple space. Circe uses internal tools
called modellers to manipulate existing and build new T-
models containing the information necessary for a certain
view. A projector is used to select data from one or more
T-models and create an appropriate abstract model for the
requested view. Finally, a translator is invoked to produce
a concrete syntax representation of the abstract model. The
open architecture is a major virtue of Circe, as modellers,
projectors and translators are not restricted in terms of what
type of data they can produce or how they operate. This
flexibility is also possible due to the use of an unified
storage paradigm - the tuple space - making exchange of
information between the tools quite easy.
3. Formal Methods and Graphical Notations
Graphical notations are one possible alternative to the
use of natural language to specify requirements. They are
a widespread and well accepted technique in design and
implementation, and have also been used to some extent in
requirements engineering [12]. Some graphical notations
provide elements to describe structural and behavioural
information, supporting the modular way of specifying
systems as discussed in the previous section.
UML is a framework composed of graphical and tex-
tual notations that allow the specification of structure
and behaviour. However, the specification of the UML
semantics relies largely on natural language description
and only uses mathematical notation to a limited extent.
Some attention has been given by the research community
to express a more formalised semantics for UML. Liu et
al. [13] defined a formal1 semantics for use-case and class
diagrams using a formal language, so that they can be
applied to the specification of requirements. Shen and Liu
[14] proposed the use of use-case diagrams with formal
constraints written in a text-based formal language. As with
all formal methods, these approaches still demand expertise
when it comes to writing or reading the requirements.
A similar situation is described by Miller et al. in [15].
A flight guidance system requirements specification was
written using a graphical requirements language called
RSML (a notation influenced by Harel’s Statecharts [16]).
The requirements were converted mechanically to temporal
logic properties that were then verified using a model
checker. Again, the use of a formal method required experi-
enced people to write and maintain the formal requirements
manually.
We believe that a combination of natural language,
graphical notations, and formal methods is necessary to
AWRE’04 9th Australian Workshop on Requirements Engineering
address the following issues of the Requirements Engi-
neering activity:
• Requirements specifications must be available in a
format suitable for non-technical users;
• Formal methods must be used to model and manip-
ulate requirements in order to help developers find
inconsistencies early;
• The “user-friendly” and formal versions of the re-
quirements must be synchronised automatically;
• Automation should be used to facilitate the generation
of formal models from the natural language require-
ments, thus simplifying the requirements engineering
task of creating models from scratch.
4. From Natural Language to Formal
Methods
We built a tool to address the issues above and experi-
ment with the generation of formal models from inherently
informal notations. The following sections introduce our
tool and how it fits in the requirements engineering activity.
Borg is a specialised implementation of an architecture
similar to Circe’s, which focuses on generating formal
models from textual and graphical requirements (the graph-
ical aspects will be described in Section 6). A natural
language requirements document is parsed and the out-
put is stored in a T-model. The stored parse trees are
mechanically transformed into refined intermediate models
by a group of modellers. These models are then used by a
projector to build an abstract model of the system, which
already uses particular characteristics of the target concrete
notation. In the final step of the tool, the abstract model is
converted to a concrete formal method notation. The full
architecture is shown in Figure 1. We decided to use Cico
as our parser, for two main reasons:
• It is a domain-based parser, which allows for terms
in the grammar to have special contextual roles. The
generated parse trees are more amenable to formal
reasoning, needed for requirements analysis.
• When there are no exact matches between the gram-
mar and the input, Cico attempts to match patterns
that are “close enough” to the grammar. As a conse-
quence, the software engineer has additional freedom
to write requirements that sound more natural to the
reader.
Cico generates a series of T-Models comprising struc-
tural and behavioural information about a system and its
components. In order to adequately represent this data
using a formalism, it has to support the structural and be-
havioural modelling concepts. Process algebras are capable
of expressing structural and behavioural constructs. In this
work, we used a particular process algebra called Circal,
which was devised by Milne [17].
3.3
Natural
Language
Requirements
Cico
Borg
Parse Tree
Modellers
Intermediate
Models
Projector
Abstract Notation
(Transition Systems)
Translator
Process Algebra
(Concrete Syntax)
Fig. 1. The Borg tool overview
Borg’s modellers can identify each of the requirements
classes in the parse trees and generate intermediate models
that can be accessed by the projector. Modellers imple-
ment heuristics used to infer certain types of information
from requirements, and also contain domain knowledge
necessary to organise the parse trees in more useful ways.
In line with the nomenclature proposed by Ambriola and
Gervasi, Borg’s modellers provide intentional knowledge,
abstraction and visualisation support [11]. Our process
algebra projector takes the output of the modellers and
builds an abstract model that can be used to generate
concrete syntax for a variety of notations based on process
algebra.
Borg’s translator takes the projector’s output to write a
concrete specification of the system. The Circal implemen-
tation used in Borg was developed by Cowie and is called
Nova [18]. More details of the parsing operation and the
translation of parse trees into Circal processes is presented
in the Appendix.
5. Requirements Modelling with Borg
Borg executes the process depicted in Figure 2. A set of
initial customer requirements is received and goes through
requirements modelling. The output of the process are a
refined natural language requirements specification and the
AWRE’04 9th Australian Workshop on Requirements Engineering

Initial Customer
Requirements
Initial
Customer
Requirements

B A C

Requirements
Parser Natural modeller
Modelling Configuration Language Specification
Requirements

Borg
Natural
Language Process Algebra
Requirements (Concrete Syntax)

Generated
Fig. 2. Requirements Modelling Model

corresponding set of formal models in concrete notation.

The activities involved in requirements modelling are Analysis
intimately linked to the underlying framework provided by Requirements
Borg. Each of the individual steps in requirements mod- Modelling

elling is shown in Figure 3. The whole process consists of

a feedback loop where the natural language requirements
are manipulated by Borg to generate a formal model of the
system. This model is analysed by the requirements engi-
neer with the help of the Nova tool. During analysis it may
be possible to identify incomplete, ambiguous or incorrect
customer requirements. If the model is not satisfactory,
changes are made to the natural language requirements,
parser configuration or modeller specification and the cycle
starts again. Here is a more detailed description of each one
of the tasks that are triggered by the analysis of the formal
model:
A Requirements are updated according to results
obtained from the analysis of the formal model.
B The Natural Language parsing rules and other
related parser configurations need to be updated
if they are not sufficient to cover all the possible
ways to specify the requirements needed. In
most cases, the parser grammar is set up at
the beginning of the project according to the
specification style used. At this stage, only minor
updates may be necessary;
C The modeller may need modifications to support
the changes done in steps A and B. Similar to the
parser configuration, once the modeller is stable,
only minor changes may be required.
A refined requirements specification and a formal model
of the system are obtained as a result of requirements
modelling, and can be used as input to the design phase.
A number of observations can be made about the
process described above. It is possible that some of the
Requirements Specification
+
Formal Model
Fig. 3. Requirements modelling in detail
output of these tasks such as the modeller implementation
or parser configurations can be reused by similar projects,
thus reducing the development effort. The level of attention
needed for each one of the tasks is highly dependent on
the project and the system requirements.
An important point to emphasise is that the analysis and
manipulation of the generated models is still a task that
cannot be completely automated. We recognise that the
creative, cognitive and analytical aspects of requirements
engineering remain the responsibility of human engineers.
During the development of Borg and of some experi-
mental examples, we felt that certain types of behavioural
requirements required more verbosity in their definitions
than would be considered natural for a reader.
For example, when modelling an automatic door that
can be in two states - OPEN or SHUT - and the transition
between these states is triggered by pressing one of two
buttons - BOPEN or BCLOSE - one is tempted to write
the following requirements:
Requirement 5.1: When BOPEN is pressed, the door
becomes OPEN.
Requirement 5.2: When BCLOSE is pressed, the door
becomes SHUT.

3.4
AWRE’04 9th Australian Workshop on Requirements Engineering
Requirements 5.1 and 5.2 are not precise enough in
order to be translated directly to a formal notation. The
problem is that they do not clearly define which door states
accept the BOPEN or BCLOSE button presses. A human
reader could assume that either BOPEN would not be ac-
cepted while the door is in the OPEN state, or that BOPEN
could occur in the OPEN state with no effect on the
door. In constructing a formal model however, it is often
necessary to explicitly state such assumptions. This sort of
issue can be resolved in two different ways. The modeller
can be implemented to “assume” one way or another
when an incomplete or ambiguous definition is given. The
problem with this is that the modeller implementation may
become quite complex and dependent on particularities of
the system, since it is not completely feasible to capture
this sort of tacit knowledge in a program. A second option
is to require more information at the Natural Language
level, by changing the input grammar. In this case, the
new requirements could be rewritten:
Requirement 5.3: While the door is SHUT, when
BOPEN is pressed, the door becomes OPEN.
Requirement 5.4: While the door is OPEN, when
BCLOSE is pressed, the door becomes SHUT.
The requirements may now become quite complex to
write and difficult to read as more states and constraints are
added to the system behaviour. These problems arise from
the fact that the “missing” information in the requirements
is needed to formally specify the system. At some point
in the transition between the informal and the formal
definitions, those details need to be supplied. It is a
decision of the requirements team whether to implement
the intelligence to resolve these issues in the tool, or require
the user to be more thorough at the natural language level.
6. Using Graphical Input
Graphical notations can be used to convey behavioural
information in a concise and intuitive way. For complex
behaviours, a graphical representation is usually more
understandable than its natural language equivalent. From
an aesthetic point of view, a requirements specification
that contains both textual and graphical information is
also more visually motivating to the reader. For these
reasons, we decided to enhance Borg with graphical input
capabilities.
The approach we took was to implement an additional
front end to allow the definition of requirements in the
form of labelled transition systems (Figure 4). Our system
parses requirements defined using the Dot language of
the Graphviz toolkit [19]. Transition systems are quite
intuitive, and their translation to process algebra is straight-
forward.
3.5
Natural
Graphical
Language
Requirements
Requirements
Borg
Process Algebra
(Concrete Syntax)
Fig. 4. Adding support for graphical requirements to Borg
7. Example
We now present an example which illustrates the re-
quirements modelling process described in Section 5. Con-
sider modelling the software requirements for a lift system
(LS) consisting of a Door Module (DM) and a Lift Module
(LM), which control the behaviour of the door and lift
respectively. The DM can be in the OPEN state or in the
SHUT state, and the LM can be in the MOVING state or
the IDLE state. Using a top-down approach, the following
requirement relates the lift system to its components:
Requirement 7.1: The lift system is composed of the
door module and the lift module.
Structural requirement 7.1 represents an implicit defi-
nition of the full system behaviour. It indicates that the
behaviour of the lift system can be obtained by combining
the behaviours of the door and the lift modules.
Before the first requirement can be used by the tools,
some configuration has to be done. Domain specific terms
are entered in the system glossary. Lift system, door module
and lift module are all added along with their acronyms LS,
DM and LM. Cico and the graphical requirements parser
use the glossary to identify important terms and convert
them to appropriate tokens in the parse trees. Once this
step is completed, the requirement is parsed, and the parse
trees are generated.
Requirement 7.1 is expressed in process algebra using
the composition operator. Composition is an operator that
defines behaviour in terms of other behaviours. The full
lift system behaviour can be obtained by expanding the
composition. Of course, before this can be done, we need
to write the requirements for the DM and the LM. Their
initial states are straightforward:
AWRE’04 9th Australian Workshop on Requirements Engineering
OPEN command
SHUT OPEN
CLOSE command
Fig. 5. Graphical requirement for the Door Module
Requirement 7.2: The DM state is initially SHUT.
Requirement 7.3: The LM state is initially IDLE.
These requirements do not correspond to any Circal
processes by themselves, but serve to introduce the SHUT
and IDLE states to the modeller and relate them to the
DM and LM. Upon occurrence of events, DM and LM
will respond differently. The door module can be specified
in the following way:
Requirement 7.4: When the DM state is equal to SHUT,
upon receipt of the OPEN command, the LS shall set the
DM state to OPEN.
The event that correspond to the door opening is identi-
fied by the term “OPEN command”, and needs to be added
to the glossary. This process of refining Cico’s configura-
tion according to the specification format corresponds to
step B in Figure 3. A similar requirement is needed for the
CLOSE command:
Requirement 7.5: When the DM state is equal to
OPEN, upon receipt of the CLOSE command, the LS shall
set the DM state to SHUT.
In larger projects it can be seen that specifying such
types of requirements can be quite repetitive and suscepti-
ble to clerical mistakes. An alternative way to define these
is simply to represent them as a graphical requirement, as
shown in Figure 5.
The LM can be defined by a similar graphical construct,
using the IDLE and MOVING states and the MOVE
and STOP commands. Borg translates the behavioural
requirements for the DM and LM to equivalent constructs
in process algebra: processes. A process represents the
behaviour of a particular component in a system, and can
be combined with other processes using the composition
operator.
The requirements presented so far are sufficient to
specify the model of the system. Borg generates a Circal
process algebra model expressed in the concrete syntax
used by the Nova tool. Nova implements the semantics of
the composition operator, so it is possible to derive the
resultant behaviour of the lift system from the model. In
this way, we are able to build the system specification as
the composition of the set of requirements in a similar
fashion to what Dromey proposes in [20]. We consider
that our process algebraic representation and Dromey’s
behavioural trees are alternative approaches to the con-
3.6
struction of system models. However, his approach seems
to require considerable human input in the construction of
the behavioural trees.
The final process algebra model for our system can be
quite easily represented in graphical format using transition
diagrams. Figure 6 shows the behaviour of the lift system.
This specification of the lift system presents a problem
since it allows the lift to move while the door is open.
Additional requirements need to be created to prevent this
condition from occurring. The appropriate natural language
requirements are:
Requirement 7.6: If the LM state is equal to MOVING
the LS shall not allow the OPEN command.
Requirement 7.7: If the DM state is equal to OPEN the
LS shall not allow the START command.
Requirements 7.6 and 7.7 add constraints to the lift
system by relating states and transitions from both lift and
door modules. It is possible to represent such constraints in
process algebra by using processes [18]. Borg identifies the
parse trees generated by these requirements as constraints,
and generates the appropriate processes for them. The re-
vised behaviour of the lift system is obtained by composing
together the process representations of the requirements
and the process representations of the constraints. This
time, the lift system is free of the moving/open problem
identified earlier, as can be seen in Figure 7.
An important point to make about the analysis step of
the modelling process is that it really consists of evaluating
the formal model from a “real world” perspective to judge
its usefulness. In this example, it corresponds to reaching
the conclusion that “lift moving” and “door open” were
not desirable at the same time. It reinforces the need for
human interaction during requirements engineering, even
when some of the steps are automated.
8. Conclusion
We introduced Borg, a framework for the assisted gen-
eration of formal Circal models based on natural language
and graphical requirements. The motivation for this work
is:
START command
SHUT * IDLE SHUT * MOVING
STOP command
OPEN CLOSE OPEN CLOSE
command command command command
START command
OPEN * IDLE
STOP command
OPEN * MOVING
Fig. 6. The lift system process
AWRE’04 9th Australian Workshop on Requirements Engineering
START command
SHUT * IDLE SHUT * MOVING
STOP command
OPEN CLOSE
command command
OPEN * IDLE
Fig. 7. The revised lift system process
• Maintain intuitive and simple software requirements
documentation that is accessible to non-technical
parties involved in a software project.
• Create a simplified and more automated process
for generating formal models from a set of natural
language requirements, without removing the human
cognition aspect from the activities involved in re-
quirements engineering.
• Facilitate the use of natural language and transition-
system based requirements in requirements engineer-
ing activities, still taking advantage of formal meth-
ods for modelling and reasoning.
To build Borg, we reused the ideas behind Circe’s
architecture. We used Cico as the natural language parser
front end for textual requirements, and developed a series
of tools that can identify different types of requirements
written in natural language and convert them to equivalent
definitions using process algebra. The output of the tool
can be directly used by the Nova Circal implementation
to manipulate and verify the formal models. Borg also
includes a parser for the Graphviz Dot language, which
allows graphical and natural language requirements to be
mixed in software requirements specifications.
Although the current tool implementation supports only
requirements that represent transition based systems, its
architecture does not preclude the implementation of dif-
ferent modellers, projectors and translators to support other
formal methods.
From a feasibility point of view, the tool presented here
shows that it is possible to achieve the goal of generat-
ing formal models from natural language and graphical
requirements. It is important to note however, that a more
thorough practicality analysis is still needed to assess the
level of effort required to adapt the tool to different projects
and domains, and to do that a set of appropriate metrics
also needs to be defined.
We envisage that one possible extension to this frame-
work could be the construction of a tool to re-express
process algebra in natural language, to simplify the analysis
of formal models produced by Borg. A comparison of
the original natural language requirements with the ones
3.7
translated from the model could assist in the verification
of correctness of the model.
References
[1] B. W. Boehm, Software Engineering Economics. Prentice Hall,
1981.
[2] M. Dorfman, “Requirements engineering,” in Software Require-
ments Engineering, 2nd ed. IEEE, 1997, pp. 7–22.
[3] J. A. Goguen and C. Linde, “Techniques for requirements elicita-
tion,” in Software Requirements Engineering, 2nd ed. IEEE, 1997,
pp. 111–122.
[4] P. Checkland and J. Scholes, Soft Systems Methodology in Action.
John Wiley and Sons Ltd., 1990.
[5] D. A. Peled, Software Reliability Methods. New York: Springer,
2001.
[6] S. Flake, W. Müller, and J. Ruf, “Structured English for model
checking specification,” in Methoden und Beschreibungssprachen
zur Modellierung und Verifikation von Schaltungen und Systemen
2.8.2. Berlin: VDE Verlag, February 2000.
[7] S. Flake, W. Müller, and J. Ruf, “Mapping of structured English
sentences to CCTL formulae,” C-LAB, Tech. Rep. 04/2000, Febru-
ary 2000.
[8] S. Flake, W. Müller, and J. Ruf, “An advanced visual capture
for model checking specifications,” C-LAB, Tech. Rep. 05/2000,
February 2000.
[9] R. Hähnle, K. Johannisson, and A. Ranta, “An authoring tool for
informal and formal requirements specifications,” in ETAPS/FASE-
2002: Fundamental Approaches to Software Engineering, ser.
Springer LNCS, R. D. Kutsche and H. Weber, Eds., 2002, vol. 2306,
pp. 233–248.
[10] OMG, OMG Unified Modeling Language Specification. Object
Management Group, September 2001, version 1.4. [Online].
Available: www.omg.org
[11] V. Ambriola and V. Gervasi, “The Circe approach to the systematic
analysis of NL requirements,” Università di Pisa, Tech. Rep. TR-
03-05, March 2003.
[12] T. DeMarco, Structured Analysis and System Specification. New
York: Yourdon, 1978.
[13] Z. Liu, H. Jifeng, X. Li, and Y. Chen, “A relational model for formal
object-oriented requirements analysis in UML,” in Formal Methods
and Software Engineering, ser. Lecture Notes in Computer Science,
J. S. Dong and J. Woodlock, Eds., vol. 2885. Springer, November
2003, pp. 641–664.
[14] W. Shen and S. Liu, “Formalization, testing and execution of a use
case diagram,” in Formal Methods and Software Engineering, ser.
Lecture Notes in Computer Science, J. S. Dong and J. Woodlock,
Eds., vol. 2885. Singapore: Springer, November 2003, pp. 68–85.
[15] S. P. Miller, A. C. Tribble, and M. P. E. Heimdahl, “Proving
the shalls,” in FME 2003: Formal Methods, ser. Lecture Notes in
Computer Science, K. Araki, S. Gnesi, and D. Mandrioli, Eds., vol.
2805. Pisa, Italy: Springer, September 2003, pp. 75–93.
[16] D. Harel, “Statecharts: A visual formalism for complex systems,”
Science of Computer Programming, no. 8, pp. 231–274, 1987.
[17] G. Milne, “Circal and the representation of communication, concur-
rency and time,” in ACM Transactions on Programming Languages
and Systems. ACM, 1985, vol. 7, no. 2.
[18] A. J. Cowie, “The modelling of temporal properties in a process
algebra framework,” Ph.D. dissertation, School of Computer and
Information Science, Faculty of Information Technology, University
of South Australia, 1999.
[19] E. R. Gansner and S. C. North, “An open graph visualization system
and its applications to software engineering,” in Software—Practice
and Experience, September 2000, vol. 30, no. 11, pp. 1203–1233.
[20] R. G. Dromey, “From requirements to design: Formalizing the
key steps,” in SEFM 2003 – International Conference on Software
Engineering and Formal Methods. The University of Queensland
– School of Information Technology and Electrical Engineering,
2003, pp. 2–13.
 AWRE’04 9th Australian Workshop on Requirements Engineering

TABLE I
Appendix
T UPLE TYPE DESCRIPTIONS
This section presents a more detailed view of the parse
Tuple type Description
trees generation and the modeller operation by showing DEPT A requirement that is composed of a
how requirement 7.4 is converted to Circal. relational operation (a condition) and
After processing a requirement, Cico produces a parse an operation that is the result of the
condition being satisfied.
tree representation in a T-model, as shown in Figure 8. RELOP In the example presented in this paper,
Nodes indicate tuple types, and leaves are terms used in RELOP is a relationship between a state
the requirement or specific commands introduced by Cico variable and a state description.
CONDRECEIPT A condition that becomes true when an
during the tree generation. Borg’s modellers use tuple types event occurs.
and terms to match and translate parts of the parse trees OPERATION A change in state.
into abstract models. Table I describes each one of the DOOP Indicates the execution of an operation
types used in this example. by an actor.
The modeller uses the following information to con-
struct the behavioural information in this case: DEPT

• The RELOP tuple is used to discover what is the RELOP DEPT

original state where the event being described by the

CONDRECEIPT tuple can occur. DM state is equal to shut CONDRECEIPT OPERATION

• The DOOP tuple contains information that relates this

open command DOOP

behaviour to its parent component, ie the Lift System.

• The OPERATION tuple is used to derive the desti- LS OPERATION

nation state, and the CONDRECEIPT indicates the

event occurrence that will take the process to that
SET DM state open

state.
Fig. 8. Parse tree generated by Cico from Requirement 7.4
The final generated process is depicted in Figure 9,
and as can be seen it is only part of the full behaviour OPEN command
shown previously in Figure 5. It is also the purpose of the
modellers to perform a second pass on the T-models to
SHUT OPEN
combine the various pieces of structural and behavioural
information into one complete abstract model. Fig. 9. Graphical representation of Circal process generated
from Requirement 7.4

c
Copyright 2004 Rubens Fernandes and Alex J. Cowie
The author(s) assign to AWRE and educational non-profit institutions a non-exclusive licence to use this document for personal use and in
courses of instruction provided that the article is used in full and this copyright statement is reproduced. The author(s) also grant a non-
exclusive licence to AWRE to publish this document on the AWRE web site (including any mirror or archival sites that may be developed)
and in printed form within the AWRE 2004 Proceedings. Any other usage is prohibited without the express permission of the author(s).

3.8