Structuring Use Cases with Goals by Alistair Cockburn

18 different definitions of use case. Differing along 4 dimensions: purpose, contents, plurality, and structure.

Purpose: Is the purpose of use cases to gather user stories, or build requirements? (the values are stories, or requirements).

Contents: Are the contents of the use case required to be consistent, or can they be self-contradicting? If consistent, are they in plain prose or are they in a formal notation (the values are contradicting, consistent prose, formal content).

Plurality: Is a use case really just another name for a scenario, or does a use case contain more than one use case? (the values are 1 or multiple)

Structure: Does a collection of use cases have a formal structure, an informal structure, or do they form an unstructured collection (the values are unstructured, semi-formal, formal structure).

The one this paper develops is:

Purpose = requirements
Contents = consistent prose
Plurality = multiple scenarios per use case
Structure = semi-formal

Jacobson's form of use case: (requirements, consistent prose, multiple scenarios, semi-formal structure).

Communication Model

A use case is a collection of possible sequences of interactions between the system under discussion and its external actors, related to a particular goal.

Communication Model Relationships

A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance to satisfy its goal. One of the actors is designated as the system under discussion.

Each actor has a set of responsibilities. To carry out that responsibility, it sets some goals. To reach a goal, it performs some actions. An action is the triggering of an interaction with another actor, calling upon one of the responsibilities of the other actor (see also Figure 3). If the other actor delivers, then the primary actor is closer to reaching its goal.

An external actor can be a person, a group of people or a system of any kind. The internal actor may be the system in design, a subsystem or an object. The system in design consists of subsystems, which consist of objects. Actors have behaviour(s).

The top-level behaviour is a responsibility. It contains goals, which contain actions. An action triggers an interaction. The interaction is one actor's goal calling upon another actors (or its own) responsibility.

If the second actor does not deliver its responsibility, for whatever reason, the primary actor has to find another way to deliver its goal! This is marked as "backup action". Goals and backups to failed goals are, however, not captured in programming languages - they are written in the programmer's comments.

The system, now having its responsibility called upon, start along a hierarchy of goals and actions. Goals have sub-goals and alternative goals, down to the level of individual actions.

In the simplest case, an interaction is simply the sending of a message. .

An interaction also could be a sequence of interactions. This is a recursive definition (as in Figure 3). At the bottom level, it consists of messages. We sometime want to bundle a sequence of messages into a single interaction item. We refer to a sequence of interactions with one statement.

A sequence has no branching or alternatives. It therefore is used to describe the past or a definite future, with conditions stated. Such a sequence is known as a scenario.

For the purpose of describing a system, we need to be able to collect together all the scenarios that might occur during one interaction.

A collection of scenarios is a use case.

How do you know when to stop writing a scenario or use case? There are two clauses that have to be made explicit to get the proper bounds on a use case and a scenario. The clauses are the same for each:

Scenario. A sequence of interactions happening under certain conditions, to achieve the primary actor's goal, and having a particular result with respect to that goal. The interactions start from the triggering action and continue until the goal is delivered or abandoned, and the system completes whatever responsibilities it has with respect to the interaction.

The characteristic information for a use is:

1. Primary Actor or actors

2. Goal

3. Scenarios used.

The characteristic information for a scenario is:

1. Primary actor

2. Goal

3. Conditions under which scenario occurs

4. Scenario result (goal delivery or failure)

The scenarios are separated according to the conditions encountered, and grouped together as they have the same goal. The set of possible sequences is what constitutes system behaviour.

-----------------------------------------------------------

Figure 4. Sample Scenario

Scenario explosion is avoided using three techniques: subordinate use cases, extensions, and variations.

Variations is a section of the use case text, which takes advantage of semi-formal structuring within and across use cases. Often, a use case at a high level uses input or output of one of several types. An example is payment by cash, check , credit, credit card, or electronic funds transfer. The differences between all those possibilities will have to be described at some point in a lower-level, but it would be wasteful to spend the time doing so at the higher levels.

We used a place holder, called Variations to track at the higher levels variations we know will occur. This is superior to creating either a myriad of high-level use cases for all the differences or a false input or output medium that pretends to be any of the actual ones.

The step is a goal, of course, which might fail.

Sample Use Case(System: the insurance company)

d. by creation and payment of another policy

Each step in a scenario is a little use case!

 It is sometimes useful to distinguish the main course from the alternate courses. The main course is the simplest scenario, the one in which everything goes right and goal is delivered without difficulty - all the subordinate use cases succeed.

The other paths that lead to success are the recovery scenarios. The paths that lead to goal abandonment the failure scenarios. The recovery and failure scenarios are collectively the alternate scenarios.

The explosion of scenarios is prevented because a subordinate use case contains and conceals a possibly large number of alternative paths. Thanks to the recursive technique just described, at each point in the scenario, everything that might possibly happen next gets reduced to a single pair - the next subgoal succeeds, or it fails. All the conditions that force one or another recovery scenario in the subordinate use case are concealed within the use case and need not be dealt with there.

The outer scenario will name some conditions in the world, but ignore certain others. The inner use case's scenarios will introduce some new conditions that are relevant to those scenarios only. In other words, the list of conditions grows and gets more detailed as we proceed down the chain.

It is perhaps worth restating that the actors usually do not know the conditions of the scenario at the start.

There are three sorts of levels: The first level involves system scope or boundary. The second level involves goal specificity. The third level involves interaction detail.

The system under design has a primary actor having that goal. The boundary of the system under discussion here is the system being designed. The goal and the use case are at system scope.

That goal shows up in a larger system, usually the system that contains both people and the computer. Ideally, the goal shows up at the outermost edge of the project's control, the corporation (or organisation). Finding the outermost level at which the goal appears is valuable, since it (a) shows exactly how the goal should benefit the organisation, and (b) it is form most easily reviewed by the sponsoring executive.

It is the level at which the system goal shows up as helping the project sponsors meet their goals. The goal and the use case are at strategic scope. The goal is a strategic goal with respect to the system.

The second dimension of refinement is goal detail. This is the dimension using the recursive structuring described in the previous sections. It consists of summary goals, user goals, and sub-functions

The level of greatest interest is the user goal, the goal of the primary actor trying to get work done. This corresponds to what might be called "user task", or "elementary business process". A user goal addresses the question: "Does your job performance depend on how many of these you do today?"

Collections of user goals are summary goals. A summary goal may collect all of the user goals relating to product promotion, and be called, "Track promotions". These goals are useful for providing an index into a large set of user goals. Note that a user and summary goals may be written for the strategic scope or for the system scope.

A user goal may have a sub-goal that is also a user goal.

The summary goals fan out to user goals in the form of a tree (bush, actually), and the user goals fan out to sub-functions in a criss-crossed way, forming a graph. The picture of all use cases by goal detail looks a bit like a sailing ship (Figure 9). We sometimes talk about the user goals being at sea level (the level that constitutes the project), with the summary goals looking like the sails and the sub-functions coming back together under the water.

This lower level of interaction detail, when specific user actions, such as "tab forward" or" select from pull-down" list are named, are at the dialog interface level. It is better to stay away from the dialog interface level during requirements gathering. It is both time-consuming and subject to change when the final user interface is designed. The user interface design will address the dialog interface level.

Most people prefer to work at the outermost level practical, the semantic interface. In the address example, we would simply write, "enter address".

The reason for choosing this level is to preserve the most latitude in (a) implementing the interaction in different technologies (such as voice or electronic interchange), and (b) accepting variations of the data (accepting different address formats for various countries, in the preceding example). The level of interaction detail is consistent across project, at least for user-goals

Subfunctions are needed when there are some subfunctions that get used by a spread of use cases, and therefore must be tracked separately.

A useful sequence is to have the highest level use cases be strategic, summary goals, which decompose to system, summary goals, which decompose to system-level, user goals, which reference system-level sub-functions

Occasionally, people look at the definitions and examples of use cases in the literature and decide that use cases are just user interface (UI) descriptions. That is a valid interpretation from the definition of use case as "a sequence of transactions between external actors and the system." It is writing use cases at the dialog level of interaction.

There are two reasons to work a different way. Writing use cases just as UI descriptions deprives them of some of their value to the project. The design of the UI is likely to change too often for such writings to be used as contractual requirements and as system requirements. From the process or methodology perspective, the design of the UI comes later, after these goals and interactions have been named. Typically, a separate UI design team will come in, read the scenarios, and then play with different ways of presenting and collecting the information.

For those reasons, most people prefer to work at the semantic interaction level, describing just what information must pass the system boundary, without describing the sequence or nature of the interaction (without describing the dialog). To programmers, this corresponds to stating the parameters and result, as to a procedure.

Use cases written this way serve well as system requirements and as contractual requirements for the functioning of the system.

The use cases described in this paper have "semi-formal content" and "semi-formal structure". The purpose is to allow people to work quickly, with a variety of tools, and to allow them an escape hatch when the content or structure becomes too complicated.

The general form of the prose that works well is:

<time or sequencefactor>..<actor>..<action>..<constraints>

Thus, typical sentences might look like:

This keeps the narrative clear, improves traceability from requirements to design or test, and allows specific line references needed in the Extensions section.

The semi-formal structure allows the Variation section to be included. Since the variations are a list of input or output possibilities, a simple list for each suffices

The key terms to match to are use case, scenario, script, main course and alternative course. Others are uses, extends, and subordinate (for use case or scenario).

. For many people, a key factor of a "scenario" is the absence of alternatives, which this paper's use of scenario preserves.

"A set of possible sequences that succeed or fail to deliver the goal" corresponds very closely to Jacobson's use cases. The extension of Cockburn is explicit capturing of the goal.

"Script" is a term from Object Behaviour Analysis. A script corresponds closely to what is called here a scenario. An OBA script differs mostly in some details of its formalism and its historical roots. OBA scripts allow alternatives, but that is mostly a syntactic variation, introduced to control the scenario explosion in a different way. Using the characteristics of the first section of the paper, OBA scripts are (requirements, formal content, multiple scenarios, formal structure).

Lower-level use cases are called "subordinate", the inverse of which is "superordinate" or "higher-level". Jacobson distinguishes the "uses" from the "extends" relation between use cases. I do not distinguish them in this paper, but in writing, the difference shows up .

Every line in a scenario names either a primitive action or a "subordinate" use case. This is the "uses" relation.

To save writing, rather than repeat the common part of a previously described scenario, it is useful to collect all the alternate courses under the heading "extensions". Each extension starts by stating where it picks up in the main narrative and what conditions are different. It then contains some lines and reverts back to the main narrative, or runs to completion on its own (for instance it might fail or complete a different way). This is exactly Jacobson's "extends" relation.

A "used" use case is a single line item in a scenario, which refers to another use case (a subroutine call). An "extension" is another scenario that refers to some point inside the scenario.

1.The difficulty with levels:

May be inherent with this way of building requirements. As was saw, there are three different ways of refining goals, which is an awful lot of complication. Introducing the terms "strategic goal", "summary goal", "user goal", "sub-function", "essential interface" and "dialog interface" helps somewhat, but not totally. Perhaps it is because these terms are still new that there is still discomfort, but mainly because the technique is multilevel, and there is not a lot one can do about that.

Drawing the picture of the use cases is useful, to help avoid some of the confusion with levels. In the picture, all the user goals are placed at the same level to connote that level that is of value to the users. As mentioned, some user goals are also sub-goals of other user goals, so not all of the user goals will, in fact be at the same level.

2.Working with data format variations

In the structuring technique described in this paper each subordinate goal case carries forward the list of variations, until it is time to break them out into their own use cases. This works, but is still a bit unsatisfactory and ad hoc.

[RG92] Rubin, K, and Goldberg, A. "Object Behavior Analysis", in Communications of the ACM, vol. 35 no. 9, (Sept. 1992).

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

[W90] Wirfs-Brock, R., Wilkerson, B., and Wiener, L., Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs, NJ, 1990.

Instructions:

1.Read the accompanying Case Study and analyse the system for Use Cases.

2. Pick out Actors of the System.

3.Then use the actors to find high-level use cases with the user goals involved and short descriptions of the normal usage of the case.

We will then have a discussion of these found cases.

4. We will then elaborate the Use Cases to add steps and detail of pre-conditions and goals.

Another discussion will centre on these descriptions.

5. We will then add the variations possible to the standard Use Cases and the extensions.

6. We will also add some related information on performance and usage profile.

7. Finally we will examine the resultant Use Cases to see whether the uses and extends relationship can be invoked to create separate subordinate Use Cases.