Use Case Summary

1. Simple overview of the Use Case idea
WHY THE USE CASE?
by tcowles
8/17/2010
1

2. Some History
 1986
 Chernobyl Disaster
 Arnold marries Maria Shriver
 Ivar Jacobson creates visual modeling
 UML
 RUP
 Usage Scenarios  Usage Case  USE CASES!
by tcowles
8/17/2010
2

3. The Rock Problem
“Bring me a rock.”
You bring them a rock
“Well, I actually wanted a small rock.”
You bring them a small rock
“Well, yes, but I really wanted a small blue rock.”
You bring them a small blue rock.
“Thank you, but it needs to be spherical…”
Eventually you discover they wanted a blue marble!
by tcowles
8/17/2010
3

4. What the heck is a use case?
 A use case defines a sequence of actions
performed by a system that yields an
observable result of value to an actor.
 If the user does THIS, then the system
responds by doing THAT.
 Identifying use cases
 What are the tasks of each actor?
 Does the system supply the business with all of
the correct behaviors?
by tcowles
8/17/2010
4

5. Actors
 Someone or something that interacts with, or
uses, the system to achieve a desired goal.
 Examples of Actors:
 User – Insurance Agent, Underwriter, Clerk
 Non-Users – Policy Holder, Client, etc
 The system under discussion
 Another system outside of the system in focus
by tcowles
8/17/2010
5

6. Use Case Models –
Birds Eye View
Request Quote
View Policy
Check Submission Status
Customer (Policy Holder)
Agent
Add Pricing Credits
Underwriter
by tcowles
8/17/2010
6

7. The Dialog
 Use cases describe the dialog between the
actor and the system using non-technical
terms that users understand.
 This will allow the users to understand the
relationship between the actor and the
system.
by tcowles
8/17/2010
7

8. Flowing the Dialog
 Happy Path – The main flow or sequence that
is used to accomplish the objective of the use
case.
 Alternate Flows – A variation of the main
flow, may also result in a successful outcome.
 Exception Flows – Failure situation, the
‘Crappy Path’.
by tcowles
8/17/2010
8

9. Sample Use Case
by tcowles
8/17/2010
9

10. Writing the Use Case
 Avoid describing the UI elements
 Systems “present” data, “provide” options, and
“invoke” other activities.
 Users “select” or “choose” options or items.
 Data is often presented as a “List of ………”
 Give titles to sets of data like “Policy Information”
rather than referring to a “screen” or “form”.
by tcowles
8/17/2010
10

11. Don’t Design!
 Stay separated from the UI as much as you
can.
 Leave the creativity up to the developers and
engineers.
 Remember, its what we want to create, not
how we want to create it.
by tcowles
8/17/2010
11

12. Business Rules and
Requirements
Rules
Requirements
Use Case
by tcowles
8/17/2010
12

13. Requirements and Rules
 Business Rules and Requirements for that
specific use case are listed at the end of the
use case and describe how the system will
behave.
 Formulas for calculations
 Fields
 Behaviors
You may have many business rules! No worries…
by tcowles
8/17/2010
13