Supporting a Co-operative
Requirements Engineering Process

Ian Alexander

Requirements Engineering Process Workshop, Florence, 1999;
Proceedings of the 10th International Workshop on Database and Expert System Applications (DEXA'99), IEEE, 1-3 September 1999, 340-344

Summary

A requirements engineering method that incorporates best practice but differs significantly from other approaches, is introduced. The approach uses Co-operative Inquiry and goal modelling, supported by a specially-made toolkit, to enable a group to describe a problem simply but accurately. The process is carried out by a group of stakeholders, facilitated by a requirements engineer. The group generates in turn a set of collectively agreed objectives, an agent interaction model, a goal model which can serve as a requirements framework, a set of scenarios, and a matching set of test scripts. Each product is valuable in its own right, and also helps to generate the next product. The subsequent design approach is not constrained; both object-oriented and structured design can follow on from the described process.

Objective

The purpose of this paper, and of the approach that it describes, is to encourage a style of requirements engineering that is both precise and practical. By precise, I mean that it handles human interactions well, and represents problems clearly. By practical, I mean that it enables stakeholders to work together to specify and get systems that solve their problems.

A Supported Method

Figure 1 is an Agent Model illustrating the principal tools (shown as 'black boxes'), agents, and communications (including the principal models) involved in the proposed Requirements Engineering approach.



Figure 1 : Agent Model of System Development

Co-operative Inquiry

Co-operative Inquiry, devised by John Heron and Peter Reason, is a general method of organizing a group to work out a collectively agreed understanding of a problem [Heron 1996, Reason 1994, Alexander 1998, 1999]. The approach calls for a group of participants to be afforded equal status and to inquire into the problem in a cycle of four phases.

1. Proposition - the group propose and agree (by any method they choose) the next action they will take. Groups sometimes begin by taking the time to agree their own procedures, such as how they will vote on a proposition.

2. Action - the group (or the actionee) takes the agreed action. This might be to brainstorm a list of objectives, for instance. Ideally most actions are taken within the group, so that everyone is immersed in the development of the requirements.

3. Reaction - the group looks at the action and gives its immediate gut reaction to it. This step is important as it ensures that tensions do not build up in the group. All members of the group have full power to intervene if they feel oppressed, or if they notice that something is not being expressed. For example, some stakeholders may be reluctant to state their real requirements in the presence of senior colleagues or customers. It is essential for a problem to be solved that it is first described accurately.

4. Reflection - the group quietly reflects on what has been achieved by the action, and considers what else if anything needs to be done to complete the action, whether the result is correct (and what they in fact want), and what ought to happen next. This leads naturally round to phase 1: Proposition again. This step too is important, as it acts as a reality check: too much action, and a group can become impractical in its statement of wishes and intentions.

In requirements engineering, the Co-operative Inquiry facilitator, typically the requirements engineer, has of course a specific method in mind. The inquiry is convened specifically to provide a report about the inquiry domain, so it is formally a 'Propositional' as well as a 'Practical' type of Inquiry [Heron 1996].

It is for the stakeholders, however, to decide if they are ready to move on to the next stage at any time, or whether they want to repeat or extend a stage by taking further action. The requirements engineer acts as a resource of knowledge and skill (in the requirements domain) but is in no sense the organizer of the group. The other stakeholders are the source of the problem domain knowledge that defines what the group is aiming to do. Typically this means defining a problem so that a suitable solution - usually a new system - can be devised.

Setting the Inquiry's Initial Objectives

Every project must begin with at least an informal idea of its objectives. Setting the initial objectives is an ideal start to a co-operative inquiry. The group can brainstorm a list of objectives in ten or fifteen minutes: there is no advantage in spending longer, as the important objectives are likely to be immediately obvious to stakeholders. The reaction and reflection phases on the objective-gathering should not take much more than an hour. It can be helpful to construct the list on a flipchart, and to display it on a wall for the group to refer to and refine as work proceeds.

Suzanne Robertson [Robertson 1997] describes the Requirements Engineering process as being like making a painting: the painter makes a sketch, or several sketches; works out important details; and then starts to construct a complete picture. A list of objectives can be reworked and revisited when the group finds it necessary. The objectives are certain to be modified, sharpened, and improved as the requirements become better understood. Rework means repeating a co-operative inquiry cycle.

Modelling the Agents' Interactions

From the informally described Objectives, the Co-operative Inquiry group can conveniently begin to analyse the problem they wish to solve by listing the Agents involved. The stakeholders in the group are themselves (ideally) representatives of each of the classes of Actor in the problem domain. The inquiry can therefore begin by having each stakeholder name the role that he or she plays, and define briefly what that role is. As each role is named, it can be written up for the group to see.

An Agent Model says nothing about the sequence in which interactions may need to take place. That analysis is reserved for the Goal Model.

Agents

The three types of Agent are [following Graham 1998] 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. Ideally the stakeholders in the Co-operative Inquiry group directly embody each class of Actor.

Systems are machines of any kind. No details of their internal behaviour are given at this stage, as we are only concerned with their interfaces. It is possible that some of the described Systems already exist but in general they may all be abstract, future machines.

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 it turns out that an External Agent needs to behave as if inside the boundary, it should be reclassified as an Actor. It is unlikely that many External Agents are embodied in the group, but all the external roles should be familiar to group members, since they interact with them.

Messages

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 is shown by its direction as having an initiator and a recipient, both of whom are able to speak. The conversation may consist of several exchanges of information.

Tool Support

The described approach is supported by the Scenario Plus toolkit [Scenario Plus 1999] which is an independently-produced add-on for the DOORS requirements platform [QSS 1998]. Three tools operate on agent models: an editor, a metrics tool, and a goal model generator.

Agent Model Editor

The Agent Model Editor is a basic graphics editor, used to construct Agent Models such as Figure 1. It is the only graphics tool in the toolkit that requires (or allows) the user to position its icons. The diagram style is taken from the SOMA method [Graham 1998]. The style is deliberately minimalist, as the intention is to represent a first level of problem structure.

Agent Model Metrics

Agent models should conform to certain rules, such as that actors may communicate only via messages. Instances of broken rules are detected and reported to the user.

Goal Model Generator

The skeleton of a Goal Model is generated automatically (as a new module) in a single step from a completed Agent Model. The tool also creates traceability links between Messages and (root) Goals, and between corresponding Agents in the two models.

Modelling the Goals

A goal model describes a problem as a composition hierarchy of typed goals and subgoals. 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 "Sequence" goal is achieved by completing each of its subgoals in strict order.

Importing the Agents

The Agents used in the Goal Model are entirely defined in the Agent Model. Each object of type Actor in the Agent Model becomes an Actor (able to carry out a Task to achieve a Goal) in the Goal Model. Similarly, Systems and External Agents are carried across into the Goal Model. Any Goal can be associated with any number of Actors, Systems, and External Agents.

Importing the Root Goals

To a very rough first approximation, the primary goals can be found simply by assuming that each of the messages identified in the Agent Model, except purely external messages (those from one External Agent to another), need to be generated.

Therefore, if there is a message X in the Agent Model, there is a goal "Generate X" in the Goal Model. It is a simple matter to allow the group to choose a standard verb, such as "Generate", "Issue", or "Produce", to indicate the nature of the relationship between messages and goals. Of course the resulting wording will sometimes be awkward. "Generate Goal Model", for instance, can be better worded with a little human intervention as "Model the Goals", but the meaning is clear enough.

Each message is connected to one or more agents in the Agent Model. These agents become the Actors, Systems, and External Agents associated with the goal generated from the original message.

For example, given the interaction

Planner à Menu à Cook

in the Agent Model, the Goal Model initially contains the following information:

ID Goal Actor System External Agent

1 To Generate Menu Planner --- ---
Cook

Goal Decomposition

High-level goals need to be broken down to make the stakeholders' meaning clear to developers. A stopping criterion (not always sufficient) is that each leaf goal must be carried out by exactly one agent. A leaf goal of this kind is described as 'atomic'.

It might be possible for a goal generator to attempt a preliminary decomposition of goals in this way. For example, "To Generate Menu" might consist of subgoals:

ID Goal Actor

1.1 To Send Menu Planner

1.2 To Receive Menu Cook

Unfortunately, the resulting rudimentary conversation is unlikely to be correct. It assumes, for instance, that the Planner has sole authority to create the menu, and that the Cook is a passive recipient.

An alternative conversation might be:

ID Goal Actor

1.1 To Request Menu Ideas Planner

1.2 To Suggest Menu Ideas Cook

1.3 To Select Preferred Menu Planner

1.4 To Confirm Selected Menu Cook

which perhaps makes better use of the actors' skills. Both decompositions could be valid in some circumstances, and both are probably typical patterns of interactive problem-solving. If so, these patterns can be stored in and retrieved from a library when needed.

The agent modelling phase is however not the place to try to decide what goal decomposition might be most appropriate (so as to set up rules for goal generation). Instead, the Co-operative Inquiry group decides how best to break down each goal, and how far such decomposition needs to proceed. The result is a hierarchy of goals which can be displayed and edited interactively (Figure 2).

Goal Typing

Different goals require different behaviours. Some sets of subgoals correspond to sequences of tasks; others to tasks that can be executed in parallel, or that must be repeated at regular intervals, and so on [Alexander 1998]. Most of the types are illustrated in Figure 2.

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. To avoid making any assumptions about their timing, the top-level goal is given the type Strong Parallels, implying that no timing constraints are known but that all the 'root' goals are assumed to be required.

From this point on, the Co-operative Inquiry group is completely free to split goals into any number of subgoals and to assign types. Most people seem to think in terms of sequences: indeed, much of the thinking around UML, some of which appears distinctly confused, is in terms of sequences of steps. The Co-operative Inquiry group can create and refine sequences through cycles of brainstorming Action and quieter Reflection.

The requirements engineer and stakeholders can then examine the goal model and ask the following questions for each goal:

1. Must this goal's children be a sequence? If not, how are they related? This question leads to the selection of the correct type for the goal.
2. Can anything go wrong at this point? This question leads to the identification of events that could interfere with the achievement of the goal, and hence to the description of exception-handling goals, which can be decomposed in turn.
3. Can this goal be met by a single action by a single agent? If not, how can it be met? This question leads to the decomposition of goals down to the atomic level.

The requirements engineer is not responsible for the answers that the group supplies: those belong to the stakeholders. However, it is appropriate for the engineer to apply experience to detect when questions are not being asked, and to attract the group's attention to parts of the model which seem incomplete, inconsistent or simply unrealistic.

A special sign to watch out for is the feeling that a stakeholder is avoiding speaking out on a definite goal because another stakeholder, typically a senior manager, might not wish to hear about it. All members of the Co-operative Inquiry group including the requirements engineer should be able to bring the situation to the group's attention for resolution. It is far better that requirements are expressed and prioritized at the start of the project. If the customer does not wish to pay for a specific requirement to be implemented, that is fine, but at least the goals should be evaluated rationally first.

Events & Preconditions

Ideally, the preconditions of every goal are explicitly stated. This can be quite time-consuming, and for projects that are not safety-related, not especially productive. A goal model makes many preconditions almost self-evident: for instance, a subgoal in a sequence has the precondition that the previous subgoal must be completed.

Other preconditions are more necessary. Each subgoal in a set of alternatives must be distinguished by its preconditions. An exception is a special case of an alternative: its preconditions must include the event(s) that trigger the need to create an exception-handling subgoal. There must generally be at least one alternative that is 'normal'; there may be several different events that need to be handled as exceptions.

Priorities

A key aspect of the negotiation of requirements between stakeholders and developers is the relative priority of each goal. The Co-operative Inquiry group is responsible for setting realistic priorities for each goal, so that when time and cost constraints intervene, good decisions about what to do, and when, can be made.

Required Behaviour & Constraints

Stakeholders' requirements have a natural relationship with goals. Each goal represents something that stakeholders agree they wish to achieve.

Tool Support

Three tools, apart from the tree diagram (Figure 2), support goal modelling: an editor, a navigator, and a metrics tool.

Goal Editor

The goal editor provides an editable view of all the immediately important attributes of a goal object, together with facilities to navigate to parent, child, and sibling goals.

Goal Navigator

Point-and-click navigation is possible both with the Goal Editor and with the underlying (customized) DOORS diagram or table views. The Navigator provides an alternative way of looking at the goal model, focusing attention on a single goal and its immediate subgoals in a way which emphasizes its behaviour. This behaviour will appear primarily during animation of scenarios, which is the next step after the creation of a goal model (see below). The Navigator allows behaviour to be explored and checked efficiently before animation begins.

Goal Metrics

Goal Models are tightly structured. The basic measure of size is the number of leaf goals. If the model is fully atomized, this corresponds to the atomic transactions of Function Point metrics. Therefore the percentage of leaf goals fully atomized (having a single Actor) is a measure of completeness of the modelling effort.

Model complexity increases rapidly with size, but relative complexity (compensated for size) may help to indicate unusual development risks ahead. The number of scenarios is essentially unlimited if there are permitted loops in the model, but the number of scenarios of interest to stakeholders can be estimated with simplifying assumptions, such as that a loop may be executed either once or twice (at least). This kind of assumption leads to a minimum number of 'interesting' scenarios. The metric may help to estimate the development and testing effort for a project.

Animation of Scenarios

Animation of a scenario consists in following a legal path through a goal model. Such a path can begin anywhere: it is not necessary to have every scenario begin at the beginning. For example, in the case of a domestic burglar alarm, practically every scenario begins with the householder activating the alarm and closing the main door. It is wasteful to test this part of the model many times over. Instead, the Co-operative Inquiry group can construct a few 'complete' end-to-end scenarios to give the general flavour, and then concentrate attention on the special cases and exceptions, which are the places where problems of design most often occur.

Rules

The rules of animation are derived directly from goal types. For example, an Alternatives goal consists of a set of mutually-exclusive subgoals. Therefore exactly one subgoal must be selected in any legal path which visits that goal. A set of 3 alternatives requires (at least) 3 scenarios to provide complete branch coverage. More detail of goal types is given in [Alexander 1998] and [Scenario Plus 1999].

Path Selection

A sequence of goals is deterministic, so path selection during animation can be automatic. In other cases, as with a set of alternatives or weak parallels, the Co-operative Inquiry group can make a free choice. For example, a fault can be 'injected' into a scenario simply by choosing the exception goal which has that fault as its precondition.

In the case of a burglar alarm, one likely scenario is that a fly buzzes inside the house, causing a sensor to detect movement and a possible intrusion. An important exception goal is to avoid treating this case as a genuine intrusion. It is disturbing that many alarms that do not handle this exception are still on the market. They cry wolf so often that the police are more likely to prosecute the householder for disturbing the neighbourhood than the burglar for intruding.

Tool Support

Scenario Animator

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.

When the rules afford a choice of alternative paths, a menu of the choices is provided. These capabilities make it easy either for a Co-operative Inquiry group to develop agreed scenarios together, or for an actionee to develop some scenarios off-line and to present them to the group interactively.

Test Script Generator

A test script is a generic scenario, annotated with attributes to support testing. The essential attribute is for the acceptance criteria that apply either to each step in a script, or to a script as a whole. A practical script normally consists only of immediately executable steps. These trace back to leaf goals in the goal model. It can sometimes be helpful to see also the higher-level goals involved so as to understand the context of a test step. All scripts generated from a specific goal model are placed in a single module.

The automatic generation and update of test scripts can represent a large saving of effort on a project. For small projects, test results can be entered directly in the scripts module (Figure 3). For large projects, test results are best kept in separate modules and traced back to the scripts. This provides full traceability right back to user requirements.



Figure 3 : Part of an Automatically-Generated Test Script

Agent-Sequence Diagram

A test script contains all the information needed to generate an agent-sequence diagram (Figure 4). Generated automatically, such diagrams are guaranteed to be consistent both with each other and with the goal model from which they derive. This is in marked contrast with the UML approach, though similar to SOMA's.



Figure 4 : Fragment of an Agent-Sequence Diagram

Coverage Metrics

Comprehensive testing is well known to be impossible [Dijkstra 1973]. Given a goal model and a set of test scripts generated from it, however, coverage metrics can indicate precisely where further effort is needed, and how complete the test campaign will be. Coverage of goals corresponds (at this high level) to the tester's "branch coverage", while coverage of scenarios is a form of "path coverage". These apply to the set of test scripts as a whole. Note that these metrics can be prepared before system design begins.

Actual coverage of scripts with test results can be measured directly by filtering on attributes (if results are recorded directly in scripts) or traces (if results are linked to scripts).

Compatible Design Approaches

Object-oriented Design

The agent and goal models can both be viewed as object models (see [Graham 1998] for a discussion of how to treat agents and tasks as objects). Similarly, scenarios and test cases are close to Jacobson's generic use cases. Object-oriented design is therefore a natural choice as successor to co-operative goal modelling with Scenario Plus. Several design tools are available with dynamic interfaces to DOORS: these maintain a 'surrogate' module in DOORS to enable direct traceability between requirements and design elements.

Structured Design

Equally, the goal model forms an ideal basis for a comprehensive requirements analysis – both of system functions and of the constraints that apply to the functions – and subsequent structured design. A single copy-and-link operation can create a skeleton System Requirements with complete traceability back to the goal model.

Discussion

The need to develop requirements more co-operatively is becoming accepted, at least by researchers [Potts 1994, Graham 1998, Macaulay 1993, DSDM 1999]. Similarly, the need to match requirements models with design approaches has led to several object-oriented requirements methods, mostly intended primarily (or entirely) for software.

Coherent Requirements Modelling

Perhaps the best of these, and the one closest to the Scenario Plus approach, is SOMA [Graham 1998]. SOMA's first step is an Agent (Object) Model; its next step is to analyze tasks. SOMA however treats each task hierarchy as a separate structure, so that scenarios are basically entirely local. Scenario Plus constructs a single coherent Goal Model, representing all the tasks – each being to achieve a (sub)goal. This has the advantage that scenarios can be created interactively to encompass, animate, and test any part of a model – whether that spans one 'root' task or many.

A much weaker approach is embodied in the much-publicised UML. Jacobson's contribution to object-oriented thinking was the idea of the use case [Jacobson 1992], a (usually) concrete instance of a particular application of a future system. There are several major problems with UML, inherent in the idea of building a method on use cases.

Firstly, it is unclear from Jacobson's writings how use cases are to be fitted together into a coherent system model. SOMA partially addresses this by providing a context in the shape of an agent diagram; Scenario Plus completes this movement by constructing a goal model on the agent model's foundations.

Secondly, the concreteness of use cases makes them repetitive, where an abstract model is needed to guide development. [Jacobson 1992], [Cockburn 1997], and others have suggested abstract or generic use cases as a partial solution. Cockburn's thinking on hierarchies of use cases points towards the Scenario Plus approach, though without its use of types to distinguish parallel, alternative, and other kinds of subgoal.

Thirdly, UML is heavily oriented towards thinking about solutions and software. [Graham 1998], [Stevens 1998], and [Jackson 1995] insist that it is essential to address the problem before the solution. Graham trenchantly criticises UML for encouraging software design to be started too early.

Scenario Plus makes no assumptions about design methods. Agent and goal models can both be viewed as object models, and scenarios are close to abstract use cases, so object-oriented design is a natural choice. But a goal model is also an ideal basis for a traditional requirements analysis of functions and constraints, and subsequent structured design. In fact, co-operative goal modelling is useful even when no development is planned: improved clarity and agreement on processes may be a successful outcome, or a precursor to business process re-engineering.

A goal model can be used simply to provide a logical chapter and section structure for a (user) requirements specification containing traditional 'shall' statements. In a requirements tool such as DOORS [QSS 1999], this seems like overkill, as the goals, if documented properly with suitable attributes, effectively describe what the users want without the need for 'shall's. Projects will differ as to which attributes they consider necessary, but most will want to define goal priority, review status, whether mandatory or not, performance and other constraints (Table 1).

ID	Goal	Actor	Review Status	Wanted in Phase	Performance	Importance
UR-46	To Activate House Alarm	Alarm Center Controller	Approved	1	within 30 seconds	Essential

Table 1 : Goals as the basis for user requirements

Co-operative Requirements Negotiation

The ETHICS method [e.g. Mumford 1985] pioneered the involvement of 'users' on an equal footing, but unfortunately did not really address ways of translating the group's understanding into an effective specification.

So-called Rapid (or Joint) Application Development approaches [e.g. DSDM 1999] similarly fail to construct models robust enough to control developers. SCENiC [e.g. Potts 1994] and USTM [e.g. Macaulay 1993] are good and practical ways of encouraging stakeholders to collaborate, but without the benefits of goal models or a proper foundation for the type of co-operation that is required.

Many projects have failed because the stakeholders ultimately did not assent to the solution being imposed, as they saw it, from outside their ranks. Others run into difficulties after initial enthusiasm for joint development when the project's complexity takes it out of control. The approach described here aims to close the gap by combining a robust and tested method of organizing groups, with a simple and practical requirements engineering approach, supported by a dedicated toolkit.

The key functions of a requirements toolkit are to support interactive (which means rapid, and reliable) construction of models, and to provide consistent and effective visualizations of these models. Stakeholders can readily understand simple diagrams and animations; the requirements engineer needs, in addition, clearly presented metrics and traceability, to check the state of a model. Notation is of little significance when people can simply see how an animation behaves.

The crucial element in any process is the behaviour of the people who are involved in it. Software can, at best, support such a process by remaining as inconspicuous as possible, and by reflecting the needs of the stakeholders and engineers at each stage.

References

Alexander, I.: Engineering as a Co-operative Inquiry: A Framework. Requirements Engineering (1998) 3:130-137 (Springer-Verlag)

Alexander, I.: Migrating Towards Co-operative Requirements Engineering. Computing & Control Engineering Journal, 1999, 9, (1), pp. 17-22

Cockburn, A.: Structuring Use Cases with Goals, JOOP, September and November 1997 (http://alistair.cockburn.us/crystal/articles/sucwg/structuringucswithgoals.htm)

Dijkstra, E.W.: Notes on Structured Programming, in Structured Programming. O.-J. Dahl, E.W. Dijkstra and C.A.R. Hoare, Academic Press, 1973

DSDM, The Dynamic Systems Development Method. http://www.dsdm.org, 1999 (a RAD method)

Graham, I.: Requirements Engineering and Rapid Development. Addison-Wesley, 1998 (SOMA method)

Heron, J., Co–operative Inquiry: Research into the Human Condition. Sage, 1996

Jacobson, I., et al: Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992

Jackson, M.: Software Requirements & Specifications. Addison-Wesley, 1995

Macaulay, L.: Requirements capture as a co-operative activity. In: IEEE international symposium on requirements engineering (RE'93), 4-6 January 1993, San Diego, CA (USTM method)

Mumford, E.: Defining system requirements to meet business needs: a case study example. Comput. J 1985;28(2):97-104 (ETHICS method)

Potts, C., Takahashi K., Anton A.: Inquiry-based requirements analysis. IEEE Software 1994:11(2):21-32 (thinking behind SCENiC method)

QSS: DOORS Reference Manual. Quality Systems & Software Ltd, Oxford Science Park, Oxford OX4 4GA, 1993-1998 (Requirements engineering platform, now owned by Telelogic)

Reason, P.: Participation in Human Inquiry. Sage, Newbury Park, CA, 1994 (Co-operative Inquiry)

Robertson, S.: ‘Putting the RAD in Requirements: Accelerating past impediments’, EuroSTAR’97, Edinburgh, 1997 (VOLERE template)

Scenario Plus: Scenario Plus! User Guide and Reference Manual. http://www.scenarioplus.com, 1999 (Tool Support for co-operative RE process)

Stevens, R. et al: Systems engineering: coping with complexity. Prentice-Hall, Englewood Cliffs, NJ, 1998 (industrial system engineering life-cycles)

Other Articles