What Is A Use Case


hello I'm Tom Hathaway I'm wearing my VA

hat so let's talk business analysis in

this knowledge nugget I want to

introduce the concept of use cases as a

tool for defining user interaction

requirements since this is an

interactive knowledge nugget I will also

give you an opportunity to try your hand

at creating a version of a very simple

use case these techniques will help you

when you are the one wearing the BA hat

defining a proposed information

technology or IT application can be a

daunting challenge whether you're tasked

with defining a brand new application or

making changes to an existing one an

immense number of decisions await you

one of the very early and critical

decisions you have to make is how you

will represent the requirements that the

solution must fulfill ensuring that both

the business community and the

developers share a common understanding

of the requirements is notoriously

difficult any standard method for

structuring the communication between

these two parties drastically reduces

the probability of miscommunication with

all of the related costs and misery

the use case paradigm is one specific

method that you should have in your

repertoire of tools for representing how

the proposed application should interact

with the external world use cases were

introduced as a method for defining

requirements for IT solutions in the

late 1980s by Ivar yaqoob son and they

spread like wildfire like all great

techniques practitioners have modified

augmented adapted and otherwise refined

the basic concept over the years and

most of the add-ons are valuable in the

proper context regardless of the context

one of the common pillars of all use

cases is that they define the

interaction between two or more entities

called actors in use case parlance this

correctly implies that the use case

paradigm is not well-suited for defining

systems lacking interaction ie patch


to address the communication issue a use

case is often presented in plain text

and as a diagram the use case

description represents the interaction

between involved actors textually had an

appropriate level of detail the use case

diagram is a visual representation of

one or more use cases depicting the

actors stick figure symbol with the name

actor below it and their connections a

simple solid line to the use case an

oval with the name of the use case

inside it due to the intentional

simplicity of the use case diagram it is

considered optional in many

organizations it does however provide a

great tool for representing the context

of the use case in relatively intuitive

symbols the diagram is particularly

useful if the use case involves a lot of

different actors which is often the case

in embedded and real-time applications

here's a very simple little exercise to

demonstrate the use case concept you

need access to a cell phone to complete

the exercise

assume you just got off the airplane

meaning that your cell phone was off and

you missed a call from a friend that you

want to return


note this interaction was created using

a samsung s4 cell phone the phone is

powered off s0 5 i press the power

button and hold for 4 seconds as 10 the

phone displays my home menu and plays a

sound s 15 i press the phone symbol on

the menu as 20 the phone displays the

keypad menu

s25 I press the recent tab as 30 the

phone displays recent calls f-35 I tap

the actions bar s40 the phone displays

the options as 45 I tap the view option

as 50 the phone displays all view

options as 55 I select the missed call

option s60 the phone displays all missed

calls s65 I click on the missed call

from Dan as 70 the phone displays Dan's

contact info I am ready to click the

green phone to place the call

assuming you actually did the exercise

your solution can look very different

from ours and still be correct your

solution depends on the specific phone

you have and how you set it up it also

depends on how you perceived your

interactions we have seen solutions with

as few as four steps and as many as 21

all of which were correct

the key characteristics of a correct

answer are the following a you

documented a precondition eg the phone

is powered off B you documented the

interaction step by step in the form of

a dialogue you are having with the phone

I did this the phone reacted like this

see you documented the post condition AG

I am ready to click the green phone to

place the call all that is left for you

is to give this a name return missed

call and you have the basic framework

for a use case congratulations

okay let me correct a couple of

oversimplifications what you really

created is technically a use case

scenario meaning a specific interaction

with a specific device to achieve a

desired outcome given a specific initial


scenarios are instances of a single use

case I could give this scenario and my

cell phone to a friend and ask her to

return the call assuming they followed

the steps faithfully they would probably

achieve the same outcome however there

could be situations in which they were

unable to achieve it

for instance what would happen if they

pushed the power button on my phone and

the battery was empty they wouldn't even

get to step 2 let alone complete the

entire scenario to ensure that this

situation is covered I could add a

second precondition the phone has

sufficient power adding that condition

would not change the scenario I

described it simply clarifies it by

documenting a precondition that I didn't

think about because it didn't happen

when I executed the scenario

now assume that I do not want to limit

my ability to return the missed call to

situations where my phone has power

instead of adding the precondition I

could define what action I would take if

the battery was empty that implies I'm

going to define an alternate set of

actions I only do under specific

circumstances I do have a problem

however there's a fundamental philosophy

of the use case paradigm there are no

ifs in a use case okay if I'm not

allowed to use an if how do I introduce

the concept of alternate actions

to answer that I need to introduce

another use case term the path the steps

you documented represent a specific path

through the use case they were the exact

actions and reactions that you

experienced in executing the assignment

if you had to create a different use

case every time something was different

eg no power you'd end up with a

thundering heard of use cases and a lot

of the steps would be identical meaning


to avoid redundancy the use case

paradigm differentiates between a

standard path

aka basic course of events VCO II or

happy path which we do not recommend as

it implies an emotional component and

alternate paths ie the path less taken

the standard path represents the

interactions under normal circumstances

meaning nothing ever goes wrong which

was by the way the rationale for calling

this the happy path generally speaking

there will only be one standard path in

a use case it can have any number of

alternate paths one for each time you

want to document how to deal with a

specific situation

what do you represent this in the

scenario we just created there are

several possible solutions and we

recommend using the at convention if I

add an alternate path for dealing with

the dead battery situation my solution

would look like this

precondition the phone is powered off

standard path s 0 5 I press the power

button and hold for 4 seconds s 10 the

phone displays my home menu and plays a

sound as 15 I pressed the phone symbol

on the menu and so on until s 70 the

phone displays the caller's contact info

the post condition I am ready to click

the green phone to place the call

alternate paths a 0 1 @ s 0 5 the phone

does not turn on a zero 1.05 I locate an

electrical outlet a 0 1 10 I plug the

phone into the outlet a 0 1.15 the phone

displays the charging symbol a 0 1 20

resume at s 0 5 you may note that this

alternate path ends with a resume

statement this convention allows me to

return to the standard path s 0 X at a

specific step to attempt again to

achieve the ultimate goal of the use

case namely return the missed call

assuming that I am able to place a call

while my phone is charging a situation

I've not personally tested everything

should then follow the standard path

if you'd like to try your hand at adding

alternate paths to your scenario here

are a couple of ideas to get you started

you don't have to limit yourself to

these scenarios consider Murphy's Law

whatever can go wrong will

we encourage creative thinking

a zero - at s40 the phone displays

delete call a zero for at s60 the phone

displays only received calls

a zero five at s70 the phone displays

unknown color

this brings us to the end of this brief

introduction to use cases obviously

there's much more to learn about using

this phenomenally simple but powerful

tool to define requirements for IT

solutions but that will have to wait for

future knowledge nuggets meanwhile I

hope you can make good use of the

information provided in this knowledge

nugget when you are the one wearing the

BA hat