Introduction

One of the central problems in system engineering is to model business processes accurately but simply. This is necessary because both users and designers need to understand what is being communicated: users need to 'own' their requirements for any future system, so that they can control development, and designers naturally need to be able to interpret any system description correctly. Every specification and process model is therefore a communication between people with very different backgrounds. The most natural way to ensure that a model is genuinely an expression of a shared understanding is to develop it co-operatively (Heron 1996). Complex modelling languages are unsuited to such communication and co-operation. Traditional approaches see business process modelling as a technical process which an engineer carries out on behalf of the users. Such approaches miss out on the vital grounding of the system engineering effort in the users' experience.

What is required, therefore, is an approach which is precise, but which has a simple enough syntax that users can intuitively and correctly grasp its models as expressions of their business processes. They must be able to contribute freely to the development of the models, for example by noticing and pointing out missing or wrongly ordered tasks.

Business processes may be carried out by people or by systems. In either case, the most basic possible model of a process is a sequence of activities or tasks (Graham 1996), performed in order to achieve a goal. But life and business is full of choices: events may dictate a change at any time.

A better model of a business process is therefore a structure which contains branch points. An exceptional case may lead to a secondary sequence of tasks which branches off from the primary sequence. There may be several alternatives available, each leading to a different set of subtasks; or there may be some subtasks which can, or must, be performed in parallel with each other. Finally, some tasks may recur, either periodically, or at irregular intervals, probably in response to events.

The resulting Task Model structure is a typed hierarchy (Simon 1996) of tasks, representing in compact form a large number of possible real-world scenarios. Different scenarios could be generated by choosing different combinations of parallel subtasks (if they are not all mandatory), or could execute them in different orders.

To formalise this concept, every path through a task model is a Scenario, one particular sequence of events that might occur in the real world also (such as interactions with a system, as defined by Cockburn 1997). A scenario in a task model is very similar to the Scripts (Schank 1977) used in artificial intelligence for planning. This is not surprising, as the job of making a plan for (say) a robot to execute a task is similar to the job of describing in detail what a task is.

The number of possible scenarios rises combinatorially with the number of branch points in the task model, so the generation of all possible scenarios, many of which share most of their steps, becomes an absurd approach. The approach taken here is therefore to avoid generating 'complete' sets of scenarios. Instead, a small but representative selection of interesting paths can be followed through the task model (or parts of it). In this way it is simple to achieve coverage while keeping the information load small and manageable.

Correctly stated user or business task models and scenarios are helpful throughout the development life-cycle to guide system specification, system and user interface design, as well as verification. An implication of this thinking is that, while scenarios are certainly useful during design, it is unwise to delay thinking about possible patterns of system use until design is already in progress. Patterns of use lie in the problem domain, and deserve to be documented as such before development begins.

The need for early investigation of scenarios is perhaps especially clear for user interface design, where devices (such as Wizards) can be created to assist users to go through common sequences of activities more or less directly derived from a task model. Other user interface design tasks, such as organising window contents, can also benefit from a clear understanding of patterns of use, including not only the commonest sequences but also a knowledge of the possible alternatives open to the user.

Where user requirements are organised into tasks that seem natural to users, or better, when the tasks are structured co-operatively with the users, then several desirable results follow.

• The users will tend to buy into the system engineering process.
• They will tend to behave as the owners of the requirements.
• They will tend to pay close attention to the structure and content of the task model.
• They will consider carefully the requirements that hang off the tree of tasks.
• In dialogue with the requirements engineer, they will force numerous iterative improvements to both structure and content.

This degree of co-operation and dialogue between users and engineers favours successful development. Older system life-cycle models such as the 'waterfall' sequence saw requirements iteration, and review meetings with users, as troublesome and costly. Co-operative task modelling, with suitable tool support, is a fruitful precursor to system development.

Representation

The Task Model consists of any number of Tasks. Each Task has 0 or more child Tasks. The name of the top-level task can be considered to be the overall goal, such as 'Introduce a Product'.

Each Task has a Name, which is preferably an English verb phrase to describe an activity in a natural way. Tasks can also have a Short Text (useful when diagramming the model) and a Description, which is a free text.

Each Task has a Type, chosen from the list, with the following meanings:

• Sequence (task consists of an ordered list of subtasks, all of which are mandatory)
• Alternatives (task consists of a set of exclusive subtasks, i.e. one must be chosen)
• Parallels (task consists of a set of non-exclusive subtasks, i.e. at least one must be chosen; if more than one is chosen, they may be executed in any order, including possibly simultaneously or at overlapping periods of time)
• Strong Parallels (task consists of a set of mandatory subtasks, but which may be executed in any order including possibly simultaneously or at overlapping periods of time)
• Link (task is a reference to another task, typically used to indicate a contingency procedure such as for shutting down a process, or to indicate a non-periodic repetition of a task such as the reworking of an incorrect process as detected by a test)
• Periodic (task consists of a sequence of subtasks which are repeated indefinitely at a definite frequency)
• Exception (task consists of a sequence of subtasks which are executed in response to an identified contingency, typically an event but potentially anything which can be expressed as a Precondition)

The first 5 of these are mutually exclusive (though a Parallels task can in principle degenerate into Alternatives if only one subtask can sometimes be chosen). Periodicity could be treated as an orthogonal attribute of tasks, so that a task could be (Periodic + Alternatives), for instance. In practice this (less common) effect can easily be achieved by composing a Periodic task which has just one child, an Alternatives task. Similar considerations apply to Exceptions, though in this case there is almost always a sequence of (recovery) activities: there is a strong advantage in keeping Exception Tasks simple, unambiguous and easy to follow given that by definition they occur in contingency conditions. It is easier to represent just one list of task types and in practice the decision to do so has worked well.

Each Task has an optional Precondition, which is a short text, but which can be configured in a standardised way if a tool is available. For example, in a Sequence of tasks, each task naturally has the default Precondition '<previous task> completed'. Similarly in a set of Parallels, each task has the default Precondition '<Parallels parent> started'.

Each task has a Priority, which may be Primary (the default), Secondary, Tertiary, or None. Prioritisation helps to focus attention on key areas, while allowing the modeller to describe tasks which are currently perceived as less important.

Each task has a list of zero or more Actors, which may be named roles such as Quality Assurance or Engineering, or which may be (sub-)systems of any kind (including hardware or software). External systems which can cause contingencies can also be listed as Actors. For example, 'Mains Power Supply' can usefully be treated as an Actor in some Exception scenarios involving computer systems (a likely Precondition for such an Exception would be 'Power fails').

Approach

This is not the place to discuss the nature of co-operative inquiry (Heron 1996), (Reason 1994), but as the method may not be familiar to many modellers, it can be very roughly summarised as a cycle of activities for a working group, running as follows:

1. A proposition is stated, discussed by the group, modified if need be, and agreed;
2. An action is taken to implement the proposition, and observes and records what happens;
3. The group engages with the experience, to see what happened in a new way;
4. The group reconsiders the proposition, makes sense of it, and prepares for another cycle.

In the case of a model-making venture, the modeller and the users (domain experts) co-operate in the making of a business model. The first proposition is to develop a certain type of model, with a particular scope.

The action may be for the modeller to conduct some interviews, for one of the users to draft a model, for the group to brainstorm some scenarios, and so on.

The third and fourth stages involve reflection and review. The third stage may consist of a meeting to review the resulting sketch of a model, in which everyone can feel free to comment and react. The fourth stage may be a detailed revision of the model. This leads to a second cycle, with a proposition to continue but perhaps with, for example, additional roles to be modelled.

Even from this brief description it can be seen that the approach is both precise and flexible: it has a tough core of essential structure, but can be adapted to suit many different situations.

It is possible to start a business process model in many ways, but the first model is always rough and ready. It is often most effective to encourage the users to present their own view of their processes; they may make simple diagrams or a slide show with bullet points. These tend to list the top-level processes of the most general scenario, and they also tend to ignore most of the possible branches and contingencies that can arise.

This model can then be discussed with other users in individual or small-group interviews. The modeller needs to facilitate the detection of missing items, as well as actual disagreements. From these, a rough first-cut task model can be constructed, showing the main possibilities together with some alternatives and (therefore) some branches.

The modeller and the users can then co-operatively pick out likely candidates for further refinement. For example, any task such as 'Review <the document>' clearly contains the seed of a branch within it: the review may pass or fail the document. Failure probably means either rework or cancellation: so the modeller and users can discuss whether either or both of these could occur at this point.

Similarly, any routine step such as 'Audit <the system>' or 'Monitor <the process>' is a likely candidate for being periodic: audits may be conducted annually; processes may be monitored much more frequently. The modeller can simply ask a user 'How often do you do this?' to get a definite answer as to the type of such a task.

The modeller can use branch points in the task model to discuss with the users whether the choices exhaust all the contingencies that may arise at this point; if not, additional tasks can be elicited. For example, the alternatives "Audit passed" and "Audit failed" may not in fact be exhaustive; the third option "Borderline score" may lead to a period of review and catching up before a repeat audit, whereas this option may be disallowed if the audit is simply failed. In practice, users quickly learn to ask these questions of themselves.

Once the model has been refined in this way, the model can be published to a wider group of users and modellers for comment and more formal review. The advantages of the co-operative approach have been discussed and measured by Heron and others, but in this context some possible advantages are:

1. more detailed modelling through greater user involvement;
2. more accurate modelling through greater user openness;
3. easier acceptance of change as it may be seen as coming from the group, not from outside.

A tool can be helpful in making a task model and scenarios derived from it accessible to users. Tools can also provide abilities not available by manual methods: for example, animating the task model, filtering it to draw attention to interesting parts of the model, calculating metrics, reusing previously observed patterns, and so on. A tool with all these capabilities, known as Scenario Plus, and based on the DOORS requirements engine, is freely available to interested process modellers from http://www.scenarioplus.com - feedback and suggestions for improvements would be welcomed.

The illustration below shows a fragment of a model of a Marketing process during animation. The tool user has decided to Go ahead with a product launch, and the tool is about to explore the strongly parallel (mandatory but non-sequential) activities involved in developing the launch strategy.

Animation proceeds interactively, the user choosing the desired path when an Alternatives Task is encountered. Animation helps to involve users in the model, and focuses their attention on the correctness of the choices which can be made while stepping through the model.

Each animation effectively generates a Scenario, a fully-determined path through the Task Model. Scenarios can be recorded by keeping track of animations, and saving each one to a file or database. These can then serve as the basis for acceptance test scripts, with the necessary addition of acceptance criteria. Scenarios are useful for giving the 'feel' of a process, and for deciding the scope of a future system.

The next illustration shows another advantage of using a tool, automatic filtering. The user has selected just one class of Actors in this case, 'Customers', and the tool has displayed only the tasks in which customers are involved (and their ancestors). Filtering facilitates discussion of specific aspects of a model.

Conclusions

This article has presented a simple approach, with tool support available, to co-operative development of business process descriptions as task models.

A task model describes the full range of expected uses of a system, including both normal and contingency operations. The result is a hierarchy which forms a natural starting-point for defining a system's scope and organising its requirements. Users can decide whether each task lies inside or outside the system's boundary. Each task inside the boundary names a (sub)section of the functional requirements, organised roughly in time-sequence.

There is a close relationship between business task models, their actors, and the scenarios that can be generated from them, and object-oriented system development concepts such as objects and use cases. However, task models have their own independent validity for business process description regardless of the subsequent development approach.

Task models are readily understood by both users and engineers. The approach to task modelling presented here aims to encourage open and balanced dialogue between modellers and domain experts, and so to contribute towards successful system development.

References

Cockburn, Alistair, Structuring Use Cases with Goals, http://members.aol.com/acockburn/papers/usecases.htm, 1997

Graham, Ian, Task scripts, use cases and scenarios in object oriented analysis, Object Oriented Systems 3, pp 123-142, 1996

Heron, John, Co-Operative Inquiry, Research into the Human Condition, Sage, 1996

Reason, Peter, Participation in Human Inquiry, Sage, 1994

Schank, R.C. and Abelson, R.P., Scripts, Plans, Goals and Understanding, Lawrence Erlbaum Associates, Boston, USA, 1977

Simon, Herbert, The Sciences of the Artificial, 3rd Edition, MIT Press, 1996 pp 59-72

(c) Ian Alexander 15 June 1998