This page, part of a series on UML, describes what Use Cases are and how to use them to develop and test applications.
$45 The Object Advantage: business process engineering with object technology, by Jacobson, I., Ericsson, M. and Jacobson, A. Addison-Wesley, May 2001. Applies object-oriented technology to the business process engineering (BPR) model.
$35 Writing Effective Use Cases by Alistair Cockburn (name pronounced "Coburn") of usecases.org. Addison-Wesley, Oct. 2000. 270 pages.
$32 Practical Software Requirements (Manning Publications October 1, 1998) by Benjamin L. Kovitz gives a structure.
Software Requirements, 2nd edition (Microsoft Press February 26, 2003)
by Karl E. Wiegers presents a jargon-free introduction to the best practices in requirements
discovery, verification and validation.
$36 Mastering the Requirements Process (Addison-Wesley August 12, 1999) by Suzanne & James Robertson
$35 Software Requirements (Addison-Wesley, January 16, 2002) by Soren Lauesen
Use cases are useful for several reasons throughout the development life cycle:
Lines in a UML use case between an actor and the system represent a more abstract concept of relationship of communication, acquaintance, or inheritance.
A use case circle can be more than a user invoking an on-demand service that passively waits until called upon.
A Use case circle can be event-driven, which proactively notifies one or more subscribers when specific events occur.
Services that run on their own without formal invocation may be better represented as an (automated) actor rather than as a use case circle.
A sample of a generalization relation is of a business use case "Withdraw Cash". Examples of use cases Subordinate to it would be:
"Withdraw cash from ATM Machine".
Another sample of a generalization relation is of when different technologies are used to achieve the same ends:
"Register using website".
To identify extensions in your application, look through boundary values and states in your data, where a user may, while performing a business use case, optionally:
This sample use case diagram is from the Professional version of Microsoft Visio 2002 software. It's called a “Jacobson use case model” because use cases were popularized by Ivar Jacobson, one of the gurus who joined Rational corporation and defined the Unified Modeling Language (UML). This sample is within the “software” category because it is a widely accepted documentation protocol for Object Oriented design and programming.
A “scenario” results from sequencing interactions. A use case defines a collection of possible scenarios. A use case is a collection of scenarios, each with a different triggering event. The main course is the simplest scenario, the one in which everything goes right and goal is achieved without difficulty — all the subordinate use cases succeed. Alternative courses (and there can be any number of them) describe deviations from that basic course.
Use cases are one aspect of a complete design, described in this graphic from a pdf file named “Structure and Style in Use Cases for User Interface Design” at Larry Constantine's website:
Use cases should not assume or specify a particular user interface object, such as “push the start button” or “press the screen”.
Convert to active voice the verbs listed in Sample Action Verbs
Thus, typical sentences might look like:
Alistair Cockburn's template provides space for information that is filled out over several passes during the life of the project. An example is descriptions for failed Extensions to the use case.
|Goal in Context||a longer statement of the goal in context if needed>||Buyer issues request directly to our company, expects goods shipped and to be billed.|
|USE CASE #||a unique identifier assigned sequentially.||5|
|USE CASE NAME||the goal as a short active verb phrase>||Buy Goods|
|Scope & Level||what system is being considered black box under design> <one of : Summary, Primary Task, Subfunction>||Company / Summary|
|Preconditions||Conditions assumed to be true before execution of the UC.||We know Buyer, their address, etc.|
|Primary Actors||a role name or description for the primary actors who invoke the use case.||Buyer, any agent (or computer) acting for the customer|
|Triggers||the action upon the system that starts the use case.||purchase request arrives.|
|Frequency of occurrence||load demands from the UC.||150 daily|
|Special Requirements||The qualities and constrants of the UC.||-|
|Secondary Actors||other systems relied upon to accomplish use case.||credit card company, bank, shipping service|
|Stakeholders and their Interests||the implications, side-effects of the use case.||-|
|Failed End Condition||the state of the world if goal abandoned.||We have not sent the goods, Buyer has not spent the money.|
|Success End Condition||the state of the world upon successful completion.||Buyer has goods, we have money for the goods.|
|Open Issues||Any unresolved item.||-|
Related information to use cases:
|DESCRIPTION Steps and Action||Steps sequentially numbered, each with an Action description||MAIN SUCCESS SCENARIO
1. Buyer calls in with a purchase request.
2. Company captures buyer's name, address, requested goods, etc.
3. Company gives buyer information on goods, prices, delivery dates, etc.
4. Buyer signs for order.
5. Company creates order, ships order to buyer.
6. Company ships invoice to buyer.
7. Buyers pays invoice.
|EXTENSIONS Steps and Branching Action||Steps sequentially numbered, each with an Action description||
3a. Company is out of one of the ordered items:
3a1. Renegotiate order.
4a. Buyer pays directly with credit card:
4a1. Take payment by credit card (use case 44)
7a. Buyer returns goods:
7a. Handle returned goods (use case 105)
|SUB-VARIATIONS Branching Actions||
1. Buyer may use phone in, fax in, use web order form, electronic interchange
7. Buyer may pay by cash or money order check credit card
|Priority||how critical to your system / organization>||top|
|Performance||the amount of time this use case should take>||5 minutes for order, 45 days until paid|
|Frequency||how often it is expected to happen>||200/day|
|Channels to actors||e.g. interactive, static files, database, timeouts>||?|
|OPEN ISSUES||list of issues awaiting decision affecting a use case>||What happens if we have part of the order? What happens if credit card is stolen?|
|SCHEDULE: Due Date:||date or release needed>||release 1.0|
|Superordinate Use Cases:||Optional: name of use case(s) that includes this one>||Manage customer relationship (use case 2)|
|Subordinates||Optional: depending on tools, links to sub.use cases>||Create order (use case 15) |
Take payment by credit card (use case 44)
Your first name:
Your family name:
Your location (city, country):
Your Email address:
Top of Page