Use Cases An Introduction

Use Cases An Introduction

Jason Gorman

www.parlezuml.com

1 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

Table of Contents
Introduction......................................................................................................................3 What Is A Use Case? .......................................................................................................3 What Is A Use Case Scenario ? ........................................................................................4 Cap turing Use Case Scen arios with Essential Use Case Descrip tions ............................5 M odeling Essential Use Case scen arios usin g Sequence Diagrams ............................6 Visualisin g Scenarios using UI Story boards....................................................................7 Use Cases & Rework .......................................................................................................8 Use Cases & UM L...........................................................................................................9 Relationship s Between Use Cases .................................................................................10 Includin g Use Cases ...................................................................................................10 Extendin g Use Cases ..................................................................................................11 App lying Use Cases.......................................................................................................13 Reusing Use Cases .........................................................................................................14 Plannin g & Estimatin g ...............................................................................................14 System Testing...........................................................................................................14 User Documentation ..................................................................................................14 User Stories ................................................................................................................15 Business Simulations .................................................................................................15 Conclusion .....................................................................................................................15 Further Reading..............................................................................................................16

2 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

Introduction
Search on Amazon for books on use cases, and y oull find hundreds up on hundreds of them. Search on Google for web sites that mention use cases, and y oull find millions. I dont think theres any asp ect of software develop ment thats received wider cov erage in the last ten y ears. But for all thats been written about them, most p eople still dont really understand them. This is partly because a lot thats been written about use cases overcomp licates them and confuses the reader. In theory and in p ractice, use cases are much simp ler than many authors make out. This short tutorial is designed to introduce use cases in their simplest form, and to show y ou how they can be effectively app lied in the software develop ment p rocess. Its not intended to be a detailed or comp rehensive guide to use cases and use case-driven software develop ment. Rather, this tutorial will show y ou the 20% of use case theory that you will p robably need to use 99% of the time.

What Is A Use Case?

In the mid-1980s, Ivar Jacobson p ut forward the idea of usage cases and usage scenarios. M ore recently these have become pop ularly known as use cases and use case scenarios. Theres no rocket science to it at all: a usage case is simply a reason to use a system. For examp le, a b ank cardho lder might need to use an ATM to get cash out of their account. Its as simp le as that.

Actor

System

Goal

Fig 1.0 A use case d escribes how a typ e of user (called an actor) uses a system to achieve a goal
3 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction There are three key things we need to know to describe a use case: 1. The actor or actors involved. An actor is a type of user (for examp le, cardhold er) that interacts with the sy stem. 2. The system being used. 3. The functional goal that the actor achieves usin g the sy stem the reason for using the sy stem. Believ e it or not, if y ou can remember this, then y ou already know a third of what there is to know about use cases (thats worth knowing, of course.) Theres a little more to it than that, and with practice y oull soon get the hang of it. So me things to bear in mind are: The actor describes a role that users play in relation to the system. May be the cardholder is an advertisin g executive, but that doesnt interest us. We only care what his relationship to the system is. The actor is external to the sy stem itself. Actors dont have to be p eop le. They can be other systems. For examp le, the ATM may need to connect to the cardholders bank. External sy stems that interact in a use case are also actors. The goal must be of value to the actor. We wouldnt have a use case called Cardholder enters PIN because that, by itself, has no value to the cardholder. We dont build ATM s just so p eop le can enter their PINs!

When we are analy sing fun ctional requirements for a system, the key questions we need to ask are; who will be using the system, and what will they be using it to do?

What Is A Use Case Scenario?

When a cardholder tries to withdraw cash from an ATM , it doesnt alway s necessarily turn out the same way . Sometimes he gets his money. Other times he might have insufficient funds. Or the ATM may be out of cash. These are all examp les of use case scenarios. The outcome is different, dep ending on circumstances, but they all relate to the same functional goal that is, theyre all triggered by the same need - and all have the same starting p oint.

4 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

Sorry. You have insufficient funds. Please specify a smaller amount.

Please take your cash

Sorry. We are unable to process your request at the moment.

Your card has been retained. Please contact your card issuer.

Fig 1.1. Use case scenarios for withdrawing cash from an ATM In p ractice, we describe use cases by describing the key scenarios. Use case scenarios form the basis of interaction design, but also map directly onto other useful develop ment artefacts like system test scripts and user documentation.

Capturing Use Case Scenarios with Essential Use Case Descriptions

Once we understand the actor and the goal for a use case, and have identified k ey use case scenarios, we can begin some high-level interaction d esign. Actors interact with the system by p ressing buttons, typ ing into text boxes, click in g on icons and so forth to achiev e the go al of the use case. A classic mistake made at this early stage of design is to go into technical detail and commit to a sp ecific user interface design or imp lementation technolo gy . This is almost alway s the wrong time to be makin g these kinds of low-level design decisions. We first need to understand what the business logic of the interactions are, so we can focus on satisfy ing the business goal of the use case. Essential use cases are a great technique for describin g interactions in a way that is indep endent of the technical imp lementation of the system. Instead of say ing the user presses the enter button, we say the user confirms their choice, for examp le. A good way to write essential use cases is to sp lit the actions into columns, one for each actor and one for the system. Then we can see at a glance not only the order of events in a use case scenario, but also exactly who is doing what. These essential use case descrip tions, one for each key use case scenario, will form the basis of our high-level object oriented design, the UI design, and are also the foundation for system test design, user documentation and other useful thin gs we might need later in the develop ment p rocess.
5 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

Cardholder
select withdrawal option

ATM

display withdrawal options specify amount check cardholder has sufficient funds eject card prompt cardholder to take card take card dispense amount prompt cardholder to take cash take cash debit cardholders account thank cardholder display welcome and await next cardholder

Fig 1.2. An essential use case clearly shows the order of events and the responsibilities of the actor(s) and system in a single use case scenario, w ithout committing to technica l design decisions WARNING! 99% of teams are unaware that use case descrip tions like the one above are no t sy stem requirements documents. These are high-level interaction designs. The dan ger is that if we mix them up with real requirements stuff the system really has to do then we can get bo gged down in the design decisions we mak e early on. Changing the design of use cases must alway s been seen as an op tion if it turns out theres a better or cheap er way of achieving the same functional goal. B e one of the smart 1% and alway s rememb er that use case designs arent the same thin g as requirements.

Modeling Essential Use Case scenarios using Sequence Diagrams

6 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction If y oure familiar with UM L sequence diagrams, then y ou can just as easily model a use case scenario like the one above usin g a simple sequence diagram. This also shows the order of events, the interactions and clearly shows whos doing what.
cardholder select withdrawal option display withdrawal options specify amount check cardholder has sufficient funds eject card ATM

prompt cardholder to take card take card prompt cardholder to take cash take cash

dispense am ount

debit cardholders account thank cardholder display welcome and await next cardholder

Fig 1.3. A use case scenario modelled using a sequence diagram It has the added advantage or d isadvantage, dep endin g on how y ou look at it - that y ou can cap ture it in a modellin g tool that supp orts UM L, and y ou can continue to flesh out the imp lementation design b ehind the user-system interactions using the same model.

Visualising Scenarios using UI Stor yboards

If were hap py with the logical flow of a use case scenario, we can use a simp le technique called storyboarding to show how it might look with a real user interface imp lementation. At each step in the scenario, we can draw a p icture of what the user interface would look like at that p oint in time, and a sequen ce of such p ictures, one for each interaction, neatly illustrates the flow of the scenario in a way even non-technical folk can readily understand. Again, its vitally imp ortant to remember that what were doing here is design. And that means we have choices. Beware of committing to the first UI design y ou do without exp loring alternative options.
7 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

Please select a service: Withdrawal Withdrawal With Receipt Display Balance Order Cheque Book

select withdrawal option

Please select an amount to withdraw: 10 20 50 100 200 Other

specify amount

take card
Please remove your card Please take your cash

take cash

Thank you for using Natleys Bank

Welcome to Natleys Bank. Please insert your card.

Fig 1.4. Storyboards are a powerful too l for visualising and communicating use case scenarios and UI designs If y ou have identified your key use cases, and have essential use case d escrip tions for key use case scenarios and story boards too, then by this stage y our users p robably have a pretty good idea of what it is they re going to be getting. Importantly, y ou will have a pretty good idea of what it is youre goin g to build, too. This is a critical breakthrough for development teams. You have p assed the point of no surprise.

Use Case s & Rework

There are all sorts of reasons why we might need to chan ge software, and some of them are inescap able hence the need for an iterative and evo lutionary app roach to development. But there are two reasons that are largely avoidable and should be seen as undesirable. 1. Buildin g somethin g the user was exp ecting to get, but building it wrong. 2. Buildin g somethin g the user wasnt exp ecting to get. If the user asks for feature X, and y ou deliver feature X working, and a month later the user says actually , what I really needed was X+1 then theres not a lot we can do about that. That sort of change is unavo idable, and we must embrace the need to accommod ate it.

8 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction But if the user asks for feature X, and we deliver X+1 either because we did a bad job of deliverin g X, or because we misunderstood and thought the user actually wanted X+1 in the first p lace - then we have failed. Use cases dont help us to avoid null pointer excep tions or un-initialised database connections, so we still have to do coding stuff to make sure we avoid those kinds of errors. But use cases can definitely help us to avoid misunderstandings between us and the users. In fact, I see no other good reason for them. Do y ou? This gives us a useful guid eline as to how effectively were ap p ly ing use cases. In theory , rework due to requirements misunderstandin gs should drop to almost zero. Thats not to say that we wont need to do any rework: we just wont need to do any unnecessary rework.

Use Case s & UML

Given how closely associated they are, y ou probably wont be surp rised to learn that the Unified Modeling Language has a sp ecific notation for modellin g use cases.
communicates ATM

withdraw cash cardholder

actor

system boundary

use case

Fig 1.5. UML Use Case diagram In UM L use case diagrams, actors are drawn as stick men, with the name of the actor written underneath. A use case is drawn as an oval containing the name of the use case. To show that an actor particip ates in a use case, we draw a line between the actor and the use case that shows that the actor communicates with the use case. Op tionally we can draw a box around the use cases to show where the system boundary is. The actor is alway s outside the sy stem boundary (by definition).
9 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

ATM

order cheque book cancel transaction

view balan ce deactivate ATM bank employee

withdraw ca sh cardholder print audit log

start session

Fig 1.6. A use case d iagram for the ATM

Relationships Between Use Cases

Including Use Cases
When I mak e a cup of tea, I boil the kettle. I also boil the kettle when I make a cup of cocoa. Wh en two or more use cases include the flow of another use case, they are said to include that use cases flow. We can illustrate this relationship in a use case diagram by simp ly drawing a dotted line with an arrow pointing towards the included use case fro m all the use cases that include it. (With me so far?) The arrow should have the UM L stereotyp e <<include>> to clearly show what kind of relationship it is.

10 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

student
select book appointment option Prompt use r to enter the t ime and date they would prefer enter time and date Retrieve list of available tutors for that date and time [tutor available] Ask student to confirm assessment

music school

book lesson
student
select book lesson option Prompt user to enter the time and date the y wo uld pref er enter time and date Retrieve list of available tutors for that date and t ime Select tutor

music school

Fig 1.7. Two essential use cases share common steps

music school

book assessment

<<include>>

chec k availability of tutors

customer

book less on

<<include>>

Fig 1.8. UML Use Case diagram showing two use cases including anoth er

Extending Use Cases

11 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction Sometimes, two or more use cases will in clude the flow of another use case, but only under certain cond itions. For examp le, when I make a cup of tea or make a cup of cocoa, I might boil the kettle only if it hasnt recently been boiled. The <<include>> relationship means that the flow of that use case is always included. But a <<extend>> relationship means that the flow of the extendin g use case is only included und er specific cond itions, which must be specified as the extension point of the use case bein g extended.
customer
select checkout option [not logged in] prompt customer for user name & password enter user name & password authenticate user disp lay conten ts of shopping basket

web store

review a product
customer
select review item option [not logged in] prompt customer for user name & password enter u ser name & password authentica te user prompt user for review text

web store

Fig 1.9. The two use case share common steps that are on ly execu ted when the actor is not logged in.

12 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

web store
c heck out extension points not logged in

<<extend>> (not logged in)

log in

customer

r eview a pr oduct extension points not logged in

<<extend>> (not logged in)

Fig 1.10. A UML Use Case diagram showing two use cases being extended b y another Many peop le get tripp ed up by <<include>> and <<extend>> relationship s between use cases. Here are some tip s for getting it right: 1. Make sure y ouve got the right kind of relationship : <<include>> means alway s included, but <<extend>> means conditionally includ ed. 2. Make sure y ouve got the arrows going the right way. <<include>> should p oint towards the use case bein g in cluded. <<extend>> should p oint towards the use case(s) bein g extended (and not the extendin g use case).

Applying Use Case s

As I mentioned at the beginning, a heck of a lot has been written about use cases, and not all of it is p erhap s as straightforward and commonsense as it could be. Ap ply ing use cases in the software develop ment p rocess is not the black art some authors make it out to be. There are a few simp le step s to follow, and y ou can use y our noodle to figure out the rest of the details: Identify y our actors: who will be usin g the system? Identify their goals: what will they be using the sy stem to do? Identify key scenarios: in try ing to achieve a sp ecific goal, what distinct outcomes or workflows might we need to consider? Describe in business terms the interactions between the actor(s) and the sy stem for a sp ecific scenario
13 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction Create a UI p rototyp e that clearly communicates the scenario to technical and non-technical stakeholders Do a high-level OO design for the scen ario Imp lement the design in code Get feedback from y our users ideally through structured accep tance testing Move on to the next scenario or use case (rinse and rep eat)

The most imp ortant thing to remember is to do analysis, design and imp lementation one use case scenario at a time, and to get feedback from the users as soon as a new scenario is ready for them to test. You can incorp orate valuable lessons from this feedback and evolve your design into something more useful. WARNING! Do not, under any circumstances, attempt to design the entire system before writing any code. Break the design down into use cases and scenarios, and work one scenario at a time.

Reusing Use Case s

As Ive alluded to already , use cases arent just useful for cap turing functional requirements or doing interaction design. In this final section, well take a look at 5 other way s we can exp loit use cases in the develop ment p rocess.

Planning & Estimating

Use cases can be used as the basis for p lanning develop ment p rojects, and for driving the development p rocess. Use cases can be sized accordin g to their comp lexity and, working from historical data, estimates can b e calculated for how long each use case might take to imp lement. A practical discussion about the ins and outs of project planning is well bey ond the scope of this guide, but if I can only get one p oint across, it will be this: use iterative and adapti ve planning techniques

System Testing
Just as a story board adds imp lementation details to an essential use case scenario, so too can sy stem test scripts add test data to the same scenarios. Thats all a sy stem test script is, in essence; a use case scenario with sp ecific test data.

User Documentation

14 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction Put real screen grabs in y our story boards and add a bit more descriptive text, then add the words How to to the title of each use case, and you have some pretty usable user documentation.

User Stories
If y oure into Agile Software Development, and esp ecially eXtreme Programmin g, y ou can easily break down your essential use cases into smaller chunks and write them on story cards. A word of advice, though, keep ing user stories and use cases in sy nch is as problematic as keep ing models and code in step . My advice is to maintain high-level traceability only: if y ou can map user stories on to use case names, then thats usually good enou gh for track ing p urposes.

Bu siness Simulations
Use case descriptions can be incorp orated into higher-level business p rocess descriptions so that we can simulate the execution of those business p rocesses and sanity check our use cases in the context in which they will be used. This can be a very effective way of avoidin g the kind of requ irements errors that are very difficult to sp ot from the ground.

Conclusion
Desp ite what y ou may have heard from some Agile develop ers, rep orts of the demise of use cases have been greatly exaggerated. Theyre by no means a silver bullet for requirements and UI design, and they certainly have their p itfalls, but overall they can be a p owerful tool for most p rojects. The secret is to keep it simple, and to involv e the users right the way along in the identification and d esign of use cases. Rememb er that our aim is to eliminate rework due to requirements misunderstandings, and so we should be aimin g to reach a point where there are no surp rises for the users. Use cases, in conjunction with techniques like story boarding, help to build an exp licit shared understandin g that every one can take away with them users, develop ers, testers, technical authors, and others. Theres absolutely no reason why use cases cant be app lied in Agile p rojects, p rovided they re app lied in the Agile spirit. Tackle them in small chunks, involv e the users closely and seek feedb ack throughout the p roject.

15 Jason Gorman 2006 www.parlezuml.com

Use Cases An Introduction

Further Reading
Writing Effective Use Cases Alistair Coburn http ://www.amazon.com/Writing-Effective-Cases-Alistair-Cockburn/dp /0201702258 App ly ing Use Case-driven Object M odeling with UML Doug Rosenberg & Kendall Scott http ://www.amazon.com/App ly ing-Case-Driven-Object-M odeling/dp /0201730391 Use Case Zone Andy Pols http ://www.p ols.co.uk/use-case-zone/index.html Driving Dev elop ment with Use Cases Jason Gorman http ://p arlezuml.com/tutorials/usecases/usecases.p df

Training Requirements Analy sis using UM L 2 days http ://p arlezuml.com/trainin g/umlrequirements.htm

16 Jason Gorman 2006 www.parlezuml.com