Supporting a Co-operative Requirements Engineering Process

Ian Alexander

Independent Consultant

1Abstract

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.

2Example 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.

3Goals 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.1Modelling 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 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.

Figure 1: Agent Model of PIPSEE

3.2Agent 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.3Goal 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.

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 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 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.

Figure 4: Goal Model Metrics Display

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.4Goal 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.5Animating 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.6Test Script Generator

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 / Original Object Number / Scripts from 'PIPSEE Goal Model' / Results
1 / ... / ... / 1 Scenario 'simple' / –-
2 / 21 / 5.1 / 1.1 Set Objectives / OK
3 / 18 / 5.2.2 / 1.2 Design Game / OK
4 / 19 / 5.2.1 / 1.3 Design Simulator / OK
5 / 17 / 5.2.3 / 1.4 Model the Process / OK
6 / 11 / 5.3.2 / 1.5 Supervise Game / OK
7 / 24 / 5.3.1.4 / 1.6 View Game Status / OK
8 / 14 / 5.3.1.1 / 1.7 Compose Message / OK
9 / 13 / 5.3.1.2 / 1.8 Receive Message / –-
10 / 12 / 5.3.1.3 / 1.9 Reply to Message / –-
11 / 26 / 5.4 / 1.10 Analyse Results / –-

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.

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 UML-style swimlanes diagram can show multiple paths, which might also be useful as an output of goal modelling.

3.7Test 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.8Experience

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.9Compatible 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.

4Discussion

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 much-publicised 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 object-oriented 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. Co-operation 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.

5References

[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 Reference Manual, com, 1999

[4] PIPSEE,

[5]Graham, I., Requirements Engineering and Rapid Development. Addison-Wesley, 1998

[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