Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Understanding Use Cases
Transcript of Understanding Use Cases
A Shift of Focus
Bringing it all together
Use Case Diagramming
How does the user accomplish a goal with our application or system?
First up... Use Cases
Made up of three main components:
Identifying the Actors
Anything that interacts with your system or app
Often a person, but not always...
With simple apps, you may have only one actor
Start with the actors... their interactions will lead you to the possible scenarios
Remember that the goals in your scenario are not always met.
Sometimes we also have to define unsuccessful scenarios
The more scenarios we have, the more important it becomes to analyze them to ensure that are complete and not redundant.
Remember to write these in everyday language, plain English!
A typical user should be able to read these descriptions and understand them
Keep it Simple!
Two common formats:
What is the Goal?
Who desires it?
How is it accomplished?
Adding Additional Detail
Scenarios where everything goes right are sometimes called "Sunny Day" scenarios, but what about additional flows or situations?
Extension: Describe steps for "Out of Stock"
Extension: Describe steps for "Order not Finalized"
Precondition: Customer has added at least one item to cart
Are there External Systems?
These might include:
external data sources
Switching back to people...
Roles / Security Groups
visitor, member, administrator, owner
Job Titles / Departments
Manager, payroll admin, production staff, executive team, accounting
Actors can also be categorized based on how the interact with each scenario:
Primary Actor: Used to describe the actors that initiate the scenario
Secondary Actor: Anyone else
How can we be sure we've addressed enough possibilities?
Log in to System
Triggered by primary actor
Has multiple steps
Has multiple conditions
But is it really a goal of the user?
The reason the want to login is to do something!
So... What is that something?
We're looking for...
Things the user wants to do:
Create new document
log in to app
Write a book
Emphasize the goal of ONE encounter
Let's look at an example
Recall the successful scenario we saw earlier... we need to ensure it is complete
Not Wordy! Not Technical!
The system is provided with the payment information and the shipping information by the customer.
Customer provides payment and shipping information
The system connects to the external payment process over HTTPS and uses JSON to submit the provided payment information to be validated, then waits for a dedicated callback response.
System validates payment information
Focus on intent!
Avoid describing UI:
Questions to ask:
Who performs system administration tasks?
Who manages users and security?
What happens if the system fails?
Is anyone looking at performance metrics or logs?
Next we need:
Symbols for our use cases and actors
A boundary for our system
Lines representing interactions
External analytics system
note we use <<type>> to indicate what the external system is
Use Case diagrams can start to look busy, but remember they should be easily readable.
We'll need a
to draw this :-)
Notice the addition of <<extend>> to link use cases when certain conditions are met.
Important: this is in no way a replacement for written use case documentation!
We will see more complex examples later... for now remember to keep it simple!