Use cases

(ísl. notkunartilvik)
System Requirements and Design
T-233-SRAD

Berglind Kara | January 7th 2023

Use cases
• What is a use case (ísl. Notkunartilvik)?
• User stories vs. use cases
• Finding use cases

• Contents & format of a use case

• Helpful guidelines

• Use case Diagrams (ísl. notkunartilvikarit)

What is a use case?
What is a use case?
• A use case is a written description of some system functionality (ísl.
kerfishegðun) that creates value (ísl. virði) for a user of the system.
• The use case is a fundamental concept in object-orient modeling. Mainly used
in the requirements and design work.
• Unlike most of UML notation, use cases are written and not necessarily drawn.

• The focus should be on user goals (ísl. notendamarkmið), and they should
describe the interaction (ísl. samskipti) of users with the system. They can
express the expectations of the users and or other stakeholders (ísl. hagaðila).
• What the user needs to do, not how the user does it.
What is a use case? (cont.)
The system
• A use case and the use case Diagram can be An actor
used to answer the following questions:
Use case
- What is being described?
• The system.
- Who interacts with the system? Use case
• The actors (ísl. leikendur)
- What can the actors do? Use case
• The use cases.
What is a use case? (cont.)
What the user needs to do How the user does it
• The user needs to authenticate • The user enters their email and
themselves password on the Login page.

• The user clicks on Facebook logo to

login using their Facebook account.

What the user needs to do How the user does it

• The user needs to buy a product • The user uses the search box on the
front page to find a product.

• The user adds the product to the cart by

pressing the “Add to cart” button.
• The user clicks “Checkout” and pays for
the product using PayPal.
What is a use case? (cont.)
• A use case is a set of one or more scenarios tied together by a common user
goal.
• A scenario represents one path through a use case.

• A scenario is a sequence of steps describing an interaction between a user and

the system.
Use cases should be
• High level
• Capture the requirements, not the design or implementation
• No wireframes or other format of User Interfaces

• Easily understood
• Avoid technical terms
• Think of the audience
• Name should represent value created to the actor or other stakeholders

• Often named with a verb followed by a noun

• “Account”
• “Close Account”
Finding use cases
Finding use cases
• Taking a list of features and creating the use cases from it

• “Brain-dumping” ideas from the user’s perspective

• Think about:
- What are the main tasks the actor should perform?
- Who is interested in the results of the system?
Contents & format of use cases
Contents & format of use cases
• UML doesn’t describe a standard format for a written use case description.
Examples
Contents & format of use cases
• Use cases should only contain information that is relevant and important.

• A use case could be described with the following:

Use case contents (name + actor)
Name (use case name)
• Short name that describes the user goal that creates value
• Example: “Buy product”
• What about: “Log in”? Or “Fill in home address”?

Actors (sometimes roles)

• What users are included in the use case
• Not only human users, other systems for example, or time
• Outside of the system, we are not in control of the actors
• Primary and secondary actors
Use case contents (name + actor)
Actors interact with the system ...
• by using use cases, (actor initiates the use case = primary actor)

• by being used by use cases, (the actors assist in the use case = secondary)

Actors represent roles that users adopt.

• Specific users can adopt and set aside multiple roles simultaneously.

Actors are not part of the system; they are outside the system boundaries.

Student

<<actor>>
Student
Use case contents (success + extensions)
Main success scenario (sometimes base flow, basic path, success)
• Describes what the user needs to do to achieve the goal
• Step by step (numbered)

Extensions (sometimes alternate flow, exceptions, expected errors)

• Handle differences in the use case
• All steps taken in the scenario that aren’t a part of the main success scenario
• Can be used to handle expected events
• Not a catch-all for everything that can go wrong
 Main success scenario

Start End
 Main success scenario with extensions

Start End

Possible alternate end, but main objective of

Alternate end the use case remains the same. The
alternate end is an “expected unexpected”
sort of.
Use case contents (conditions)
Precondition
• What needs to be true before the use case can be started
• Should not cover things that are irrelevant
• The user is conscious
• The electricity is on and the computer is turned on
• The user is authenticated and has an active account
• The funds in the user’s bank account exceed the amount to be transferred

Postcondition (sometimes guarantee)

• What will have happened after the main success scenario has completed
• Should not cover things that are irrelevant
Use case contents (other)
• Number • Trigger
• Used as a reference • What causes the use case to start
• Organizational metadata • Only when needed
• Source • Description
• What requirement is this use case • 1-2 sentences to describe the use case
addressing without detailed steps. Can contain
• Not necessarily a 1:1 mapping between reasoning why or what the end goal is.
requirements and use cases • Goal level (use case level)
• Priority • Fish level, Sea level, Kite level
• Low to High, 1-n, A-C • We won’t focus on these in this class
• Author
• Who wrote the use case specification
• For reference if needed
Use case format (empty)
Name
Number
Description
Priority
Author
Source
Actors
Precondition
Postcondition
Trigger
Main success scenario
Extensions
Use case format (example)
Name Buy Product
Number 1
Description The customer searches for a product, finds it, and buys it.
Priority High
Author Skúli Arnlaugsson
Source 1 (in requirements)
Actors Primary: Online customer, Secondary: Warehouse
Precondition The customer has a user in the system, product is in warehouse stock
Postcondition An order is ready to be handled by the warehouse, and the purchase
has been credited to the customer’s credit card.
Use case format (example cont.)
Main success scenario 1. Customer browses through the site
2. User finds the product to buy, and adds to the cart
3. Customer opens the cart and indicates they want to do a checkout
4. Customer selects a payment method
5. Customer enters shipping address
6. Customer reviews payment, shipping information
7. Customer accepts
8. System authorizes the purchase
9. System confirms sale and sends an order to the warehouse
10. System sends a confirmation email to customer
Extensions 1a) The customer uses the site’s search functionality instead of
browsing the site for a product.
4a) The customer can choose to add/update their credit card, see use
case 2.
8a) System fails to authorize the credit card purchase, allow customer
to go to step 4 and retry by adding another credit card.
Helpful guidelines
Helpful guidelines
• Remember the purpose
• This is the part where we ask why, try to understand the goal
• Focus on what matters
• The main success scenario in most cases
• Be as clear as possible, think of the audience
• Skip irrelevant information
• even entire rows if not needed
• Once you have several use cases
• Review list of actors, do all of them have use cases? If not, chances are there is a use case
you haven’t created.
• Review list of use cases, do all of them have the needed actors? If not, chances are you are
missing actors.
Use case diagrams
Use case diagrams
• UML standard
• Show actors, system boundaries, use cases,
and relationships between.

• Include (and extend) relationships

• Most value in the use case written description,
less so in the diagrams
Use case diagrams
Name Notation Description
System (ísl. kerfi) Box around the system. Marks the boundaries of the
internal system, and the
external actors.
Use case (ísl. notkunartilvik) Ellipse with the use case name. Unit of functionality of the
system.
Actor (ísl. leikari, gerandi) Stick figure, or a box with Roles of the users.
<<actor>> and the name of the
role beneath.
Association (ísl. vensl) Straight line between use case Relationships between the use
and actor. cases and actors.
Extend & Include relationship <<include>> & <<extend>> and Use case can extend another
a dashed line between two use use case, or a use case can
cases. include other use cases
Use case diagrams
Use case diagrams
Keep in mind
• Use case diagrams do not model processes/workflows!
• Actors are not part of the system, they should always be positioned outside of
the system boundaries.
• Many small use cases that have the same objective, could be grouped to form
one Use case using extensions for each scenario.
What about user stories?
• In Agile Software Development (ísl. kvik hugbúnaðarþróun), use cases are not
often used, but user stories are used to describe requirements for planning and
developing software.
• Alistair Cockburn, author of Writing Effective Use Cases (2001) and one of the
creators of the Agile Manifesto, that user stories don’t serve quite the same
purpose.

A user story is to a use case as a gazelle is to a gazebo.

Alistair Cockburn
Five reasons for use cases
• In Agile Software Requirements (Leffingwell, Dean, 201 ), five reasons for use
cases are listed (paraphrased for this slide):
1. List of use cases provides a short summary of what the system will contribute to the business
and the users. Helpful as a project planning skeleton, defining initial priorities, discussions on
estimates, and more.
2. Main success scenario of use cases provide everyone with an agreement as to what a system
will, and will not do.
3. The extensions provide a framework for investigating all the little details that somehow end up
taking 80% of the development time and budget. It provides a look-a-head mechanism, that
the customer/product owner/ analysist use to spot issues that are likely to take a long time.
4. The extensions also provide answers for detailed questions asked while in development, such
as “what are we supposed to do in this case…?”.
5. The full use case shows that the developers/analysts have thought of the user’s every need,
every goal that they have with respect to the system, and to every business variant involved.
Use cases vs. user stories
• A user story doesn’t model the more extensive than user stories.
interaction between an actor and the
• User stories are used for planning,
system. It is a brief description of
use cases are more used for the
functionality from the standpoint of a
requirements phase and thinking
user.
about the larger picture.
• User story is short (1-2 sentences),
• User stories normally take less time to
role, goal and acceptance criteria. Use
be created and can be created by
case has more detailed information.
anyone. Use cases require more time
• Use cases consider the larger context for analysis and writing.
and examine different scenarios. Or
Háskólinn í Reykjavík | Menntavegur 1 | 101 Reykjavík | Sími: 599 6200 | www.hr.is