Supporting a Co-operative Requirements Engineering Process
Ian Alexander
Independent Consultant
iany@easynet.co.uk
1 Abstract
Experiences with a tool (Scenario Plus) which attempts
to support a co-operative requirements engineering
process are described. The tool creates, edits, and
measures agent interaction models, goal models serving as
requirements frameworks, sets of scenarios, and sets of
test scripts. Each product is valuable in itself, and also
helps to generate the next product. Both object-oriented
and structured design can follow.
2 Example Project
Scenario Plus aims to support co-operative [1, 2]
Requirements Engineering (RE) in many ways. Rather
than attempt to describe all of these – a task already
performed by the user guide [3] – this paper illustrates
how the approach works in an industrial research project.
The project, Product Introduction Process Simulation in
the Extended Enterprise (PIPSEE) [4], aims to investigate
ways of bringing products such as aero engines to market
more quickly and efficiently, by simulating the product
introduction process. Many companies are involved, each
operating to their own standard procedures, in a relatively
long-lived but loose association described as an Extended
Enterprise. Improved co-operation is central to the project.
concerned with their interfaces. Some of the described
Systems may already exist.
External Agents may be human or machine, but are
considered to be outside the boundary of the problem to be
solved. They are introduced to make clear the context and
the external interfaces of the problem domain. If an
External Agent needs to be inside the boundary, it should
be reclassified as an Actor.
A Message is any communication between (a pair of)
Agents. It represents a complete conversation, a two-way
traffic for a single purpose, possibly over an extended
period of time. The message is not a dataflow from a
source to a target. Instead, the message has an initiator and
a recipient. Both are able to speak.
Scenario Plus [3] is an independently-produced add-on
for the DOORS requirements platform [6]. Three tools
operate on agent models: an editor, a metrics tool, and a
goal model generator.
3 Goals for Tool Support
Scenario Plus tries to support co-operative RE by:
representing users explicitly as agents;
representing communications between stakeholders
explicitly as messages;
 providing a visual structure for goals;
 providing easily-understood feedback.


3.1 Modelling Agent Interactions
From an informal list of objectives, modelling begins
by listing the Agents involved. The conversations in which
each Agent participates are represented as Messages. An
Agent Model says nothing about the sequence in which
interactions may take place. That is reserved for the Goal
Model.
The three types of Agent are, following Graham's
SOMA [5], Actors, Systems, and External Agents.
Actors are classes of people who play a role in solving
the problem. They can interact with any systems that may
be called for.
Systems are machines of any kind. No details of their
internal behaviour are given at this stage, as we are only
Figure 1: Agent Model of PIPSEE
3.2 Agent Model Tools
The Agent Model Editor is a basic graphics editor for
context diagrams (Figure 1). It is the only graphics tool in
the Scenario Plus toolkit that requires (or allows) the user
to position its icons. The diagram style is taken from
SOMA [5]. The style is deliberately minimalist, to
represent a first level of problem structure.
A simple set of checks on the agent model identifies
structural mistakes, and validates completed models. For
example, an error is shown if a message has no recipient.
3.3 Goal Modelling
A goal model describes a problem as a composition
hierarchy of goals and subgoals (e.g. [7, 8]). Scenario Plus
refines the classical approach by typing the goals to
indicate exceptions, and whether ANDed goals have a
specific order or whether parallelism is permitted.
Similarly, ORed goals may be strict alternatives (attempt
exactly one) or weakly parallel (attempt one or more).
Constraints can be documented with additional links.
The essential problem is stated as a single top-level
goal. A set of subgoals achieves its parent goal in a
manner which depends on the parent goal's type. For
example a "Strong Parallels" goal is achieved by
completing its subgoals in any order.
those from one External Agent to another) generates a goal
in the Goal Model phrased simply as "To Generate M".
This can be rephrased by hand if desired. For example,
given the interaction
Player  Message M  Simulator
in the Agent Model, the Goal Model initially contains
the following information:
ID: 1
Goal: To Generate Message
System: Simulator
Actor: Player
External Agent: none
High-level goals are broken down to make the
stakeholders' meaning clear to developers. A simple
stopping criterion (not sufficient) is that each leaf goal
must be carried out by at most one agent. The stakeholders
decide how best to break down each goal, and how far
such decomposition needs to proceed. Scenario Plus
creates a hierarchy of goals which are displayed (Figure 2)
for interactive navigation and editing with a specialised
tool (Figure 3).
The goal model generator gives all the 'root' goals that
it creates the default type, which is Sequence. This has no
immediate effect as they have no children at this stage.
The single top-level goal has these 'root' goals as its
children; it is given the type Parallels, implying that no
timing constraints are known and that any of the goals
might be required.
Figure 2 : Goal Model as Generated from Agent
Model, editing just starting
A skeleton Goal Model is generated automatically (as a
new DOORS module) in a single step from a completed
Agent Model. The tool creates traceability links between
Messages and (root) Goals, and between corresponding
Agents in the two models.
The Agents used in the Goal Model are entirely defined
in the Agent Model. Each Actor in the Agent Model
generates an Actor in the Goal Model, and similarly for
Systems and External Agents. A Goal can be associated
with any number of Actors, Systems, and External Agents.
Each message M identified in the Agent Model (except
Figure 3: Goal Model Editor
From this point on, goals can freely be split into any
number of subgoals of any type. Most people seem to
think in sequences: indeed, much of the thinking around
UML presumes sequences of steps. The requirements
engineer can prompt the stakeholders with the questions
for each goal such as:
a) Must this goal's children be a sequence? If not,
how are they related? This question helps to select
the correct type for the goal.
b) Can anything go wrong at this point? This
identifies events that could interfere with the goal,
and so to exception-handling goals, which can be
decomposed in turn.
c) Can this goal be met by a single action by a single
agent? If not, how can it be met? This question
helps to decompose goals.
Ideally, the preconditions of every goal are explicitly
stated. This is time-consuming, and for projects that are
not safety-related, not especially productive. A goal model
implies many preconditions: e.g. a subgoal in a sequence
has the precondition that the previous subgoal has been
completed. Scenario Plus fills in any such preconditions
automatically where user-supplied values are missing.
Each subgoal in a set of alternatives must be
distinguished by its preconditions. Exceptions are special
kinds of alternative: their preconditions must include the
event(s) that trigger each exception-handling subgoal.
There must be at least one alternative that is 'normal'; there
may be several exceptions.
The priority of each goal is recorded, to support
scoping and scheduling. The result of editing is a
hierarchical structure of goals for the future system.
3.4 Goal Metrics
Goal Models are tightly structured. The basic measure
of size is the number of leaf goals. This corresponds
roughly to the atomic transactions of Function Point
metrics. The percentage of leaf goals having a single Actor
hints at the completeness of the modelling effort, as it is
unlikely that a goal with multiple Actors is fully
decomposed.
Simple measures of model size are given by the number
of branch points, parallel points, and cycles, leading to a
McCabe-like absolute complexity metric [3]. Model
complexity increases rapidly with size, but relative
complexity (compensated for size) may help to predict
risks ahead. The number of scenarios is essentially
unlimited if there are loops in the model, but the minimum
number of 'interesting' scenarios can be estimated with
simplifying assumptions, such as that a loop may be
executed twice (at least). The metric may help to estimate
development and testing effort (Figure 4).
3.5 Animating Scenarios
Animation consists in following a legal path through a
goal model. The resulting path is an abstract scenario.
Scenarios need not begin at the beginning. Instead, a few
'complete' end-to-end scenarios can give the general
flavour; attention can then be focused on exceptions,
which are the most likely places for problems.
The rules of animation are derived directly from the
Scenario Plus goal types. E.g. an Alternatives goal consists
of a set of mutually-exclusive subgoals. So, a set of 3
alternatives requires (at least) 3 scenarios to provide
complete coverage. More detail of goal types is given in
[1] and [3].
A sequence of goals is deterministic, so path selection
during animation is automatic. With Alternatives or weak
Parallels, a free choice is provided in a menu. Options for
a set of weak Parallels include 'Random order' (simulated
concurrency) and 'Choose one'. A fault can be 'injected'
into a scenario by choosing the Exception goal which has
that fault as its precondition. As animation proceeds, the
current DOORS object changes, giving a visual impression
of progress.
The animator follows the animation rules to create a
specific generic (abstract) scenario from the goal model.
Scenarios can be recorded, replayed, and used to filter the
goal model as desired.
3.6 Test Script Generator
Figure 4: Goal Model Metrics Display
A test script is a generic scenario, annotated with
attributes for results and acceptance criteria to support
testing. A practical script normally consists only of
immediately executable steps. These trace back to leaf
goals in the goal model. Higher-level goals can optionally
be included, to reveal the context of a test step. All scripts
generated from a specific goal model are placed in a single
module.
Table 1 : A Test Script
ID Original
Number
1
...
2
21
3
18
4
19
5
17
6
11
7
24
8
14
9
13
10 12
11 26
Original Object
Number
...
5.1
5.2.2
5.2.1
5.2.3
5.3.2
5.3.1.4
5.3.1.1
5.3.1.2
5.3.1.3
5.4
Scripts from 'PIPSEE
Goal Model'
1 Scenario 'simple'
1.1 Set Objectives
1.2 Design Game
1.3 Design Simulator
1.4 Model the Process
1.5 Supervise Game
1.6 View Game Status
1.7 Compose Message
1.8 Receive Message
1.9 Reply to Message
1.10 Analyse Results
Results
–OK
OK
OK
OK
OK
OK
OK
–––-
Automatic generation and update of test scripts by
Scenario Plus represents a large saving of project effort.
For small projects, test results can be entered directly in
the DOORS scripts module (Table 1). For large projects,
test results are best kept in separate modules and traced
back to the scripts using links. This provides full
traceability to goals, and the approach can be extended
using the DOORS user interface or custom tools to trace
requirements and verification throughout the project.
UML-style swimlanes diagram can show multiple paths,
which might also be useful as an output of goal modelling.
3.7 Test Coverage Metrics
Comprehensive testing is well known to be impossible.
But given a goal model and a set of test scripts generated
from it, Scenario Plus test coverage metrics indicate, for
both leaf goals (nodes) and scenarios (paths), where
further effort is needed, and how "complete" the test
campaign will be for the set of test scripts as a whole.
These metrics can be prepared before system design
begins. Coverage of test scripts with test results can be
measured directly by filtering.
3.8 Experience
The simple examples of high-level work on the PIPSEE
project given here illustrate something of the style of the
Scenario Plus approach. The effort required to validate
large numbers of scenarios is considerable, but this is
normal for system verification. The simulator is now in
use by researchers and industrialists, and is proving to be a
versatile tool for gathering process knowledge. The
application of the requirements process has been relatively
small, but it has involved stakeholders with a wide range
of backgrounds.
The process has not been applied directly to model the
processes that PIPSEE is studying, as it was felt that the
industrialists needed traditional flowchart-style diagrams
to visualize process structure, and project-planner style bar
charts to visualize time-structure and dependencies in a
familiar way. The representations are partially
interchangeable, but e.g. flowcharts and GANTT charts
cannot easily show optional activities. The use of any new
notation in an industrial context, however simple it is felt
to be, has to be very carefully considered.
3.9 Compatible Design Approaches
Agent and goal models can both be viewed as object
models [5]. Similarly, scenarios and test cases are close to
Jacobson's generic use cases. Object-oriented design is
therefore a natural successor to goal modelling. Equally,
the goal model forms an ideal basis for structured analysis
and design. A single copy-and-link operation creates a
fully traceable skeleton System Requirements module.
4 Discussion
Figure 5: Part of an Agent-Sequence Diagram
A test script contains all the information needed to
generate a simple agent-sequence diagram (Figure 5) for a
scenario. Such diagrams are guaranteed consistent both
with each other and with the goal model, in marked
contrast with the UML approach which uses such
diagrams as input, though similar to SOMA's approach. A
The need to develop requirements more co-operatively
is becoming accepted, at least by researchers such as Potts
and Macaulay [5, 9, 10, 11]. Similarly, the need to match
requirements models with design approaches has led to
several object-oriented requirements methods, primarily
for software. Agent and Goal modelling are attracting
academic interest as precursors to requirements. Scenario
Plus puts these models to work in a simple and practical
way.
The closest object-oriented method is SOMA [5]. Its
first step is an Agent Model; its next step is to analyze
tasks, but it treats each task hierarchy as a separate
structure, so scenarios are purely local. Scenario Plus
constructs a single Goal Model, allowing scenarios to
animate and test any part of a model.
A much weaker approach is embodied in the muchpublicised UML. Jacobson's contribution was the idea of
the use case [12], a (usually) concrete instance of an
application of a future system. There are several major
problems with the idea of building a method directly on
use cases.
Firstly, it is unclear how use cases can form a coherent
system model. SOMA partially addresses this by providing
a context in the shape of an agent diagram; Scenario Plus
goes further by constructing a goal model on the agent
model's foundations.
Secondly, concrete use cases are repetitive, where an
abstract model is needed. Cockburn [13] suggests abstract
or generic use cases in a goal hierarchy, pointing towards
Scenario Plus, though without goal types.
Thirdly, UML is heavily oriented towards thinking
about solutions and software. Industrial workers [4, 14,
15] insist that it is essential to address problem before
solution. Graham trenchantly criticises UML for
encouraging design to be started too early.
Scenario Plus makes no assumptions about design
methods. Agent and goal models are both object models,
and scenarios are close to abstract use cases, so objectoriented design is a natural choice. Goal models are also
ideal for traditional requirements analysis, and subsequent
structured design.
A goal model provides a logical chapter and section
structure for user requirements with traditional 'shall'
statements. Most projects will also use attributes for e.g.
goal priority, review status, importance, and performance.
Mumford's ETHICS method [e.g. 16] pioneered the
involvement of 'users' on an equal footing, but did not
address specification methods.
Rapid (or Joint) Application Development [e.g. 10]
similarly fails to construct robust models to control
development. SCENiC [9] and USTM [10] encourage
collaboration, but without the benefits of goal models. Cooperation between stakeholders has been investigated
within the Co-operative Inquiry paradigm for many years
[e.g. 17, 18]. Scenario Plus is in the early stages of trying
to apply this to requirements engineering [1, 2].
The key tasks of a requirements toolkit are to enable
interactive construction of models, and consistent and
effective visualizations of these models. Stakeholders need
simple diagrams and animations; the requirements
engineer needs clearly presented metrics and traceability.
Notation is of little significance when people can simply
see how an animation behaves; people are the crucial
element in any process.
5 References
[1] Alexander, I., Engineering as a Co-operative Inquiry: A
Framework. Requirements Engineering (1998) 3:130-137
(Springer-Verlag)
[2] Alexander, I., Migrating Towards Co-operative Requirements
Engineering. CCEJ, 1999, 9, (1), pp. 17-22
[3] Scenario Plus, User Guide and
http://www.scenarioplus. com, 1999
Reference
Manual,
[4] PIPSEE, http://www.seg.dmu.ac.uk/pipsee
[5] Graham, I., Requirements Engineering
Development. Addison-Wesley, 1998
and
Rapid
[6] DOORS Reference Manual. QSS, Oxford Science Park,
Oxford OX4 4GA, 1993-1998
[7] Kendall, E., U. Palanivelan, S. Kalikivayi, M. Malkoun,
Capturing and Structuring Goals: Analysis Patterns, European
Pattern Languages of Programming, (EuroPlop'98), Germany,
July, 1998
[8] van Lamsweerde, A., R. Darimont, E. Letier, Managing
Conflicts in Goal-Driven Requirements Engineering, IEEE
Trans. on Software Engineering, Special Issue on managing
inconsistency in software development, Nov. 1998
[9] Potts, C., K. Takahashi, A. Anton, Inquiry-based
requirements analysis. IEEE Software 1994:11(2):21-32
[10] Macaulay, L., Requirements capture as a co-operative
activity. In IEEE international symposium on RE (RE'93), 4-6
Jan 1993, San Diego, CA
[11] DSDM, Dynamic Systems
http://www.dsdm.org, 1999
Development
Method.
[12] Jacobson, I., et al, Object-Oriented Software Engineering: A
Use Case Driven Approach, Addison-Wesley, 1992
[13] Cockburn, A., Structuring Use Cases with Goals, JOOP,
September and November 1997
[14] Stevens, R. et al, Systems engineering: coping with
complexity. Prentice-Hall, Englewood Cliffs, NJ, 1998
[15] Jackson, M., Software Requirements & Specifications.
Addison-Wesley, 1995
[16] Mumford, E., Defining system requirements to meet
business needs: a case study example. Comput. J 1985;28(2):97104
[17] Heron, J., Co–operative Inquiry: Research into the Human
Condition. Sage, Newbury Park, CA, 1996
[18] Reason, P., Participation in Human Inquiry. Sage, Newbury
Park, CA, 1994