4 Use Cases - Explanation

8/12/2019 4 Use Cases - Explanation

http://slidepdf.com/reader/full/4-use-cases-explanation 1/19

PROJECT R AVEN

CONFIDENTIAL

Use Cases – In Project Raven

Version 1.1

Author : Raven Business Analysts

Use Cases – In Project Raven 1 06/06/2014



PROJECT R AVEN

CONFIDENTIAL

Table of Contents1.1 What is a Use Case?...................................................................................................................21.2 What is a Use Case for?..............................................................................................................3

1.3 What is a Use Case N! for?.....................................................................................................3

1.4 "isa#vanta$es of not havin$ Use Cases.....................................................................................3

.!tructure of a Use Case...................................................................................................".#ther Use Case Attributes in $A:..................................................................................1%&.I'(ortant notes on $)itin* Use Cases in $A:.............................................................1%+.Creatin* a Rich Te,t re(ort in $A.................................................................................1-

1. Pur(oseThe purpose of this document is-

• To describe / define the structure of the use case and outline the best practices that

could be adopted while writing Use Cases for Project Raven.

• To consolidate best practices, recommendations from a few general reference materials

and also from specific eperiential learning from projects within !d.com.

• To touch upon creating and maintaining Use Cases using "nterprise !rchitect, the

integrated tool to be used for Use Cases and related artifacts in Project Raven.

• To help in achieving a reasonable level of standardi#ation amongst Use Cases that is

written in Project Raven.

2. Use Case – At a lance

1.1 What is a Use Case?

• ! use case is the specification of a set of actions performed b$ a s$stem which $ields

an observable result that is of business value.




PROJECT R AVEN

CONFIDENTIAL

• Use cases are tet descriptions of the interaction that ta%es place between a computer

s$stem and one or more actors that are outside of the s$stem

• ! use case is a collection of possible se&uences of interactions between eternal actors

'users, user roles and other s$stems( and the s$stem under consideration, related to aparticular goal

• ! Use Case captures who 'actor( does what 'interaction( with the s$stem, for what

purpose 'goal(, without dealing with s$stem internals.

1.2 What is a Use Case for?

• To map )ta%e *older needs to )$stem Re&uirements.

• To communicate )$stem Re&uirements to downstream teams in the )+C.

• To validate or verif$ Re&uirements.

• To be used as an aid in planning projects

1.3 What is a Use Case NOT for?

• t is not meant to be the onl$ basis for coding 'development( Use Case and other

requirements documents should lead to or input to other analysis documentsdownstream in the SDLC process.

• t is not the onl$ source of the entire business re&uirements. - Use Case is just one

artifact in a myriad of other useful documents that can be used in conjunction tocompletely define the requirements. E.g. Business ules! Data "low diagrams etc.

• t is not an anal$sis artifact - #t should not attempt to critically analy$e or decipher

processes but just record the interactions.

• t is not to eplain the CRU+ operations 'Create, Read, Update, and +elete( on

database objects 'i.e.( of an T application Use Cases should not be identified alongCUD lines but more on the functional lines.

• t s not used to suggest / capture mplementation +etails 'including U information(

The design document and analysis document are a%ailable specifically for that purpose.

• t is not a tool to capture 0on-1unctional Re&uirements &hey are certainly important

but could be captured outside of the Use Case in a different document ' format.

1.4 Disadvantages of not having Use Cases

• )e&uence of interactions between the actors and the s$stem are often missed when

arbitrar$ re&uirement statements are written.

• Traceabilit$ and continuit$ will be impacted as Use Cases are bridges between the

2usiness team and the T team.

. !tructure of a Use Case




PROJECT R AVEN

CONFIDENTIAL

The components / elements of the Use Case are to capture a particular aspect of the same.These elements should have their own uni&ue value without introducing redundanc$. Thefollowing sub-sections describe how a Use Case should be created in the projects that fallunder Project Raven. There are multiple descriptions and approaches outlined in variousUse Case literatures across the industr$ and projects. The description and approach thatare eplained below are based on those standard materials and also considering valuable

inputs from an eperiential stand point with respect to some of the earlier projects underProject Raven.

The sub-sections that follow are organi#ed in the following manner3

• The$ touch upon ever$ element of the Use Case and the epected content.

• The Use Case components are also illustrated with screen shots from "nterprise

!rchitect '"!( as their contents will be managed using that as a tool in Project Raven.

• The sections also eplain how a Use Case is epected to be standardi#ed with the help

of an eample.

• The eample that is used is that of a Use Case for 4$nterin* the )etails of a

Custo'er into the syste'5.




PROJECT R AVEN

CONFIDENTIAL

3.1 Use Case Name :

+escription ! name that uni&uel$ identifies a use case and is also self eplanator$ ofthe observable result produced b$ the eecution of the Use Case.

+o5s • t could be an identifier that represents the functionalit$ provided b$

the Use Cases. The identifier could be in simple "nglish or acombination of "nglish words and numbers.

• The "nglish name preferabl$ should be in the 6erb-0oun form.

".g. )earch Customer.

• t should be understood b$ all sta%e holders 2usiness 7wners,

!nal$sts, +evelopers, and Testers etc.

• !ll 0ouns, 6erbs, !djectives and !dverbs should be capitali#ed, and

articles and preposition should not be capitali#ed.

• n "!, auto-numbering is alread$ set up for Use Cases

8. f a use case is discarded upon creation, reset the counter in"!.

9. f a use case is discarded later, put it in a :deprecatedre&uirements; 'or something similar( folder.

• f there is more than one actor, differentiate the same b$ ma%ing use

of the term :The User; or the actor5s name.

+on5ts • )hould not be made of a series of numbers.

• )hould not have a length$ verbiage.

!ddCustomer"ample

"nter Customer +etails,

UC<89= "nter Customer

Customer !ddition

UC<9=>

n "!




PROJECT R AVEN

CONFIDENTIAL

3.3 Use Case !tor":

+escription )ummari#es the interaction that happens in the use case in a ver$concise manner and serves as a &uic% reference to the functionalit$represented in the Use Case.

+o5s •

+escribe the essence of the use case outlining the main se&uence'the success condition of the 2asic Course( of events that are relevantto the functionalit$ of the use case.

+ont5s • +o not be vague or have generic one statement descriptions.

• +o not tr$ to stretch the description be$ond a limit.

* lengthy Use Case Story loose its critical %alue and reduces theimportance of the Basic Course of the Use Case

!ddCustomer"ample

This use case helps the actor

enter the details of the newcustomer to the s$stem. tvalidates for duplicates, adds

the customer and sendsnotification to appropriateparties concerned about suchan addition.

This use case creates new

customers to the s$stem

n "!




PROJECT R AVEN

CONFIDENTIAL

3.% #re$Condition:

+escription )ummari#es the conditions that must be satisfied before the interactionstated in the Use Case occurs. t is the contract between the Use Caseand the outside world.

+o5s •

ist the business conditions that should be true, and are outside theboundar$ of the Use Case.

+ont5s • +o not refer to ver$ granular level of details but rolled up business

conditions.

!ddCustomer"ample

The ?ar%eting +epartment hasgiven clearance for the additionof the Customer.

The !ccount ?anager has

confirmed the addition of theCustomer

The ?ar%eting department hasupdated the )tatus to green

The "mail confirmation from the

!ccount ?anager has beenreceived

n "!




PROJECT R AVEN

CONFIDENTIAL

3.6 #ost Condition:

+escription i%e the Pre-Condition, the Post-Condition is also a contract between theUse Case and the outside world. t enlists the conditions that will besatisfied after the eecution of the Use Case is complete.

+o5s •

)ummari#e the conditions that will be true of the Use Case iscomplete.

• )hould be independent of the !lternate Courses ta%en in the Use

Case.

• Tr$ to list the Post Condition with the Use Case level in mind and not

per the individual courses li%e !lternate or "ception.

+ont5s • +o not repeat steps from the 2asic Course from the Use Case

• +o not mention multiple post conditions.

• +o not refer to the s$stem5s state as a Post Condition.

!ddCustomer"ample

The Customer has been addedto the s$stem and sent for

Credit !pproval.

The Customer has been addedto the )iebel database.

n "!




PROJECT R AVEN

CONFIDENTIAL

3.& A%tors:

+escription !n agent / entit$ that eists outside of the boundar$ of the s$stem'though under the auspices of the Use Case(, and interacts with the

s$stem to achieve the business goal that is represented b$ the UseCase.+o5s • 0ame !ctors intuitivel$ and unambiguousl$.

• !ctor names should be representing their role and not titles.

• Tr$ to generali#e the !ctors 'i.e.( sometimes there ma$ be two roles in

an 7rgani#ation that are named differentl$ but ma$ be perform thesame eact functions.

+ont5s • +o not identif$ !ctors as individuals / specific persons.

!ddCustomer"ample

!ccounts +epartment Cler%

Credit !nal$st

avin ?c?illan

)enior ?anager

n "! u) $nter Custo'er /etails

UC001 $nter

Custo'er /etails

ccounts A)'inistrator




PROJECT R AVEN

CONFIDENTIAL

3.' #rimar" !%enario&'asi% Course(:

+escription The core section of the Use Case. "nlists the se&uence of events thes$stem and actor's( go through, most of the times, to accomplish the goalof the Use Case.

+o5s •

t should eplain the interaction in a re&uest 'b$ the !ctor( response'b$ the )$stem( format.

• t could be the most common 'fre&uent( path.

• t could be the simplest path 'if the fre&uenc$ is not determinable(.

• t should reflect the dail$ wor% for the users regardless of the number

of steps involved.

• t could be the decisions the actors ma%e most fre&uentl$ in the

performance of the tas%s covered b$ the use case.

• t is the path that eercised the most functionalit$ provided under the

auspices of the use case.

• t should be numbered se&uentiall$ starting with a 8.

• Use a consistent verb tense )imple Present and in !ctive 6oice ".g.

:The batter hits the ball; not :The ball is hit b$ the batter;

• 2ranching is permitted if it covers just that one step and remerges to

the Primar$ )cenario after that. f there are an$ other steps in thecourse of the Use Case that are dependent on the decision ta%en inthe branching step, that would &ualif$ for an !lternate )cenario

• Bithin an alternative scenario, at most, one additional level of depth of

alternative scenarios will be allowed 'label it the same wa$ all otheralternative scenarios are labeled(. f more la$ers of alternates areneeded, move the alternative scenario to be its own Use Case.

+on5ts • t should not tell 4ho23 the Use Case happens, but 42hat3 happens in

the Use Case.

• ! step in the Use Case should not combine multiple actions, but onediscrete action.

• t should not contain formula, rule set, pictorial eplanations etc.

• t should not contain looping and branches.

• t should not contain an$ pseudo code or programming bloc%

statements li%e 1-")" or 2"0-"0+ etc.

• )hould not have inconsistent verb tense li%e should shall, ma$ etc.

!ddCustomer"ample

8. The actor enters the

Customer5s identificationdetails including the

address and Ta +.9. The s$stem searches for

duplicates with the sameidentification informationand indicates that thecustomer does not eistalread$.

=. The s$stem also as%s forconfirmation to add the

8. The actor enters the

Customer information in the4!dd Customer5 web page.

9. The s$stem scans the7racle database forduplicates and indicates thatthe Customer does noteist.

=. ! dialog bo appears as%ingfor confirmation to add theCustomer.

>. The !ctor clic%s 47A5.




PROJECT R AVEN

CONFIDENTIAL

Customer.>. The actor indicates the

confirmation to add theCustomer.

. The s$stem records theCustomer information and

displa$s a successmessage that the Customeris added.

D. The s$stem also notifies theCredit !pproval departmentabout the new addition.

E. The !ctor logs out of thes$stem.

. The s$stem adds theCustomer to the databaseand sends an email to theCredit !pproval departmentconfirming the addition.

n "!

F




PROJECT R AVEN

CONFIDENTIAL

3.( A)ternate !%enario &A)ternate #ath* A)ternate Course(:

+escription The$ are the less common variants of the 2asic Course also representingunusual processing that ta%es place in the Use Case, but satisfies theeecution of the Use Case.

+o5s • "ach !lternate Course should be mentioned where it eits from

the 2asic Course and joins bac%.

• t is recommended that all !lternate Course joins the 2asic Course

if applicable.

• !lternate scenario invocations and returns should be handled

outside of numbered steps.

• Bhen other use cases are invo%ed within a use case, the

invocation should be handled within its own step in the invo%ingscenario.

• f the point of return is not immediatel$ following the point of

departure 'generall$ it should be(, the point of return should be

handled the same wa$ returns are handled for alternate scenarios.• 0umbered se&uentiall$ starting a 8 and prefied with !) e.g. !)8,

!)9 etc.

• Points of departure for alternate paths are identified b$ :GG

HConditionI Hverb clauseI in the H!lternate )cenario 0ameIalternate scenario.;

• Points of re-entr$ for alternate paths are identified b$ :JJ Return

from the H!lternate )cenario 0ameI alternate scenario.;

• !lternate scenarios should result in achieving the purpose of the

use case at some level of abstraction

+on5ts • The error / eception scenarios should not be listed here

!ddCustomer"ample +n the 'asi% Course,

8. The actor enters the Customer5s identification details including theaddress and Ta +.

9. The s$stem searches for duplicates with the same identificationinformation and indicates that the customer does not eist alread$.

'Customer with same name eists(

GG !lternate )cenario3 Customer Bith )ame 0ame "ists

=. The s$stem also as%s for confirmation to add the Customer.>. The actor indicates the confirmation to add the Customer.. The s$stem records the Customer information and displa$s a

success message that the Customer is added.D. The s$stem also notifies the Credit !pproval department about the

new addition.

JJReturn from the !lternate )cenario3 Customer Bith )ame 0ame




PROJECT R AVEN

CONFIDENTIAL

"ists

E. !ctor logs out of the s$stem.

+n the A)ternate !%enario,

Customer Bith )ame 0ame "ists

8. f the same customer eists in the s$stem, !ctor does not ta%e an$action.

9. f the Customer is a new entit$ with a similar name but withdifferent address, the !ctor attaches a valid and identifiable prefito the Customer name and enters the same to the s$stem.

n "!




PROJECT R AVEN

CONFIDENTIAL

3.10-%e/tion !%enario &-%e/tion Course* -%e/tion #ath(:

+escription t is similar to an !lternative Course in that the$ represent uncommonprocessing but the$ are different from them in that the$ represent onl$ these&uence of events that happen following an "rror condition.

+o5s •

"ach !lternate Course should be mentioned where it eits fromthe 2asic Course and joins bac%.

• t is recommended that all !lternate Course joins the 2asic Course

if applicable.

• 0umber se&uentiall$ starting at 8.

• The "ception scenario should end the Use Case.

+on5ts • The alternate scenario should not be listed here.

• The "ception scenario should not join the 2asic Course again.

• +o not refer to technical eceptions in the s$stem.

!ddCustomer"ample

The address of the new

Customer is invalid and is

not recogni#ed b$ thes$stem.

The Use Case stops at this

point displa$ing the errormessage.

The s$stem times out during the

search.

The s$stem displa$s a Page0ot 1ound error.

n "!




PROJECT R AVEN

CONFIDENTIAL

3.110reuen%":

+escription +escribe how often this use case 4occurs5.

+o5s • 1re&uenc$ could be mentioned in the measures / units as listed

below.o transactions/hour

o times/da$

o times/Bee%

o times/month

o K of customers

+ont5s • +o not refer to s$stem statistics as fre&uenc$ of the Use Case this

refers to be business functionalit$ !ddCustomer"ample

8< times a wee% 8< batch processes a wee%

n "!

The 0otes field can be utili#ed for this purpose




PROJECT R AVEN

CONFIDENTIAL

". #ther Use Case Attributes in $A:

Attribute /escri(tion !u**este) Value)cope +enotes the visibilit$ of theUse Case

Public

!lias Referred b$ an$ other validnames

+efault 6alue

Re&uirementT$pe)tatusProposed+ifficult$Priorit$

!n nternal Re&uirement that isassociated with the Use Case

+efault 6alue

in% 1acilit$ to lin% other artificeswith the Use Case

0/!

1ile 1acilit$ to lin% other artificesthat are relevant to the UseCase in the )+C

0/!

0otes The field capturesmiscellaneous and usefulinformation about the UseCase. The field is ver$important and can be ver$useful.

8. )hort +escription 30ot a repetition ofthe Use Case stor$but it should besupplementing theUse Case name if itis not possible to be

self eplanator$9. The 1re&uenc$ of

the Use Case shouldbe mentioned here.

=. 6er$ mportantl$, thenotes field shouldcapture the 2usiness)ta%e *olders forthe Use Case, until apermanent place forthis information isidentified in a

different place

&. I'(ortant notes on $)itin* Use Cases in $A:




PROJECT R AVEN

CONFIDENTIAL

• Recogni#e that, in the editing boes of "! there is no provision made for the rich formatting

?icrosoft Bord provides in the tet boes in "nterprise !rchitect, so don5t invest a lot oftime in formatting the contents of the Use Case in "!

• "! has features / facilities to create Rich Tet and *T? formatted versions of the Use

Case.

• Rich Tet versions created that wa$ could be shared with the team members for feed bac%

and comments

+. Creatin* a Rich Te,t re(ort in $A

8. o to the menu 3 Project -G +ocumentation -G Rich Tet 1ormat Report

9. The following screen will be presented.

=. The RT1 report will be created in the appropriate folder with the desired name

U C I P j t R 19 06/06/2014

Choose this te'(lateChoose a )esire) na'e Clic4 enerate

4 Use Cases - Explanation

Documents

Transcript of 4 Use Cases - Explanation