Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start 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.


Understanding Use Cases

No description

Matt Redmond

on 27 January 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Understanding Use Cases

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
Identifying Scenarios
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:
Use Cases
User Stories
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
web services
corporate apps
tax reporting
backup systems
Switching back to people...
Roles / Security Groups
visitor, member, administrator, owner
Job Titles / Departments
Manager, payroll admin, production staff, executive team, accounting
Categorizing Actors
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?
An example...
Log in to System
Sounds good...
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:
Purchase Items
Create new document
Balance Account
log in to app
Write a book
merge organizations
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:
Notice in the previous "stepped" example that there is no mention of: "click the checkout button", "rearrange using JavaScript"
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?
Our example:
Use Cases:
Search Articles
View Article
Manage Users
Create Article
View Analytics
Our Actors:
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
Another example:
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!
Full transcript