iji use-case2 0 2

8/2/2019 IJI Use-Case2 0 2

1/54

USE-CASE 2.0The Guide to Succeeding with Use Cases

Ivar Jacobson

Ian Spence

Kurt Bittner

December 2011

USE-CASE 2.0 The Defnitive Guide

8/2/2019 IJI Use-Case2 0 2

2/54

About this Guide 3

How to read this Guide 3

What is Use-Case 2.0? 4

First Principes 5Principe 1: Keep it simpe by teing stories 5

Principe 2: Understand the big picture 5

Principe 3: Focus on vaue 7

Principe 4: Buid the system in sices 8

Principe 5: Deiver the system in increments 10

Principe 6: Adapt to meet the teams needs 11

Use-Case 2.0 Content 13

Things to Work With 13

Work Products 17

Things to do 22

Using Use-Case 2.0 29

Use-Case 2.0: Appicabe for a types of system 29

Use-Case 2.0: Handing a types of requirement 30

Use-Case 2.0: Appicabe for a deveopment approaches 30

Use-Case 2.0: Scaing to meet your needs scaing in, 38

scaing out and scaing up 38

Concusion 39

Appendix 1: Work Products 40

Supporting Information 41

Test Case 43

Use-Case Mode 45

Use-Case Narrative 46

Use-Case Reaization 48

Gossary of Terms 50

Acknowedgements 51

Genera 51

Peope 51Bibiography 52

About the Authors 53

USE-CASE 2.0 The Defnitive Guide Page 2 20052011 IA JACS ITEATIAl SA. All IGTS ESEED.

8/2/2019 IJI Use-Case2 0 2

3/54

About this GuideThis guide describes how to appy use cases in an agie and scaabe ashion. It buids on the current state othe art to present an evoution o the use-case technique that we ca Use-Case 2.0. The goa is to provide youwith a oundation to hep you get the most out o your use cases; one that is not ony appicabe or sma coocated agie teams but aso arge distributed teams, outsourcing, and compex muti-system deveopments.It presents the essentias o use-case driven deveopment as an accessibe and re-usabe practice. It aso pro-vides an introduction to the idea o use cases and their appication. It is deiberatey kept ightweight. It is nota comprehensive guide to a aspects o use cases, or a tutoria on use-case modeing. It may not be sucientor you to adopt the practice. For exampe, it is not intended to teach you how to mode, or this we reer youto our previousy pubished books on the subject.

ow to read this GuideThe guide is structured into our main chapters:

What is Use-Case 2.0? A one page introduction to the practice. First Principes An introduction to use cases based around the 6 principes that act as the oundation

or the practice. Use-Case 2.0 Content The practice itse presented as a set o key concepts, activities, work products

and the rues that bind them together. Using Use-Case 2.0 A summary o when and how to appy the practice.

Use-Case 2.0 Content The practice itse presented as a set o key concepts, activities, work productsand the rues that bind them together.

These are topped and taied with this brie introduction, and a short concusion.

I you are new to use cases then you might want to read the What is Use-Case 2.0?, the First Principes, andthe Using Use-Case 2.0 chapters to understand the basic concepts. You can then dip into the Use-Case 2.0Content as and when you start to appy the practice.

I you are amiiar with the basics o use cases then you might preer to dive straight into the Use-Case 2.0Content and Using Use-Case 2.0 chapters once youve read the What is Use-Case 2.0? chapter. This wi hepyou compare Use-Case 2.0 with your own experiences and understand what has changed.

Aternativey you coud just read a the chapters in the order presented.


8/2/2019 IJI Use-Case2 0 2

4/54

What is Use-Case 2.0?Use Case: A use case is a the ways o using a system to achieve a particuar goa or a particuar user. Takentogether the set o a the use cases gives you a o the useu ways to use the system, and iustrates the vauethat it wi provide.

Use-Case 2.0: A scaabe, agie practice that uses use cases to capture a set o requirements and drive theincrementa deveopment o a system to uf them.

Use-Case 2.0 drives the deveopment o a system by frst heping you understand how the system wi be usedand then heping you evove an appropriate system to support the users. It can be used aongside your cho-sen management and technica practices to support the successu deveopment o sotware and other ormso system. As you wi see Use-Case 2.0 is:

lightweight Scaabe

ersatie Easy to use

Use cases make it cear what a system is going to do and, by intentiona omission, what it is not going to doThey enabe the eective envisioning, scope management and incrementa deveopment o systems o anytype and any size. They have been used to drive the deveopment o sotware systems since their initia in-troduction at PSlA in 1987. ver the years they have become the oundation or many dierent methodsand an integra part o the Unifed Modeing language. They are used in many dierent contexts and envi-ronments, and by many dierent types o team. For exampe use cases can be benefcia or both sma agiedeveopment teams producing user-intensive appications and arge projects producing compex systems ointerconnected systems, such as enterprise systems, product ines, and systems in the coud.

The use-case approach has a much broader scope than just requirements capture. As mentioned beore theycan and shoud be used to drive the deveopment, which means that Use-Case 2.0 aso supports the anaysisdesign, panning, estimation, tracking and testing o systems. It does not prescribe how you shoud pan ormanage your deveopment work, or how you shoud design, deveop or test your system. It does howeverprovide a structure or the successu adoption o your seected management and deveopment practices.

Use-Case 2.0 exists as a proven and we-defned practice. Athough the term Use-Case 2.0 suggests a new ver-sion o use cases, it does not reer to an update o the Unifed Modeing language, but rather to cumuativechanges in the way sotware deveopers and business anaysts appy use cases. A use case is sti a use casebut the ways that we present, address and manage them have a evoved to be more eective. The changes

are not theoretica but are pragmatic changes based on 20 years o experience rom a over the word and aareas o sotware deveopment.


8/2/2019 IJI Use-Case2 0 2

5/54

First PrincipesThere are six basic principes at the heart o any successu appication o use cases:

1. Keep it simpe by teing stories2. Understand the big picture

3. Focus on vaue4. uid the system in sices5. Deiver the system in increments6. Adapt to meet the teams needs

In this chapter we ook at these principes in more detai and use them to introduce the concepts o use-casemodeing and use-case driven deveopment.

Principe 1: Keep it simpe by teing storiesStoryteing is how cutures survive and progress; it is the simpest and most eective way to pass knowedgerom one person to another. It is the best way to communicate what a system shoud do, and to get everybodyworking on the system to ocus on the same goas.

The use cases capture the goas o the system. To understand a use case we te stories. The stories cover howto successuy achieve the goa, and how to hande any probems that may occur on the way. Use cases pro-vide a way to identiy and capture a the dierent but reated stories in a simpe but comprehensive way. Thisenabes the systems requirements to be easiy captured, shared and understood.

As a use case is ocused on the achievement o a particuar goa, it provides a ocus or the storyteing. athe

than trying to describe the system in one go we can approach it use case by use case. The resuts o the story-teing are captured and presented as part o the use-case narrative that accompanies each use case.

When using storyteing as a technique to communicate requirements it is essentia to make sure that thestories are captured in a way that makes them actionabe and testabe. A set o test cases accompanies eachuse-case narrative to compete the use cases description. The test cases are the most important part o a usecases description, more important even than the use-case narrative. This is because they make the stories reaand their use can unambiguousy demonstrate that the system is doing what it is supposed to do. It is the testcases that defne what it means to successuy impement the use case.

Principe 2: Understand the big pictureWhether the system you are deveoping is arge or sma, whether it is a sotware system, a hardware systemor a new business, it is essentia that you understand the big picture. Without an understanding o the systemas a whoe you wi fnd it impossibe to make the correct decisions about what to incude in the system, whatto eave out o it, what it wi cost, and what beneft it wi provide. This doesnt mean capturing a the require-ments up ront. You just need to create something that sums up the desired system and ets you understandscope and progress at a system eve.


8/2/2019 IJI Use-Case2 0 2

6/54

A use-case diagram is a simpe way o presenting an overview o a systems requirements. Figure 1 shows theuse-case diagram or a simpe teephone system. From this picture you can see a the ways the system can beused, who starts the interaction, and any other parties invoved. For exampe a Caing Subscriber can pace aoca ca or a ong-distance ca to any o the systems Caed Subscribers. You can aso see that the users donthave to be peope but can aso be other systems, and in some cases both (or exampe the roe o the CaedSubscriber might be an answering machine and not a person).

FIGUR 1: TH USCAS DIAGRAM FR A SIMPl TlPHN SSTM

A use-case diagram is a view into a use-case mode. Use-case modes acknowedge the act that systems sup-port many dierent goas rom many dierent stakehoders. In a use-case mode the stakehoders that use thesystem and contribute to the competion o the goas are modeed as actors, and the ways that the system wibe used to achieve these goas are modeed as use cases. In this way the use-case mode provides the contextor the systems requirements to be discovered, shared and understood. It aso provides an easiy accessibebig picture o a the things the system wi do. In a use-case diagram, such as Figure 1, the actors are shownas stick-men and the use cases as eipses.

A use-case mode is a mode o a the useu ways to use a system. It aows you to very quicky scope the sys-tem what is incuded and what is not and give the team a comprehensive picture o what the system wido. It ets you do this without getting bogged down in the detais o the requirements or the internas o thesystem. With a itte experience it is very easy to produce use-case modes or even the most compex systemscreating an easiy accessibe big picture that makes the scope and goas o the system visibe to everyoneinvoved.


PLACE LOCAL CALL

PLACE LONG DISTANCE CALL

RETRIEVE CUSTOMER BILLING INFO

GET CALL HISTORY

CALLED

SUBSCRIBER

BILLING

SYSTEM

CALLING

SUBSCRIBER

CUSTOMER

8/2/2019 IJI Use-Case2 0 2

7/54

Principe 3: Focus on vaue

When trying to understand how a system wi be used it is aways important to ocus on the vaue it wi pro-vide to its users and other stakehoders. aue is ony generated i the system is actuay used; so it is muchbetter to ocus on how the system wi be used than on ong ists o the unctions or eatures it wi oer.

Use cases provide this ocus by concentrating on how the system wi be used to achieve a specifc goa or aparticuar user. They encompass many ways o using the system; those that successuy achieve the goas, andthose that hande any probems that may occur. To make the vaue easy to quantiy, identiy and deiver youneed to structure the use-case narrative. To keep things simpe start with the simpest possibe way to achievethe goa. Then capture any aternative ways o achieving the goa and how to hande any probems that mightoccur whist trying to achieve the goa. This wi make the reationships between the ways o using the systemcear. It wi enabe the most vauabe ways to be identifed and progressed up ront, and aow the ess vau-abe ones to be added ater without breaking or changing what has gone beore.

In some cases there wi be itte or no vaue in impementing anything beyond the simpest way to achievethe goa. In other cases providing more options and speciaist ways o achieving the goa wi provide the key

dierentiators that make your system more vauabe than your competitors.

Figure 2 shows a use-case narrative structured in this way. The simpest way o achieving the goa is describedby the basic ow. The others are presented as aternative ows. In this way you create a set o ows that struc-ture and describe the stories, and hep us to fnd the test cases that compete their defnition.

FIGUR 2: TH STRUCTUR F A USCAS NARRATI

Figure 2 shows the narrative structure or the Withdraw Cash use case or a cash machine. The basic ow isshown as a set o simpe steps that capture the interaction between the users and the system. The aterna-tive ows identiy any other ways o using the system to achieve the goa such as asking or a non-standardamount, any optiona aciities that may be oered to the user such as dispensing a receipt, and any probemsthat coud occur on the way to achieving the goa such as the card getting stuck.

BASIC FLOW ALTERNATIVE FLOWS

1. Insert Card

2. Validate Card

3. Select Cash Withdrawal

4. Select Account

5. Conrm Availability

of Funds

6. Return Card

7. Dispense Cash

A1 Invalid Card

A2 Non-Standard Amount

A3 Receipt Required

A4 Insucient Funds in ATM

A5 Insucient Funds in Acct

A6 Would Cause Overdraft

A7 Card Stuck

A8 Cash Left Behind etc..


8/2/2019 IJI Use-Case2 0 2

8/54

This kind o bueted outine may be enough to capture the stories and drive the deveopment, or it may needto be eaborated as the team expores the detai o what the system needs to do.

You dont need to capture a o the ows at the same time. Whist recording the basic ow it is natura to thinkabout other ways o achieving the goa, and what coud go wrong at each step. You capture these as Aterna-tive Fows, but concentrate on the asic Fow. You can then return to compete the aternative ows ater asand when they are needed.

The most important thing is the additive structure o the use-case narrative. The basic ow is needed i theuse case is ever to be successuy competed; this must be impemented frst. The aternatives though areoptiona. They can be added to the basic ow as and when they are needed. This aows you to reay ocus onthe vaue to be obtained rom the system. You no onger need to deiver the whoe use case but can ocus onthose parts o the use case that oer the most vaue. It aso means that you dont need a compete use-casemode or even a compete use case beore you start to work on the deveopment o the system. I you haveidentifed the most important use case and understood its basic ow then you aready have something ovaue you coud add to your system.

This structure makes the stories easy to capture and vaidate or competeness, whist making it easy to fteout those potentia ways o using a system that oer itte or no rea vaue to the users. This constant ocus onvaue wi enabe you to ensure that every reease o your system is as sma as possibe, whist oering reavaue to the users o the system and the stakehoders that are unding the deveopment.

Principe 4: uid the system in sicesMost systems require a ot o work beore they are usabe and ready or operationa use. They have manyrequirements, most o which are dependent on other requirements being impemented beore they can beufed and vaue deivered. It is aways a mistake to try to buid such a system in one go. The system shoud

be buit in sices, each o which has cear vaue to the users.

The recipe is quite simpe. First, identiy the most useu thing that the system has to do and ocus on thatThen take that one thing, and sice it into thinner sices. Decide on the test cases that represent acceptanceo those sices. Some o the sices wi have questions that cant be answered. Put those aside or the momentChoose the most centra sice that traves through the entire concept rom end to end, or as cose to that aspossibe. Estimate it as a team (estimates dont have to be right, theyre just estimates), and start buiding it.

This is the approach taken by Use-Case 2.0, where the use cases are siced up to provide suitaby sized workitems, and where the system itse is evoved sice by sice.

Sicing up the use casesThe best way to fnd the right sices is to think about the stories and how we capture them. Each story is a goodcandidate sice. Each story is defned by part o the use-case narrative and one or more o the accompanyingtest cases. It is the test cases that are the most important part o the use-case sices description because theymake the stories rea.


8/2/2019 IJI Use-Case2 0 2

9/54

Appying our recipe above, the use cases identiy the useu things that the system wi do. Seect the mostuseu use case to fnd the most useu thing that the system does. To fnd the most centra sice you wi needto shed a the ess important ways o achieving the goa and handing probems. You can do this by ocusingon the story described by the basic ow. A sice based on the basic ow is guaranteed to trave through theentire concept rom end-to-end as it wi be the most straightorward way or the user to achieve their goa.

Estimate the sice and start to buid it. Additiona sices can then be taken rom the use case unti there areenough sices to provide this particuar user with a usabe soution. The same can then be done or any otheruse cases you need to compete a usabe system.

A use-case sice doesnt need to contain an entire ow and a its test cases the frst sice might just be thebasic ow and one test case. Additiona sices can then be added to compete the ow and address a the testcases. The sicing mechanism is very exibe enabing you to create sices as big or sma as you need to driveyour deveopment.

The sices are more than just requirements and test casesWhen we buid the system in sices it is not enough to just sice up the requirements. Athough use cases have

traditionay been used to hep understand and capture requirements, they have aways been about morethan this. As shown in Figure 3, the use-case sices sice through more than just the requirements, they asosice through a the other aspects o the system and its documentation.

FIGUR 3: A USCAS SlIC IS MR THAN JUST A SlIC F TH RUIRMNTS

n the et o Figure 3 you can see the use-case sice, this is a sice taken rom one o the use cases shown inthe next coumn. The sice then continues through the design showing the design eements invoved, andthrough the impementation where you can see which pieces o the code actuay impement the sice. Finaythe sice cuts through the test assets, not just encompassing the test cases, but aso the test scripts used toexecute the test cases and the test resuts generated.

As we as providing traceabiity rom the requirements to the code and tests, thinking o the sices in this wayheps you deveop the right system. When you come to impement a sice you need to understand the impactthat the sice wi have on the design and impementation o the system. Does it need new system eements tobe introduced? Can it be impemented by just making changes to the existing eements? I the impact is toogreat you may even decide not to impement the sice! I you have the basic design or the system this kindo anaysis can be done easiy and quicky, and provides a great way to understand the impact o adding thesice to the system.


8/2/2019 IJI Use-Case2 0 2

10/54

y addressing each aspect o the system sice by sice, use cases hep with a the dierent areas o the systemincuding user experience (user interace), architecture, testing, and panning. They provide a way to ink therequirements to the parts o the system that impement them, the tests used to veriy that the requirementshave been impemented successuy, and the reease and project pans that direct the deveopment work. InUse-Case 2.0 there is a specia construct, caed the use-case reaization, which is added to each use case torecord its impact on the other aspects o the system.

Use-Case Sices: The most important part of Use-Case 2.0The concept o a use-case sice is as integra to Use-Case 2.0 as the use case itse. It is the sices that enabethe use cases to be broken down into appropriatey sized pieces o work or the deveopment team to tackeImagine that you are part o a sma team producing working sotware every two weeks. A whoe use case isprobaby too much to be competed in one two-week period.

A use-case sice though is another matter because it can be siced as thiny as the team requires. They asoaow the team to ocus on providing a vauabe, usabe system as soon as possibe, shedding a unnecessaryrequirements on the way.

Principe 5: Deiver the system in incrementsMost sotware systems evove through many generations. They are not produced in one go; they are con-structed as a series o reeases each buiding on the one beore. Even the reeases themseves are oten notproduced in one go, but are evoved through a series o increments. Each increment provides a demonstrabeor usabe version o the system. Each increment buids on the previous increment to add more unctionaityor improve the quaity o what has come beore. This is the way that a systems shoud be produced.

The use cases themseves can aso be too much to consider deivering a at once. For exampe, we probabydont need a the ways o pacing a oca ca in the very frst increment o a teephone system. The most basic

aciities may be enough to get us up and running. The more optiona or niche ways o pacing a oca ca suchas reversing the charges or rediaing the ast number caed can be added in ater increments. y sicing up theuse cases we can achieve the fner grained contro required to maximize the vaue in each reease.

Figure 4 shows the incrementa deveopment o a reease o a system. The frst increment ony contains asinge sice: the frst sice rom use case 1. The second increment adds another sice rom use case 1 and thefrst sice rom use case 2. Further sices are then added to create the third and ourth increments. The ourthincrement is considered compete and useu enough to be reeased.


8/2/2019 IJI Use-Case2 0 2

11/54

FIGUR 4: US CASS, USCAS SlICS, INCRMNTS, AND RlASS

Use cases are a abuous too or reease panning. Working at the use-case eve aows whoe swathes o re-ated requirements to be deerred unti the ater reeases. y making decisions at the use-case eve you canquicky sketch out the big picture and use this to ocus in on the areas o the system to be addressed in thenext reease.

Use-case diagrams, showing which use cases are to be addressed in this reease and which are to be et unti aater reease, are a great too or iustrating the teams goas. They ceary show the theme o each reease andook great pinned up on the was o your war-room or everybody to see.

Use-case sices are a abuous too or buiding smaer increments on the way to a compete reease. They a-ow you to target independenty impementabe and testabe sices onto the increments ensuring that eachincrement is arger than, and buids on, the one beore.

Principe 6: Adapt to meet the teams needs

Unortunatey there is no one size fts a soution to the chaenges o sotware deveopment; dierent teamsand dierent situations require dierent styes and dierent eves o detai. egardess o which practices andtechniques you seect you need to make sure that they are adaptabe enough to meet the ongoing needs othe team.

This appies to the practices you seect to share the requirements and drive the sotware deveopment asmuch as any others. For exampe ightweight requirements are incrediby eective when there is cose co-aboration with the users, and the deveopment team can get persona expanations o the requirements andtimey answers to any questions that arise. I this kind o coaboration is not possibe, because the users arenot avaiabe, then the requirements wi require more detai and wi inevitaby become more heavyweight

There are many other circumstances where a team might need to have more detaied requirements as aninput to deveopment. owever, whats important is not isting a o the possibe circumstances where a ight-weight approach might not be suitabe but to acknowedge the act that practices need to scae.


START UP

RELEASE

READY HANDOVER

FIRST

INCREMENT

SECOND

INCREMENT

THIRD

INCREMENT

FOURTH

INCREMENT

RELEASED

SYSTEM

RELEASE

CANDIDATE

SLICE 1.1 SLICE 1.1 SLICE 1.1 SLICE 1.1

SLICE 1.2 SLICE 1.2 SLICE 1.2

SLICE 2.1 SLICE 2.1 SLICE 2.1

SLICE 3.1 SLICE 3.1

SLICE 4.1 SLICE 4.1

SLICE 2.2

SLICE 3.2

SLICE 4.2USE CASE 1

USE CASE 2

USE CASE 3

USE CASE 4

8/2/2019 IJI Use-Case2 0 2

12/54

Use-Case 2.0 is designed with this in mind, and is as ight as you want it to be. Sma, coaborative teams canhave very ightweight use-case narratives that capture the bare essentias o the stories. These can be handwritten on simpe index cards. large distributed teams can have more detaied use-case narratives presentedas documents. It is up to the team to decide whether or not they need to go beyond the essentias, addingdetai in a natura ashion as they encounter probems that the bare essentias cannot cope with.


8/2/2019 IJI Use-Case2 0 2

13/54USE-CASE 2.0 The Defnitive Guide Page 13 20052011 IA JACS ITEATIAl SA. All IGTS ESEED.

Use-Case 2.0 ContentUse-Case 2.0 consists o a set o things to work with and a set o things to do.

Things to Work With

The subject o Use-Case 2.0 is the requirements, the system to be deveoped to meet the requirements, and the testsused to demonstrate that the system meets the requirements. At the heart o Use-Case 2.0 are the use case, the storyand the use-case sice. These capture the requirements and drive the deveopment o the system. Figure 5shows howthese concepts are reated to each other. It aso shows how changes and deects impact on the use o Use-Case 2.0.

FIGUR 5: USCAS 2.0 CNCPT MAP.

The stakehoders are the peope, groups, or organizations who aect or are aected by a sotware system. The requirements arewhat the system must do to satisy the stakehoders. It is important to discover what is needed rom the sotware system, sharethis understanding among the stakehoders and the team members, and use it to drive the deveopment o the new system.In Use-Case 2.0 the requirements are captured as a set o use cases, which are scope managed and addressed as a set o use-case sices. Any changes requested by the stakehoders resut in additions or changes to the set o use cases and use-case sices.

STAKEHOLDERS

MAY ASK FOR

CHANGE

REQUIREMENTS

USE CASE

USE-CASE SLICE

CAPTURED AS

SYSTEM

TEST

DEFECT

SCOPE MANAGED

AND ADDRESSED

AS A SET CF

STORY

ARE THE

SOURCE OF

ADD OR

CHANGE

MAY

REQUIRE

NEW

HELP TO

IDENTIFY

ARE INVOLVED IN

AND PRIORITIZE

COMMUNICATE

BY TELLING

EXPLORED

BY TELLING

VERIFY THE

IMPLEMENTATION OF

IMPLEMENTED BY

SCOPE AND GOALS

MODELED AS A SET OF

DRIVE THE

DEVELOPMENT OF

VERIFIES TH

QUALITY AND

COMPLETENESS OPREVENTS THE

COMPLETION OF FIND

FIXED BY

IMPROVING

8/2/2019 IJI Use-Case2 0 2


The system is the system to be buit. It is typicay a sotware system athough Use-Case 2.0 can aso be used inthe deveopment o new businesses (where you treat the business itse as a system), and combined hardwareand sotware systems (embedded systems).

It is the system that impements the requirements and is the subject o the use-case mode. The quaity andcompeteness o the system is verifed by a set o tests. The tests aso veriy whether or not the impementa-tion o the use-case sices has been a success. I deects are ound during the testing then their presence wiprevent the competion o the use-case sice unti they have been fxed and the system improved.

Teing stories bridges the gap between the stakehoders, the use cases and the use-case sices. It is how thestakehoders communicate their requirements and expore the use cases. Understanding the stories is asothe mechanism or fnding the right use-case sices to drive the impementation o the system.

Use CasesA use case is a the ways o using a system to achieve a particuar goa or a particuar user. Taken together theset o a the use cases gives us a o the useu ways to use the system.

A use case is:

A sequence o actions a system perorms that yiedsan observabe resut o vaue to a particuar user.

That specifc behavior o a system, which participates in a coaboration with a user to deiversomething o vaue or that user.

The smaest unit o activity that provides a meaningu resut to the user.

The context or a set o reated requirements.

To understand a use case we te stories. The stories coverboth how to successuy achieve the goa and how to han-de any probems that occur on the way. They hep us to un-derstand the use case and impement it sice by sice.

As Figure 6 shows, a use case undergoes severa statechanges rom its initia identifcation through to its uf-ment by the system. The states constitute important waypoints in the understanding and impementation o the usecase indicating:

1) Goa Estabished: when the goa o the use case hasbeen estabished.

2) Story Structure Understood: when the structure othe use-case narrative has been understood enoughor the team to start work identiying and impementing the frst use-case sices. FIGUR 6: TH lIFCCl F A US CAS

GOAL

ESTABLISHED

STORY STRUCTURE

UNDERSTOOD

SIMPLEST STORY

FULFILLED

SUFFICIENT STORIES

FULFILLED

ALL STORIES

FULFILLED

8/2/2019 IJI Use-Case2 0 2


3) Simpest Story Fufed: when the system ufs the simpest story that aows a user to achieve thegoa.

4) Sucient Stories Fufed: when the system ufs enough o the stories to provide a usabe soution.

5) A Stories Fufed: when the system ufs a the stories tod by the use case.

This wi be achieved by impementing the use case sice-by-sice. The states provide a simpe way assess theprogress you are making in understanding and impementing the use case.

Use-Case SicesUse cases cover many reated stories o varying importance and priority. There are oten too many stories todeiver in a singe reease and generay too many to work on in a singe increment. ecause o this we need away to divide the use cases into smaer pieces that 1) aow us to seect which pieces o the use case to deivewhen, 2) provide a suitabe unit or deveopment and testing by the deveopment team, and 3) aow us tohave sma and simiary sized pieces o work that ow quicky through deveopment.

A use-case sice is one or more stories seected rom a use case to orm a work item that is o cear vaue to the

customer. It acts as a pacehoder or a the work required to compete the impementation o the seectedstories. As we saw earier when we discussed how the use-case sices are more than just requirements and testcases, the use-case sice evoves to incude the corresponding sices through design, impementation and test

The use-case sice is the most important eement o Use-Case2.0, as it is not ony used to hep with the requirements but todrive the deveopment o a system to uf them.

Use-case sices:

Enabe use cases to be broken up into smaer,

independenty deiverabe units o work. Enabe the requirements contained in a set o use

cases to be ordered, prioritized and addressed inparae.

link the dierent system modes (requirements,anaysis, design, impementation and test) used inuse-case driven deveopment.

As Figure 7 shows, a use-case sice undergoes severa statechanges rom its initia identifcation through to its fna ac-ceptance. The states constitute important way points in theunderstanding, impementation and testing o the use-casesice indicating:

1) Scoped: when it has been scoped and the extent othe stories covered has been carifed.

SCOPED

PREPARED

ANALYZED

IMPLEMENTED

VERIFIED

FIGUR 7: TH lIFCCl F A USCAS SlIC

8/2/2019 IJI Use-Case2 0 2


2) Prepared: when the sice has been prepared by enhancing the narrative and test cases to cearydefne what it means to successuy impement the sice.

3) Anayzed: when the sice has been anayzed so its impact on the components o the system is understood and the pieces aected are ready or coding and deveoper testing.

4) Impemented: when the sotware system has been enhanced to impement the sice and the sice is

ready or testing.

5) eried: and fnay when the sice has been verifed as done and is ready or incusion in a reease.The states provide a simpe way to assess the progress you are making in understanding and impementing the use-case sices. They aso denote the points when the sice is at rest and coud potentiaybe handed over rom one person or team to another.

The states provide a simpe way to assess the progress you are making in understanding and impementingthe use-case sices. They aso denote the points when the sice is at rest and coud potentiay be handed overom one person or team to another. To the casua observer gancing at the states, this might ook ike a wa-tera process:

scoping>preparation>anaysis>impementation>verifcation. Theres a big dierence, though. In a wateraapproach, a the requirements are prepared beore the anaysis starts, and a the anaysis is competed beorethe impementation starts, and a the impementation is competed beore the verifcation starts. ere we aredeaing with an individua use-case sice. Across the set o sices a the activities coud be going on in paraeWhie one use-case sice is being verifed, another use-case sice is being impemented, a third is being impe-mented, and a ourth being anayzed. In the next chapter we wi expore this more when we ook at usingUse-Case 2.0 with dierent deveopment approaches.

StoriesTeing stories is how we expore the use cases with our stakehoders. Each story o vaue to the users and

other stakehoders is a thread through one o the use cases. The stories can be unctiona or non-unctionain nature.

A story is described by parto the use-case narrative, oneor more ows and specia re-quirements, and one or moretest cases. The key to fndingeective stories is to under-stand the structure o the use-case narrative. The network o

ows can be thought o as amap that summarizes a thestories needed to describe theuse case. Figure 8 iustrates thereationship between the owso a use-case narrative and thestories it describes.

FIGUR 8: TH RlATINSHIP BTWN TH FlWS AND TH STRIS

1 USE CASE

STEP 1

STEP 2

STEP 3

STEP 4

STEP 5

STEP 6

STEP 7

START OF USE CASE

END OF USE CASE

MANY STORIES..

ALT 1

ALT 3

ALT 2

8/2/2019 IJI Use-Case2 0 2


There are two common approaches to identiying the stories and creating the use-case narrative:

Top Down: Some peope ike to take a top down approach where they 1) identiy the use case, 2) outine the steps o the basic ow, and 3) brain-storm aternative ows based on the basic ow. This structures the narrative and aows them to identiy their stories.

Bottom Up: Using the bottom up approach we start by brainstorming some stories and then groupingthese by theme to identiy our use cases. The set o stories are then examined to hep us identiy thebasic and some o the aternative ows. The use-case structure then eads us to identiy any missingstories and make sure that a the stories are we-ormed and compementary.

You shoud pick the approach that works best or your stakehoders. You can o course combine the two ap-proaches and work both top down, rom your use cases, and bottom up rom any suggested new stories.

The stories are a useu thinking too to hep us fnd the right use-case sices and, most importanty, the righttest cases. We dont need to track the state o the stories themseves as it is the execution o the test casesthat shows us how compete the system is, and the progress o the use cases and use-case sices that drive the

deveopment.

Defects and ChangesAthough not a direct part o Use-Case 2.0, it is important to understand how deects and changes are reatedto the use cases and the use-case sices.

Changes requested by the stakehoders are anayzed against the current use-case mode, use cases, and use-case sices. This enabes the extent o the change to be quicky understood. For exampe adding a new usecase to the system is a major change as it changes the systems overa goas and purpose; whereas a changeto an existing use case is typicay much smaer, particuary i it is to a story that has not been aocated to a

sice and prepared, anayzed, impemented or verifed.

Deects are handed by tracking which use-case sices, and by impication which test cases, resuted in theirdetection. I they are ound during the impementation or verifcation o a use-case sice then that sice cannotadvance unti the deect is addressed and the test can be passed. I they are ound ater during regression testing then the reationship between the aied test cases and the use cases aows you to quicky discern whatimpact the deect wi have on the users and the usabiity o the system.

Work ProductsThe use cases and the use-case sices are supported by a number o work products that the team uses to hepshare, understand, document them. Figure 9 shows the fve Use-Case 2.0 work products (in grey) and theirreationships to the requirements, use cases, use-case sices, stories, tests, and the system (in yeow).

8/2/2019 IJI Use-Case2 0 2


FIGUR 9: TH USCAS 2.0 WRK PRDUCTS

The use-case mode visuaizes the requirements as a set o use cases, providing an overa big picture o thesystem to be buit. The mode defnes the use cases and provides the context or the eaboration o the in-dividua use cases. The use cases are expored by teing stories. Each use case is described by 1) a use-casenarrative that outines its stories and 2) a set o test cases that compete the stories. The stories are describedas a set o ows. These can be compemented with a set o specia requirements that wi inuence the storieshep you assign the right stories to the use-case sices or impementation, and most importanty defne theright test cases.

The use-case mode is compemented by supporting inormation. This captures the defnitions o the termsused in the use-case mode and when outining the stories in the use-case narratives. It aso captures anysystem-wide requirements that appy to a o the use cases. Again these wi inuence the stories seectedrom the use cases and assigned to the use-case sices or impementation.

You may be disconcerted by the ack o any expicit work products to capture and document the stories andhe use-case sices. These are not needed as they are uy documented by the other work products. I requiredyou can ist the stories reated to a use case as an extra section in the use-case narrative but this is not essentia

REQUIREMENTS

CAPTURED AS

SCOPE MANAGED AND

ADDRESSED AS A SET OF

USE CASE

SYSTEM

TEST

IMPLEMENTED

BY

USE-CASE SLICE VERIFIES THEQUALITY AND

COMPLETENESS OF

STORY

USE-CASE MODEL

COMPLEMENTED

BY

VISUALIZED AS

SYSTEM-WIDEREQUIREMENTS

DEFINITIONS

DEFINES AND

CONTEXTUALIZES

EXPLORED

BY TELLINGSYSTEM-WIDEREQUIREMENTS

DEFINITIONS

DETAILED BY

A SET OF

USE-CASENARRATIVE

DESCRIBED

BY

REFERENCES

OUTLINE

INFLUENCE

INFLUENCE

ASSIGNED

TO

FLOWS, SPECIAL REQUIREMENT AND SYSTEM-WIDE

REQUIREMENTS ARE GROUPED INTO STORIES AND ASSIGNED TO

SLICES FOR ELABORATION, ANALYSIS, DESIGN AND TESTING.. THE

STORIES CAN BE EXPLICITLY LISTED AS PART OF THE USE-CASE

NARRATIVE OR TACTILY IMPLIED BY THE USE-CASE SLICES.

SCOPE & GOALS MODELED

AS A SET OF

USE-CASEREALIZATION

EXPLAIN HOW THE

REQUIREMENTSARE HANDLED BY

COMPLETED

BY

TESTCASE

VERIFIED BY

EXECUTING

EXECUTED

AS PART OF A

IMPACT ON

THE SYSTEM

EXPLAINED BY

8/2/2019 IJI Use-Case2 0 2


Working with the use cases and use-case sicesAs we as creating and tracking the work products, you wi aso need to track the states and properties o theuse cases and the use-case sices. This can be done in many ways and in many toos. The states can be trackedvery simpy using post-it notes or spreadsheets. I more ormaity is required one o the many commerciayavaiabe requirements management, change management or deect tracking toos coud be used.

Figure 10 shows a use case and some o its sices captured on a set o post-it notes.

FIGUR 10: CAPTURING TH PRPRTIS F A US CAS AND ITS SlICS USING PSTIT NTS

The use case shown is use-case 7 rowse and Shop rom an on-ine shopping appication. Sices 1 and 2 o theuse case are based on individua stories derived rom the basic ow: Seect and uy 1 Product and Seect anduy 100 Products. Sice 3 is based on mutipe stories covering the avaiabiity o the various support systemsinvoved in the use case. These stories cover a number o the aternative ows.

The essentia properties or a use case are its name, state and priority. In this case the popuar MoSCoW (MustShoud, Coud, Woud) prioritization scheme has been used. The use cases shoud aso be estimated. In thiscase a simpe scheme o assessing their reative size and compexity has been used.

The essentia properties or a use-case sice are 1) a ist o its stories, 2) reerences to the use case and the ows

that defne the stories, 3) reerences to the tests and test cases that wi be used to veriy its competion, and 4)an estimate o the work needed to impement and test the sice. In this exampe the stories are used to namethe sice and the reerences to the use case are impicit in the sices number and ist o ows. The estimateshave been added ater ater consutation with the team. These are the arge numbers towards the bottomright o each post-it note. In this case the team has payed panning poker to create reative estimates usingstory points; 5 story points or sices 7.1 and 7.2, and 13 story points or sice 7.3 which the team beieve witake more than twice the eort o the other sices. Aternativey idea days, t-shirt sizing (XS, S, M, l, Xl, XXl,XXXl), or any other popuar estimating technique coud be used.

7.1 Select and Buy1 Product

Flows: BFTest: 1 Product,default payment,valid details

5

7.2 Select and Buy100 Products

Flows: BFTest: 100 Products,default payment,valid details

5

7.3 SupportSystems UnavailableFlows: BF, Ag, A10,A11, A12Test: Select Product,Provide Information,Disconnect each systemin between 13

SHOPPER

7. Browseand Shop

Priority: MUSTRelease: 1Size: Very LargeComplexity: High

A USE CASE AND ITS PROPERTIES

CAPTURED ON A POST-IT NOTE

SOME SLICES

FROM THE USE CASE

CAPTURED ON THEIR

OWN POST-IT NOTES

8/2/2019 IJI Use-Case2 0 2


The use cases and the use-case sices shoud aso be ordered so that the most important ones are addressedfrst. Figure 11 shows how these post-its can be used to buid a simpe product back og on a white board.eading rom et to right you can see 1) the big picture iustrated by use-case diagrams showing the scopeo the compete system and the frst reease, 2) the use cases seected or the frst reease and some o theirsices which have been identifed but not yet detaied and ordered, 3) the ordered ist o sices ready to bedeveoped in the reease and fnay 4) those sices that the team have successuy impemented and verifed

FIGUR 11: USING US CASS AND USCAS SlICS T BUIlD A PRDUCT BACKlG

Figure 11 is incuded or iustrative purposes ony, there are many other ways to organize and work withyour requirements. For exampe many teams worry about their post-it notes aing o the whiteboard. Theseteams oten track the state o their use cases and use-case sices using a simpe spreadsheet incuding worksheets such as those shown in Figure 12 and Figure 13.

FIGUR 12: TH USCAS WRKSHT FRM A SIMPl USCAS TRACKR

USE CASE NAME RELEASE PRIORITY STATE SIZE COMPLEXITY

7

14

17

12

13

16

11

1

2

3

4

BROWSE AND SHOP

GET NEW AND SPECIAL OFFERS

MAINTAIN PRODUCTS & AVAILABILITY

TRACK ORDERS

LOCATE STORE

SET PRODUCT OFFERS

GET SHOPPING HISTORY

BUILD HOUSE

DESIGN INTERIOR

BUILD GARDEN

FILL GARDEN

1

1

1

1

1

1

1

1 - MUST

1 - MUST

1 - MUST

2 - SHOULD

2 - SHOULD

2 - SHOULD

3 - COULD

STORY STRUCTURE UNDERSTOOD







GOAL ESTABLISHED

GOAL ESTABLISHED

GOAL ESTABLISHED

GOAL ESTABLISHED

VERY LARGE

MEDIUM

LARGE

LARGE

SMALL

MEDIUM

SMALL

HIGH

MEDIUM

HIGH

LOW

LOW

HIGH

MEDIUM

8/2/2019 IJI Use-Case2 0 2


FIGUR 13: TH USCAS SlIC WRKSHT FRM A SIMPl USCAS TRACKR

These iustrations are incuded to hep you get started. The use cases and the use-case sices are centra to ev-erything the team does, so use whatever techniques you need to make them tangibe and visibe to the team

Fee ree to add other attributes as and when you need them, or exampe to record the source o the use caseor its owner, or to target the use-case sices on a particuar increment within the reease.

Competing the Work ProductsAs we as tracking the use cases and the use-case sices you wi need to, at east, sketch out and share thesupporting work products.

A o the work products are defned with a number o eves o detai. The frst eve o detai defnes the bareessentias, the minima amount o inormation that is required or the practice to work. Further eves o de-tai hep the team cope with any specia circumstances they might encounter. For exampe, this aows smacoaborative teams to have very ightweight use-case narratives defned on simpe index cards and arge dis-

tributed teams to have more detaied use-case narratives presented as documents. The teams can then growthe narratives as needed to hep with communication, or thoroughy defne the important or saety criticarequirements. It is up to the team to decide whether or not they need to go beyond the essentias, addingdetai in a natura ashion as they encounter probems that the bare essentias cannot cope with.

Figure 14 shows the eves o detai defned or the set o Use-Case 2.0 work products. The ightest eve odetai is shown at the top o the tabe. The amount o detai in the work product increases as you go down thecoumns enhancing and expanding the content.

FIGUR 14: WRK PRDUCT llS F DTAIl

USE CASE SLICE STORIES FLOW TEST CASES STATE ORDER

7

7

7

17

1

2

2

7

7

17

7

5

5

1

BROWSE AND SHOP

BROWSE AND SHOP

BROWSE AND SHOP

MAINTAIN PRODUCTS AND AVAILABILITY

BUILD HOUSE

DESIGN INTERIOR

DESIGN INTERIOR

BROWSE AND SHOP

BROWSE AND SHOP

MAINTAIN PRODUCTS AND AVAILABILITY

BROWSE AND SHOP

WALK THROUGH DESIGN

WALK THROUGH DESIGN

BUILD HOUSE

7.1

7.2

7.4

17.1

1.1

2.1

2.4

7.5

7.6

17.2

7.7

5.1

5.2

1.2

BF

BF

A4, A5, A6

BF

BF

BF, A3

A6

A9, A11, A12

A7

A2, A3

A14

BF, A1

A2

A2, A5

1

2

3

4

5

6

7

8

9

10

11

12

13

14

1

1

1

1

1

1

1

1

1

1

1

1

1

1

13

13

3

20

5

5

3

5

13

5

20

8

2

1

7.1.1

7.2.1, 7.2.3

7.3.1, 7.3.2

17.1.1, 17.1.2

1.1.1, 1.1.2, 1.1.3

1.2.1, 1.2.2, 1.2.3

PREPARED

PREPARED

SCOPED

SCOPED

SCOPED

VERIFIED

SCOPED

SCOPED

SCOPED

SCOPED

SCOPED

SCOPED

SCOPED

SCOPED

SELECT AND BUY 1 PRODUCT

SELECT AND BUY MANY PRODUCTS

HANDLE PAYMENT AND DELIVERY DETAILS

CREATE NEW PRODUCT

ADD FIRST HOUSE

DESIGN ROOM

PURCHASE CONTENTS

HANDLE LOSS OF KEY SUPPORT SYSTEMS

PRODUCT OUT OF STOCK

HANDLE PRODUCT DETAIL ERRORS

QUIT SHOPPING

NAVIGATE DESIGN

HANDLE NAVIGATION ERRORS

ADD OR REMOVE FLOOR

(STORY POINTS) RELEASEESTIMATE TARGET

USE-CASE MODEL USE-CASE NARRATIVE USE--CASE REALIZATION TEST CASE SUPPORTING

INFORMATION

SKETCH:

BARE ESSENTIALS:

ENHANCED:

EXPANDED:

FURTHER EXPANDED:

BRIEFLY DESCRIBED

BULLETED OUTLINE

ESSENTIAL OUTLINE

FULLY DESCRIBED

TEST IDEASFORMULATED

SCENARIO CHOSEN

VARIABLES IDENTIFIED

VARIABLES SET

SCRIPTED/AUTOMATED

OUTLINED

SIMPLY DEFINED

MODELLED& ILLUSTRATED

COMPREHENSIBLYDEFINED

VALUE ESTABLISHED

SYSTEM BOUNDARY

ESTABLISHED

STRUCTURED

IMPLEMENTATION

ELEMENTS IDENTIFIED

RESPONSIBILITIES

ALLOCATED

INTERACTION DEFINED

8/2/2019 IJI Use-Case2 0 2


The good news is that you aways start in the same way, with the bare essentias. The team can then continu-ay adapt the eve o detai in their use-case narratives to meet their emerging needs. The eve o detai canaso be adjusted to reduce waste; anything beyond the essentias shoud have a cear reason or existing or beeiminated. As Einstein (is attributed to have) said Everything shoud be made as simpe as possibe, but notsimper.

For more inormation on the work products and their eves o detai see Appendix 1: Work Products.

Things to doUse-Case 2.0 breaks the work up into a number o essentia activities that need to be done i the use cases areto provide rea vaue to the team. These activities are shown in Figure 13 where they are grouped into thoseactivities used to discover, order and veriy the requirements, and those used to shape, impement and testthe system. The soid chevrons indicate activities that are expicity defned by the practice. The dashed chev-rons are pacehoders or other activities that the practice depends on to be successu. Use-Case 2.0 does notcare how these activities are perormed, it just needs them to be done.

FIGUR 15: TH ACTIITIS IN USCAS 2.0

ead Figure 15 rom et to right to get an impression o the order in which the activities are frst perormedThe activities themseves wi a be perormed many times in the course o your work. Even a simpe activitysuch as Find Actors and Use Cases may need to be perormed many times to fnd a the use cases, and maybe conducted in parae with, or ater, the other activities. For exampe, whist continuing to Find Actors andUse Cases you may aso be impementing some o the sices rom those use cases ound earier.

The rest o this chapter provides an introduction to each o the activities, oowing the journey o a use-casesice rom the initia identifcation o its parent use case through to its fna testing and inspection. The nextchapter incudes a brie discussion on how to organize the activities to support dierent deveopment ap-proaches such as Scrum, Kanban, Iterative and Watera.

FIND ACTORS

AND USE CASES

SLICE THE

USE CASES

INSPECT AND ADAPT

THE USE CASES

TEST THE SYSTEM

(AS A WHOLE)

TO DISCOVER, ORDER AND VERIFY THE REQUIREMENTS

PREPARE A

USE-CASE SLICE

ANALYZE A

USE-CASE SLICE

IMPLEMENT SOFTWARE

(FOR A SLICE)

TEST THE SYSTEM

(AS A WHOLE)

TO SHAPE, IMPLEMENT AND TEST THE SYSTEM SLICE-BY-SLICE

8/2/2019 IJI Use-Case2 0 2


Find Actors and Use CasesFirst you need to fnd some actors and use cases to hep you to:

Agree on the goas o the system. Agree on new system behavior. Scope reeases o the system. Agree on the vaue the system provides.

Identiy ways o using and testing the system.

The best way to do this is to hod a use-case modeingworkshop with your stakehoders. There is no need to fnda the systems use cases, just ocus on those that are go-ing to provide the stakehoders with the vaue they areooking or. ther actors and use cases wi be ound asyou inspect and adapt the use cases.

As the use cases are discovered they shoud be ordered tosupport the teams reease pans. ne o the great thingsabout use cases is that they enabe high-eve scope man-agement without the need to discover or author a thestories. I a use case isnt needed then there is no need todiscuss or document its stories. I the use case is in scope itshoud be outined so that there is enough inormation tostart the sicing process.

epeat this activity as necessary to evove your mode andfnd any missing actors or use cases.

TIP: MODEL STORM TO KICKSTART YOUR USE-CASE MODEL

The formal nature of the use-case model, and its

use of the Unied Modeling Language, can be a

barrier to involving stakeholders in the

modelling eort.

A great way to overcome this is to simply get the

stakeholders together to brainstorm some

dierent users and their goals using

post-it-notes (vertical for users and horizontal

for goals.) Then facilitate the grouping of theseinto actors and use cases, which the stakehold-

ers will then nd it very easy to quantify, outline,

and order.

8/2/2019 IJI Use-Case2 0 2


Sice the Use Casesext you need to create your frst use-case sices. You do this to:

Create suitaby sized items or the team to work on. Fit within the time and budget avaiabe. Deiver the highest vaue to the users, and other stakehoders. Demonstrate critica project progress or understanding o needs.

Even the simpest use case wi cover mutipe stories.You need to sice the use cases to seect the stories tobe impemented. You shoud do the sicing with yourstakehoders to make sure that a the sices created areo vaue and worth impementing. Dont sice up a theuse cases at once. Just identiy enough sices to meetthe immediate needs o the team.

You dont need to competey sice up the use cases, justpu out the sices that are needed to progress the workand eave the rest o the stories in the use cases or sic-ing when and i they are needed. You can even adopta pu mode where the deveopers ask or new sicesto be identifed as and when they have the capacity toimpement them.

The sices created shoud be ordered or deivery tomake sure the deveopment team tackes them in theright order. Again, you shoud do this with your stake-hoders and other team members to make sure that theordering defnes the smaest usabe system possibe.

The best way to do this is to consider the combinationo priority, vaue, risk and necessity.

epeat this activity whenever new sices are needed.

TIP: YOU ONLY NEED THEBASIC FLOW OF THE MOSTIMPORTANT USE CASE TOCREATE YOUR FIRST SLICE

Many people think that they need to have

outlined all the use cases before they can start

to create their slices. This leads to the adoptionof a waterfall approach that delays the creation

of valuable, working software.

One slice from one use case is enough to get the

team started on the development and testing of

the system.

The rst slice should always be based on the

basic ow. For some complex systems this slice

may not even cover the whole of the ow. Youmay just take a sub-set of the basic ow,

skipping the detail of some steps snd stubbing

up the solution for others, to attack the biggest

challenges in implementing the use case and

learn whether or not it can be implemented.

8/2/2019 IJI Use-Case2 0 2


Prepare a Use-Case Sicence a sice is seected or deveopment more work is required to:

Get it ready or impementation. Ceary defne what it means to successuy impement the sice Defne required characteristics (i.e. non-unctiona requirements). Focus the deveopment o sotware towards the tests it must meet.

Preparing a use-case sice is a coaborative activity,you need input rom the stakehoders, deveopers,and testers to cariy the use-case narrative and de-fne the test cases.

When preparing a use-case sice you shoud ocuson the needs o the deveopers and testers who wiimpement and veriy the sice. Think about howthey wi access the inormation they need. Wi theybe abe to tak to subject matter experts to esh outthe stories, or wi they need everything to be docu-mented or them? You aso need to baance the workbetween the detaiing o the use-case narrative andthe detaiing o the test cases. The more detai youput in the use-case narrative the easier it wi be tocreate the test cases. n the other hand the ighterthe use-case narrative the ess dupication and rep-etition there wi be between it and the test cases.You shoud create the use-case narrative and the testcases at the same time, so that the authors can ba-ance their own needs, and those o their stakehoders. There may sti be work to do i the test cases are to beautomated but there wi be no doubt about what needs to be achieved by a successu impementation.

Perorm this activity at east once or each sice. epeat this activity whenever there are changes appied tothe sice.

TIP: IF THE SLICE HAS NO TESTCASES THEN IT HAS NOT BEENPROPERLY PREPARED

When you prepare a use-case slice do not forget

to dene the test cases that will be used to verify

it. It is by looking at the test cases that we know

what really needs to be achieved.

The test cases provide the developers with an

empirical statement of what the system needs

to do. They will know that the development of

the slice is not completed until the system

successfully passes all the test cases.

8/2/2019 IJI Use-Case2 0 2


Anayze a Use-Case Siceeore you start coding you shoud anayze the sice to:

Understand its impact on the system eements that wi be used to impement it. Defne the responsibiities o the aected system eements. Defne how the system eements interact to perorm the use case.

When a team is presented with a new sice to impementthe frst thing to do is to work out how it wi aect thesystem. ow many bits o the system are going to needto be changed and in what way? ow many new thingsare needed and where do they ft?

Anayzing the target sices is oten a pre-cursor to thepanning o the deveopment tasks. It aows the team topan the impementation o the sice as a set o smaercode changes rather than as one, arge, indivisibe pieceo work. Aternativey, the sice itse can be used as the

unit o work and anayzing the sice is just the fna thingto be undertaken by the deveoper beore the codingstarts.

As the team buid their understanding o the systemand its architecture they wi fnd it easier and easierto anayze the sices, and wi oten be abe to do it intheir heads. It is sti worth sketching the anaysis outwith some coeagues beore committing to the coding.

This wi vaidate a ot o the design decisions, check that nothing has been misunderstood, and provide traceabiity or use ater when investigating the impact o deects and changes. The resut o this kind o anaysis isknown as a use-case reaization as it shows how the use case is reaized by the eements o the impementingsystem.

Perorm this activity at east once or each sice. epeat this activity whenever there are changes appied tothe sice.

TIP: KEEP THE ANALYSISCOLLABORATIVE ANDLIGHTWEIGHT

The easiest way to analyze the use-case slice is

to get the team together to discuss how it

would aect the various elements of the system.

As the team walks-through the design theypicture it on a white board, typically in the form

of a simple sequence or collaboration diagram,

which can then be captured as a photograph or

in the teams chosen modelling tool.

8/2/2019 IJI Use-Case2 0 2


Impement Software (for a Sice)You are now ready to design, code, unit test, and integrate the sotware components needed to impement ause-case sice.

The sotware wi be deveoped sice-by-sice, with dierent team members working in parae on dierensices. Each sice wi require changes to one or more pieces o the system. To compete the impementation

o a sice the resuting pieces o sotware wi have to be unit tested and then integrated with the rest o thesystem.

Test the System (for a Sice)ext, independenty test the sotware to veriy that the use-case sice has been impemented successuy.Each use-case sice needs to be tested beore it can be considered compete and verifed. This is done by suc-cessuy executing the sices test cases. The independence o the use-case sices enabes you to test it as soonas it is impemented and provide immediate eedback to the deveopers.

Use-case 2.0 works with most popuar testing practices. It can be considered a orm o test-driven deveop-ment as it creates the test cases or each sice up-ront beore the sice is given to the deveopers or impe-

mentation.

Test the System as a WhoeEach increment o the sotware system needs to be tested to veriy that it correcty impements a o the newuse-case sices without breaking any other parts o the system. It is not sucient to just test each sice as it iscompeted. The team must aso test the system as a whoe to make sure that a o the impemented sices arecompatibe, and that the changes to the system havent resuted in the system aiing to support any previ-ousy verifed sices.

The test cases produced using Use-Case 2.0 are robust and resiient. This is because the structure o the use-case narratives resuts in independenty executabe, scenario-based test cases.

8/2/2019 IJI Use-Case2 0 2


Inspect and Adapt the Use CasesYou aso need to continuousy tune and evauate the use cases, and use-case sices to:

ande changes. Track progress Fit your work within the time and budget avaiabe. Keep the use-case mode up to date.

Tune the size o the sices to increase throughput.

As the project progresses it is essentia that you con-tinuay work with your use-case mode, use cases anduse-case sices. Priorities change, essons are earnt andchanges are requested. These can a have an impacton the use cases and use-case sices that have areadybeen impemented, as we as those sti waiting to beprogressed. This activity wi oten ead to the discoveryo new use cases and the reactoring o the existing usecases and use-case sices.

The varying demands o the project may need you totune your use o Use-Case 2.0 and adjust the size o thesices or the eve o detai in your use-case narratives,supporting defnitions and test cases. It is importantthat you continuay inspect and adapt your way-o-working as we as the use cases and use-case sices youare working with.

Perorm this activity as needed to maintain your usecases and hande changes.

TIP: DONT FORGET TOMAINTAIN YOUR BACKLOG OFUSE-CASE SLICES

By ordering your slices and tracking their state

(scoped, prepared, analyzed, implemented,

veried) you create a backlog of the

requirements left to implement. This list should

be continually monitored and adjusted to

reect the progress of the team and the desires

of the stakeholders.

As the project progresses you should monitor

and adjust the slice size to eliminate waste and

improve the teams eectiveness.

8/2/2019 IJI Use-Case2 0 2


Using Use-Case 2.0Use-Case 2.0 can be used in many dierent contexts to hep produce many dierent kinds o system. In thischapter we ook at using use cases or dierent kinds o system, dierent kinds o requirements and dierendeveopment approaches.

Use-Case 2.0: Appicabe or a types o systemMany peope think that use cases are ony appicabe to user-intensive systems where there is a ot o interac-tion between the human users and the system. This is strange because the origina idea or use cases camerom teecom switching systems, which have both human users (subscribers, operators) and machine usersin the orm o other interconnected systems. Use cases are o course appicabe or a systems that are used and that means o course a systems.

Use-Case 2.0: Its not just for user-intensive appications

In act use cases are just as useu or embedded systems with itte or no human interaction as they are oruser intensive ones. owadays, peope are using use cases in the deveopment o a kinds o embedded sot-ware in domains as diverse as the motor, consumer eectronics, miitary, aerospace, and medica industries.Even rea-time process contro systems used or chemica pants can be described by use cases where each usecase ocuses on a specifc part o the pants process behavior and automation needs.

A that is needed or use cases to be appropriate is or the system to coaborate with the outside word, re-gardess o whether the users are humans other systems. Their appicabiity is ar broader than most peopethink.

Use-Case 2.0: Its not just for software deveopment

The appication o use cases is not imited to sotware deveopment. They can aso hep you to understandyour business requirements, anayze your existing business, design new and better business processes, andexpoit the power o IT to transorm your business. y using use cases recursivey to 1) mode the business andits interactions with the outside word and 2) mode the systems needed to support and improve the businessyou can seamessy identiy where the systems wi impact on the business and which systems you need tosupport the business.

The use cases used to mode the business are oten reerred to as business use cases. They provide the contextor your IT systems deveopment work, aowing the business deveopment and the IT deveopment to becarried out in perect synchronization. ot ony can you deveop the IT systems sice-by-sice but you can asodeveop your business mode sice-by-sice. This is very poweru as it aows you to evove your business and

its supporting systems in tandem with one another, enabing incrementa business deveopment as we asincrementa systems deveopment.

In the modern word the business and the IT systems that support it can, and shoud, be deveoped in synch(one wont work without the other). The use o use cases and use-case sices at both the business and ITboundaries can cose the gap between the business and the IT enabing them to work as truy coaborativepartners.

8/2/2019 IJI Use-Case2 0 2


Use-Case 2.0: anding a types o requirementAthough they are one o the most popuar techniques or describing systems unctionaity, use cases are asoused to expore their non-unctiona characteristics. The simpest way o doing this is to capture them as parto the use cases themseves. For exampe, reate perormance requirements to the time taken between spe-cifc steps o a use case or ist the expected service eves or a use case as part o the use case itse.

Some non-unctiona characteristics are more subte than this and appy to many, i not a, o the use casesThis is particuary true when buiding ayered architectures incuding inrastructure components such as se-curity, transaction management, messaging services, and data management. The requirements in these areascan sti be expressed as use cases separate use cases ocused on the technica usage o the system. We cathese additiona use cases inrastructure use cases as the requirements they contain wi drive the creation othe inrastructure that the appication wi run on. These use cases and their sices can be considered as cross-cutting concerns that wi aect the behavior o the system when the more traditiona unctiona use cases areperormed. For exampe a use case coud be created to expore how the system wi manage database transac-tions incuding a o the dierent usage scenarios such as the schemes or data ocking, data caching, commitand ro-back. This use case woud appy every time another use case retrieves or stores data in the system.

Combining these inrastructure use cases with other techniques such as separation o concerns and aspect-oriented programming aows these common requirements to be addressed without having to change theimpementation o the existing unctiona use cases.

Use-Case 2.0: Appicabe or a deveopment approachesUse-Case 2.0 works with a popuar sotware deveopment approaches incuding:

ackog-driven iterative approaches such as Scrum, EssUP and penUP

ne-piece ow based approaches such as Kanban A-in-one go approaches such as the traditiona Watera

In the oowing 3 short sections we wi iustrate how Use-Case 2.0 and, in particuar, use-case sices can hepwith each o these. These sections are not as se contained as the rest o the document and rey upon thereader having a basic understanding o the approach being discussed. We recommend that you ony read thesections or the approaches you are amiiar with.

Use-Case 2.0 and backog-driven iterationseore adopting any backog-driven approach you must understand what items wi go in the backog. Thereare various orms o backog that teams use to drive their work incuding product backogs, reease backogs

and project backogs. egardess o the terminoogy used they a oow the same principes. The backogitse is an ordered ist ist o everything that might be needed and is the singe source o requirements or anychanges to be made. The basic concept o a backog is iustrated by Figure 16.

8/2/2019 IJI Use-Case2 0 2


FIGUR 16: A BASIC BACKlG

When you use Use-Case 2.0 the use-case sices are the primary backog items. The use o use-case sices en-sures that your backog items are we-ormed, as they are naturay independent, vauabe and testabe. Thestructuring o the use-case narrative that defnes them makes sure that they are estimabe and negotiabeand the use-case sicing mechanism enabes you to sice them as sma as you need to support your deveop-ment team.

The use cases are not put into the ordered ist themseves as it is not cear what this woud mean. Does it meanthat this is where the frst sice rom the use case woud appear or where the ast sice rom the use case woudappear? I you want to pace a use case into the ist beore sicing just create a dummy sice to represent thewhoe use case and insert it into the ist.

When you adopt a backog-driven approach it is important to reaize that the backog is not buit and com-peted up-ront but is continuay worked on and refned, something that is oten reerred to as grooming ormaintaining the backog. The typica sequence o activities or a backog-driven, iterative approach is shownin Figure 17.

MOSTIMPORTANT

LEAST

IMPORTANT

WHERE THE TEAM WILL FINISH...

..AT ITS SLOWEST SPEED

..AT ITS AVERAGE SPEED

..AT ITS FASTEST SPEED

WHAT WILL BE DONE NEXT.

WHATS BEEN DONE}

BACKLOG

8/2/2019 IJI Use-Case2 0 2


FIGUR 17: USCAS 2.0 ACTIITIS FR ITRATI DlPMNT APPRACHS

eore the deveopment starts the backog is prepared; Find Actors and Use Cases is used to buid the initiause-case mode and scope the system, Sice the Use Cases is used to create the initia set o most importantuse-case sices to seed the backog, and Prepare Use-Case Sice is used to get one or more o these ready ordeveopment in the frst iteration.

nce the backog is up and running you can start the frst deveopment iteration. Every iteration starts with

some panning. During this panning you may need to use Sice the Use Cases to urther sice the seecteduse-case sices to make sure they are sma enough to compete in the iteration. The deveopment team thenuses Prepare a Use-Case Sice, Anayze a Use-Case Sice, Impement Sotware (or a sice), and Test the System(or a sice) to deveop the identifed sices and add them to the system.

Whie the deveopment is on-going the team aso uses Inspect and Adapt the Use Cases, Sice the Use Casesand Prepare a Use-Case Sice to maintain the backog, hande change and make sure there are enough back-og items ready to drive the next iteration. The team may even need to use Find Actors and Use Cases tohande major changes or discover more use cases or the team. In Scrum it is recommended that teams spend5 to 10 per cent o their time maintaining their backog. This is not an inconsiderabe overhead or the teamand Use-Case 2.0 provides the work products and activities needed to do this easiy and ecienty.

Finay at the end o the iteration the team needs to demonstrate the system and reect on their perormanceduring the iteration. The team shoud use Test the System (as a whoe) to understand where they are, andInspect and Adapt Use Cases to reect on the quaity and eectiveness o their use cases and use-case sices

BEFOREDEVELOPMENT

EVERY DEVELOPMENT ITERATION

}

FIND ACTORSAND USE CASES

SLICE THEUSE CASES

PREPARE A USE-CASE SLICE

SLICETHEUSE

CASES

PLAN THE

TIME BOX

DEMON-

STRATE

AND

REFLECT

TEST THE

SYSTEM(AS A

WHOLE)

INSPECT &ADAPT THEUSE CASES

PREPAREUSE-CASE

SLICE

INSPECT &ADAPT THEUSE CASES

SLICE THEUSE CASES

PREPARE AUSE-CASE

SLICE

FIND ACTORSAND USE

CASES

ANALYZEA USE-CASE

SLICE

IMPLEMENTSOFTWARE

(FOR A SLICE)

TEST THESYSTEM

(FOR A SLICE)

DEVELOP AND TEST SLICES

MAINTAIN THE BACKLOGPREPARE THE BACKLOG

8/2/2019 IJI Use-Case2 0 2


Use-Case 2.0 and one-piece owne-piece ow is an approach that avoids the batching o the requirements seen in the iterative and wateraapproaches. In a one-piece ow approach each requirements item ows through the deveopment processne-piece ow is a technique taken rom ean manuacturing. Figure 18 shows a sma team engaging in one-piece ow passing each item directy rom work station A to to C.

FIGUR 18: BASIC NPIC FlW.

For this to work eectivey you need sma, reguary sized items that wi ow quicky through the system. Fosotware deveopment the requirements are the raw materias and working sotware is the fnished goods.Use cases woud be too irreguary sized and too big to ow through the system. The time at stations A, and Cwoud be too unpredictabe and things woud start to get stuck. Use-case sices though can be sized appropriatey and tuned to meet the needs o the team. Figure 19 iustrates one-piece ow or sotware deveopmenwith use-case sices.

FIGUR 19: NPIC FlW FR SFTWAR DlPMNT WITH USCAS SlICSAs we as owing quicky through the system, there needs to be enough items in the system to keep the teambusy. ne-piece ow doesnt mean that there is ony one requirements item being worked on at a time or thatthere is ony one piece o work between one work station and the next. Work in progress imits are used toeve the ow and prevent any wasteu backogs rom buiding up.

ioannis kounadeas / Fotoia

ioannis kounadeas / Fotoia

8/2/2019 IJI Use-Case2 0 2


Kanban boards are a technique or visuaizing the ow through a production ine. A Kanban is a sign, ag, osigna within the production process to trigger the production and suppy o product as part o just-in-timeand ean manuacturing. n a Kanban board Kanban cards are used to represent the items in the system. Fig-ure 20 shows a simpe Kanban board or a deveopment team which frst anayses each sice to understandits impact, then deveops and unit tests the sotware, and fnay independenty tests the resuting sotwarebeore putting it ive.

FIGUR 20: USCAS SlICS N A KANBAN BARD

The work in progress imits are shown in red. eading rom et to right you can see that sices have to be pre-pared beore they are input to the team. ere there is a work in progress imit o 5, and the customers, productowner or requirements team that are the source o the requirements try to keep 5 use-case sices ready or

deveopment at a times.

Sices are pued rom the input queue into anaysis. ere there is a work in progress imit o 3 items. Items inthe on-going coumn are currenty being worked on. The items in the done coumn have had their anaysiscompeted and are waiting to be picked up by a deveoper. In this way the sices work their way through thedeveopment team and ater successuy passing the independent testing go ive. There is no work in prog-ress imit on the output or the number o items that can go ive.

An important thing to note about Kanban is that there is no defnitive Kanban board or set o work in prog-ress imits; the structure o the board is dependent on your team structure and working practices. You shoudtune the board and the work in progress imits as you tune your practices. The states or the use-case sices

are a great aid to this kind o work design. Figure 21 shows the aignment between the states and the Kanbanboard shown in Figure 20. The states are very poweru as they ceary defne what state the sice shoud be inwhen it is to be handed on to the next part o the chain.

ON-GOING DONE ON-GOING DONE ON-GOING DONE

INPUT PREPARATION DEVELOPMENT SYSTEM LIVE

5 3 4 3

8/2/2019 IJI Use-Case2 0 2


FIGUR 21: AlIGNING TH STATS F TH USCAS SlIC T TH KANBAN BARD

Figure 22 shows where the dierent Use-Case 2.0 activities are appied. The interesting thing here is that In-spect and Adapt Use Cases is not the responsibiity o any particuar work station but is conducted as part othe reguar quaity contro done by the team. This activity wi hep the team to tune the number and type o

work stations they have as we as their work in progress imits.

FIGUR 22: USCAS 2.0 ACTIITIS FR WATRFAll APPRACHS

For exampe as a resut o reviewing the teams eectiveness you might decide to eiminate the preparationwork station and increase the work in progress imits or deveopment and system test. Again you expoit thestates o the use-case sice to defne what it means or each work station to have fnished their work resutingin the Kanban board shown in Figure 23.

INPUT PREPARATION DEVELOPMENT SYSTEM TEST LIVE

FIND ACTORS& USE CASES

SLICE THEUSE CASES

PREPARE AUSE-CASE SLICE

ANALYZE AUSE-CASE SLICE



TEST THE SYSTEM(AS A WHOLE)

INSPECT AND ADAPTTHE USE CASES

ACTIVITIES PERFORMED AT EACH WORKSTATION

PERFORMED REGULARLY AS PART OF THE QUALITY CONTROL


INPUT PREPARATION DEVELOPMENT SYSTEM TEST

5 3 4 3

SCOPED PREPARED ANALYZED IMPLEMENTED VERIFIED

LIVE

8/2/2019 IJI Use-Case2 0 2


FIGUR 23: TH TAMS RISD KANBAN BARD SHWING CMPlTIN STATS

Use-Case 2.0 and waterfaFor various reasons you may fnd that you need to deveop your sotware within the constraints o some

orm o watera governance mode. This typicay means that some attempt wi be made to capture a therequirements up-ront beore they are handed over to a third-party or deveopment.

When you adopt a watera approach the use cases are not continuay worked on and refned to aow thefna system to emerge but are a defned in one go at the start o the work. They then proceed in perect syn-chronization through the other deveopment phases, a o which ocus on one type o activity at a time. Thetypica sequence o activities or a watera approach is shown in Figure 24.

FIGUR 24: USCAS 2.0 ACTIITIS FR WATRFAll APPRACHS

REQUIREMENTSPHASE

ANALYSISPHASE

DESIGNPHASE

DEVELOPMENTPHASE

TESTPHASE

FIND ACTORSAND USE CASES

SLICE THEUSE CASES

PREPARE A USE-CASE SLICE

FIND, PREPARE & SLICE

ALL THE USE CASES

INSPECT & ADAPT THE USE CASES PREPARE A USE-CASE SLICE

CONTROL CHANGE

TEST THE SYSTEM(FOR A SLICE)

ANALYZE A USE-CASE SLICE

ANALYZE A USE-CASE SLICE

SHAPE THESYSTEM

SHAPE THESYSTEM

TEST THE SYSTEM(AS A WHOLE)

IMPLEMENTSOFTWARE

(FOR A SLICE)

TESTEVERYTHINGIMPLEMENTALL THE SLICESDESIGN THEENTIRE SYSTEMANALYZE ALLTHE USE CASES


INPUT DEVELOPMENT SYSTEM TEST

5 7 5

SCOPED PREPARED ANALYZED IMPLEMENTED VERIFIED

LIVE

8/2/2019 IJI Use-Case2 0 2


Even within the strictest watera environment there are sti changes happening during the deveopment othe sotware itse. ather than embrace and encourage change, watera projects try to contro change. Theywi occasionay Inspect and Adapt the Use Cases when there is a change request that cannot be deerredand they wi prepare additiona use-case sices to hande any changes that are accepted. They are unikeyto fnd any urther use cases ater the requirements phase as this woud be considered too arge a change inscope.

The one thing at a time nature o the watera approach means that the make-up o the team is continuaychanging over time, and so the abiity to use to ace-to-ace communication to share the stories is very imited

To cope with this you need to turn up the eve o detai on the work products, going way beyond the bare

essentias. Figure 25 shows the eve o detai typicay used on watera projects.

FIGUR 25: llS F DTAIl FR TH WRK PRDUCTS USING A WATRFAll APPRACH

Within each o the deveopment phases one or more o the work products are progressed to a very high-eve

o detai to ensure that they are 1) compete and 2) answer any and a questions that might arise during theater phases. In the requirements phase the use-case mode is worked and re-worked to make sure that athe use cases have been discovered, a o the use-case narratives are uy described and the supporting in-ormation is comprehensivey defned. At this stage some thought wi be put into testing and the test ideasormuated. The test cases are then put to one side unti the test phase is reached.

The use cases and their supporting inormation are handed over to the anaysis and design team who wiesh out the use-case reaizations frst to assign responsibiities to the system eements and then to defnea the interactions. Eventuay coding wi start and a the use cases and use-case sices wi be impementedFinay the testers wi get invoved and a the test cases wi be defned in detai and testing wi commence.

The sequentia nature o this way-o-working may ead you to think that there is no roe or use-case sices topay, and that just handing the entire use cases woud be enough. This is not true as the fner grained con-tro provided by the use-case sices aows the requirements team to be much more specifc about the actuascope o the system to be buit. Even in watera projects it is unikey that you wi need a o the stories roma o the use cases. They wi aso hep you to hande any ast minute changes in scope caused by schedue orquaity probems.

USE-CASE MODEL USE-CASE NARRATIVE USE--CASE REALIZATION TEST CASE SUPPORTING

INFORMATION

SKETCH:

BARE ESSENTIALS:

ENHANCED:

EXPANDED:

FURTHER EXPANDED:

BRIEFLY DESCRIBED

BULLETED OUTLINE

ESSENTIAL OUTLINE

FULLY DESCRIBED

TEST IDEASFORMULATED

SCENARIO CHOSEN

VARIABLES IDENTIFIED

VARIABLES SET

SCRIPTED/AUTOMATED

OUTLINED

SIMPLY DEFINED

MODELLED& ILLUSTRATED

COMPREHENSIBLYDEFINED

VALUE ESTABLISHED

SYSTEM BOUNDARY

ESTABLISHED

STRUCTURED

IMPLEMENTATION

ELEMENTS IDENTIFIED

RESPONSIBILITIES

ALLOCATED

INTERACTION DEFINED

8/2/2019 IJI Use-Case2 0 2


Use-Case 2.0 Its not just for one type of teamAnother important aspect o Use-Case 2.0 is its abiity to adapt to existing team structures and job unctionswhist encouraging teams to eiminate waste and increase eciency. To this end Use-Case 2.0 does not pre-defne any particuar roes or team structures, but it does defne a set o states or each o the centra eements(the use case and the use-case sice).

As iustrated by the discussion on Use-Case 2.0 and one-piece ow, the states indicate when the items are atrest and coud be handed-over rom one person or team to another. This aows the practice to be used withteams o a shapes and sizes rom sma cross-unctiona teams with itte or no handovers to arge networkso speciaist teams where each state change is the responsibiity o a dierent speciaist. Tracking the statesand handovers o these eements aows the ow o work through the team (or teams) to be monitored, and

teams to adapt their way-o-work to continuousy improve their perormance.

Use-Case 2.0: Scaing to meet your needs scaing in,scaing out and scaing up

o one, predefned approach fts everyone so we need to be abe to scae our use o Use-Case 2.0 in a numbeo di

iji use-case2 0 2

Documents