Use Case Scenarios - Patrick McDermott

Sometimes a Word is worth a thousand Pictures
The Use of Cases:
Use Case Scenarios
College of Alameda
[email protected]
Copyright © 2007 Patrick McDermott
Why I Recommend
• Scenario-Driven
• Can become Test Cases
• One Case—user did test cases B4 we started
– Wonderful!
– But never worked in another case
• Can become User Manual
• Better yet, can come FROM user Manual:
– “Write the user manual, then write the code.”
Words & Pictures
• Eventually Pictures fail, Words are Needed
• Pictorial diagrams become too complex
(e.g., trying to show every decision point
and path in an event-driven interface), and
don’t illustrate desired system functions
• Flowchart is no better than code
– Once you grasp it, you no longer need it
• Access Query no Better than SQL Code
• Like a storyteller with unnecessary detail
– It was 5 years ago, Or maybe 6. No, wait, it was
4½ years ago, or was it?
A Use Case has Scenarios
Requirements
Use Case
Use Case
Scenario
Program
Spec
Class
Class
Diagram
What’s a Use Case Scenario?
Use Case Scenarios are a powerful tool to specify
requirements, and can also serve as test case scenarios to assure
those requirements are met. They are often used as design or
coding specs. They can even evolve into the User Manual. Use
brainstorming techniques to help come up with Use Cases and
Use Cases Scenarios to better understand the problem.
A use case scenario is a specific example—an
instance of a use case. The sunny-day scenario is the
normal case: What happens if the user does exactly what
is expected and completes the transaction? The rainy-day
scenarios (of which there are usually many) are variations
on the use case (e.g., the user tries to perform a task for
which she isn’t authorized).
Scenarios
A complete path through a use case,
from the first step to the last, is called a
Scenario.
Most use cases have several scenarios,
but they always share the same user goal.
3 Audiences
Write your use cases in a way that
makes sense to you, your boss, and
your customers.—H1st OOA&D, p. 151
Check the Weather
UC Main Path
☼Sunny Day
Alternate Path
Rainy Day
– Optional Path
UC Formats
•
•
•
•
Simple, Step-based format
Focus on Interaction
When … Then
Can be
Paragraph
Table
Steps
• Numbers/Subnumbers
• Alternate too
Use Case Scenario
• Note that one use case is a collection of several
use case scenarios. A use case might be
Register Vehicle. Four scenarios:
Register New Vehicle, Register Outof-State Vehicle, Re-Register
Existing Vehicle, Register Stolen
Vehicle.
• We’ll use “step” to refer to the lower level items:
they are called steps on our diagrams and are
portrayed as boxes, but the individual workers
often call them tasks, or activities.
A Scenario
Worker Enters Time: Sunny Day Scenario
When…
Worker logs in
Worker selects Week
Worker selects Task
Worker enters hours for task
Worker indicates “Finished”
Worker logs out
Then…
System
System
System
System
System
System
displays current schedule
displays current schedule
displays task
edits task entry for reasonableness
edits schedule for reasonableness
informs Boss of completion
Objects
Schedule
Task
Task
Task
Instance
Use Case Instance
The execution of a sequence of actions in a specified use case.
An instance of a use case.
Loops in UC
• “Lots of times a use case has a set of steps
that need to be repeated, but there’s not a
standard way to show that in the cases. So
we just made one up!”—H1st OOA&D
• They put “the system repeats steps a-x until
complete.”
while Loop
• In reality, not a problem
Going
Along
Initialize
Test
Condition
true
while (condition)
{
DoSomething();
AlterControlVariable;
}
false
Wrap up
Do It
Alter Control
Go On...
Include & Extend
It’s “easy to spend a lot of time arguing
over whether a use case extends this use
case, or includes that one…but it’s really
not that big of a deal, and those keywords
should never distract from the overall
design process.”—H1st OOA&D

Download Report