Newsgroup Article comp.web

1. What are use cases?

The essence of the use case model is to capture and/or structure user requirements of a new system, whether it is being developed from scratch or based on an existing system, by identifying all the big functional blocks (use cases) and by detailing all the scenario’s that users will be performing (within these big functional blocks) [Rosenberg & Scott 99]. The use case model helps the customer, users and developers agree on how to use the system [Jacobson et al 99].

A use case species a sequence of actions, including variants and extensions, that the system can perform and that yields an observable result of value to a particular (primary) actor [Jacobson et al 99]. 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. Actors have external goals and responsibilities. Actors may be people or computer systems. The system is treated as a single entity, which interacts with the actors. The use case will talk about sequences of interactions, and it will talk about variations in the sequences. The use case is related to one particular goal that one actor (called the primary actor) has towards the system. Other actors that are part of the use case, are called secondary actors [Cockburn 97].

A use case answers a question of the form, “How do I get money out of that banking machine?” You, the primary actor, have a goal, to get money out the system, which is that banking machine. There are a number of situations you could find yourself in. The use case collects them into one place. It breaks down your goal into subgoals, eventually individual message actions, plus the interactions between various actors as they try to reach that goal, or eventually fail to reach it. Scenarios and use cases go until goal success or abandonment.

A use case must be related to an end-user goal. Such an end-user goal (‘to move from floor 2 to floor 4’) might involve various actions (push the ‘upwards’ button; a lift, ringing a bell, arrives; enter the lift…).

An actor represents a role a user can play. The same person could play different roles.

It is important to identify the full range of use cases, e.g. including administration and set-up activities.

Use cases are usually associated with a user manual style of describing functionality. So, use cases are typically related to end-user required functionality (or goals). Still, and in particular to make HOORA appropriate for real-time aspects, we have extended use cases [Awad et al 96] to also cover the autonomous activities, i.e. internal activities in the system not explicitly requested by a user of the system.

Use case diagram elevator example

Use cases are entities that have a clear meaning in user terms. This makes use cases an ideal candidate to plan the project as a set of iterations, where each iteration is defined by the set of use cases that will be supported. So, in user-oriented terms, the project is planned in terms of a set of observable external goals. The project follow-up is also structured around these observable external goals.

[back to top]

2. What is the form of a use case model?

A use case diagram shows the actors and use cases with a so-called communication association between each interacting pair of actor and use case [Jacobson et al 99]. In UML, it is also possible to have, in addition, relationships between use cases. Because there is considerable controversy on this issue, we advise not to use relationships between use cases, or to restrict ourselves to very simple relations (e.g. use case A ‘uses’ use case B). We choose not to specify whether this implies that use case A always calls use case B, or may call use case B only in particular circumstances.

Use cases have a lot more information than what is represented on the diagram. A standard template needs to be filled in for every use case. An example is given, taken from [Cockburn 97].

We can also add additional information to use cases, exploiting their usefulness to organize the project around use cases, e.g. to monitor progress or to plan project increments.

Use case 5	Buy goods
Goal in context	Buyer issues request directly to our company, expects goods to be shipped, and to be billed.
Preconditions	We know buyer, address, etc.
Success end condition	Buyer has goods; we have money for the goods.
Failed end condition	We have not sent the goods; Buyer has not spent the money.
Primary actor	Buyer, any agent acting for the customer.
Secondary actors	Credit card company, bank, shipping service company
Trigger	Purchase request arrives.
Description	Step	Action
	1	Buyer calls in with a purchase request.
	2	Company captures buyer’s identification information.
	3	Company gives buyer information on goods, prices, delivery dates.
	4	Buyer signs for order.
	5	Company creates order, and ships order to buyer.
	6	Company ships invoice to buyer.
	7	Buyer pays invoice.
Extensions	Step		Branching action
	3a		Company is out of one of the ordered items: [3a1, renegotiate order]
	4a		Buyer pays directly with credit card: [use case 7, take payment by credit card]
	7a		Buyer returns goods: [use case 12, return goods]
Variations	Step		Branching action
	1		Buyer may use phone, fax, web order form, electronic interchange.
	7		Buyer pays by cash or money order, check, credit card.
			Use case template: an example [back to top]

3. Use case guidelines

We find the use cases by looking at how the users need to use the system to do their work. Such a goal-based way of identifying the use cases is preferable [Jacobson et al 99] [Cockburn 97].

Parts of the remainder of this section are taken from [Awad et al 96].

A recommended practice for finding the use cases of a system, is to consider all external agents that interact with it. These agents may be humans or other computers. While interacting with the system, each agent may play different roles. An agent playing a role is called an actor. Since the role determines the context of usage, use cases are associated with actors. Therefore, start by finding all external agents and try to distinguish their roles. Then consider their roles one by one.

Actors can be classified in several ways:

Active/passive: some actors participate in use cases, but they never initiate a use case; these actors are called passive.
Primary/secondary: see above
Client/non-client: actors either use the system for a certain purpose, or they just affect it by sending some trigger.

Once actors have been identified and classified, consider each of them separately. Primary active client actors should be considered first. Ask yourself:

What are their main goals?
When are these goals applicable?
What is the effect of fulfilling the goal?
What are the timing requirements?

Note that actors are roles, and not real systems or human beings. Use cases where several ‘actors’ can perform the same function, are usually incorrect. The typical remedy is to identify a common ‘role’ (i.e. ‘actor’) that the two ‘systems’ can fulfill.

A common error in identifying use cases is to represent individual steps, operations or transactions as use cases. A use case is a relatively large end-to-end process description that typically includes many steps or transactions, all related to the same goal [Larman 98]. Note that the main goal of the use case identification, is the preparation of the scenario elaboration (see next Chapter). Use cases should, in most cases, not be decomposed into sub-use cases.

It is possible, although not very common, to introduce abstract use cases (that do not give a direct contribution to a user’s need, and/or that are not related to an end user’s goal) when factoring out commonalities between several use cases.

[back to top]

4. External event list

4.1 External event list: what?

The identification of goals (i.e. use cases) needs to be complemented by identifying the external interfaces required to achieve the goals. This is called the external event list. Such a list defines not only all the possible events, but also the expected system response, their arrival pattern (periodic or episodic), and the required performance of the system response [Douglass 99]. This information is important for subsequent real-time requirements identification.

Every external event must be attributable, to an external actor, to an internal clock, or to a triggering use case. Dependencies among event/response pairs are identified, and grouped together in use cases.

We collect the following information for every external event [Ellis 97]:

§ External Event: a “happening” that occurs outside the system at a definable instant in time and to which the system must respond. System start-up and time-based events are considered External Events for requirements analysis purpose, regardless of their specific implementations.

§ Trigger: the external actor, internal clock or use case triggering the external event.

§ Response: the structured sequence of activities that the system is required to perform when the corresponding external event has been detected by the system.

§ Performance: specific performance requirements (e.g., responsiveness, maximum latency, throughput, etc.) associated with the corresponding event/response pair are documented.

§ Arrival pattern: the manner in which the system recognizes the corresponding External Event. It must be one of the following:

§ Directly Perceived Event (dir): an event that is immediately known to the system without the system having to perform any processing to distinguish it from other possible events (triggered by an external actor).

§ Indirectly Perceived Event (ind): an event that requires the system to analyze externally provided data to differentiate specific events or to determine the specific instant at which the event occurs (triggered by a use case).

§ Temporally Perceived Event (tmp): an event that depends on the passing of a period of time. Periodic processing is considered to be initiated by a temporally perceived event, as is processing that is initiated after a finite time delay (triggered by an internal clock).

§ Drives Event: when the external event drives another event, that event will not be recognized unless the external event has first occurred.

§ Driven By Event: when the external event is driven by another event, that event must already have occurred before the external event can be recognized. The absence of a prior occurrence of the “driven by” event inhibits the response to the external event.

§ Use case: identifies the use case dealing with the external event and serves to categorize the external events.

[back to top]

4.2 External event list: example

This example is taken from [Ellis 97].

External Event	Trigger	Response^[1]	Arrival pattern	Drives	Driven by	Use case
Periodic Nav timer lapse (DVS providing good data).	Nav Clock	Use groundspeed data from DVS to update computed current aircraft position. If ADS providing good data, use difference of groundspeed from DVS and airspeed from ADS to estimate current wind speed vector and set NavigationDataValidityStatus to “Normal”	tmp	reference to other events	reference to other events	reference to use case(s)
Periodic Nav timer lapse (DVS not providing good data, but ADS is).	Nav Clock	Use airspeed data from ADS with the current wind speed vector estimate to estimate groundspeed. Use the estimated groundspeed to update the computed current aircraft position. Set NavigationDataValidityStatus to “Backup”	tmp	…	…	…
Periodic Nav timer lapse (neither DVS nor ADS providing good data).	Nav Clock	Inhibit flight plan following and set NavigationDataValidityStatus to “Invalid”	tmp	…	…	…
Aircraft approaches current target waypoint, which is not the last waypoint in the active flight plan.	Crew Flight Plan Monitoring use case	Signal crew that waypoint is reached. Select next waypoint in the active flight plan as the new current target waypoint.	ind	…	…	…
Crew enters command to add/delete/edit a waypoint in the Waypoint View.	Crew Flight Plan Editor	If the waypoint is not part of the active flight plan: Make commanded change to the designated waypoint. Update the Waypoint View.	dir	…	…	…
…		…	…	…	…	…

External events list example

[back to top]

5. Activities and outputs

Identify the boundary of the system and the external actors
Identify use cases based on end-user (actor) goals and external event list
Prioritize the use cases
Identify and define the external event list (including the response information)
Detail the use cases (identify the basic scenario, variations and extensions)

The output of this activity is a set of use cases and use case diagrams, with textual information according to the templates shown above (use case description and external event list).

[back to top]

[1] In the response description, performance requirements need to be indicated as well, e.g. <50 ms response.

[back to top]