The Rational Unified Process: An Introduction (3rd Edition)
IDENTIFYING USE CASES
It is often difficult to decide whether a set of user -system interactions, or a particular dialog or scenario , is one or several use cases. Consider the use of an ATM: you can walk up to the cash dispenser , insert your bank card, punch in your PIN, and then withdraw money, deposit money, check your balances , or transfer funds between accounts. Then you can get a receipt for your transaction and get your card back.
(For the moment, let's forget about multiple transactions.) Is inserting your ATM card, entering your PIN, and having it validated a use case? Does it provide value to you? Suppose you walked up to an ATM, inserted your card, and entered your PIN, and the machine told you that you correctly entered your PIN and then gave you your card back? Would you be happy? Of course not! We use the ATM to get money, transfer funds, and so on. Those are the things of value that the ATM does; those are its use cases: withdraw cash, transfer funds, deposit funds, and inquire into balances. Each use case includes the complete dialog, from inserting the ATM card to selecting the transaction type to getting the receipt and the return of the card.
Use cases emerge when you focus on the results of value that a system provides to an actor and when you group the sequences of actions that a system takes to provide those results of value. Another useful way of thinking about this is to consider that a use case fulfills a particular "goal" that an actor has, to be accomplished by the system. A very useful discussion of this method can be found in an article by Alistair Cockburn . [2]
[2] Alistair Cockburn, "Structuring Use Cases with Goals," Journal of Object-Oriented Programming , Sept. 1997 and Nov. 1997; see also: http:// members .aol.com/acockburn/papers/usecases.htm
It is important to keep the actions together so that you can review them at the same time, modify them together, test them together, write manuals for them, deploy them together, and, in general, manage them as a unit. The need for this approach becomes obvious in larger systems. It is different from a "functional decomposition" approach, in which you rapidly lose track of the value and purpose of each little bit of functionality. The reason for grouping pieces of functionality and calling it a use case is that you want to manage these pieces of functionality together throughout the lifecycle.