a

L04 Use Case Description

lecture for use case modeling writing

use case description at the end of this

session you should be able to list the

main components of a use case

description identify scenarios of the

use case described main floor and

alternate flows of the use case in the

previous session we have seen how we can

use a use case model to model the

system's functional requirements the

function requirements specify the user

goals however what goes on in each of

these use cases

can you tell from the use case model

obviously not hence for each use case it

must accompanied with a use case

description use cases have internal

complexity so what that is complexity

the sequence of steps to execute

business process to achieve the users

goal there might be several variations

that may exist within a use single use

case for example when you place the

order the step may vary resist is this

customer a registered member who is

entitled to privileges if that is the

case how would you handle this

particular situation each of this

scenario or each of this variation is

called a scenario we represent a

possible situation that may arise when

executing a use case it is ultimately

very important for you to identify all

possible scenarios because when you

implement the system the system must be

able to handle all these scenarios so

what does the Yusuke description include

each you see a description accompanied

with a detail Yusuke description the

information normally comes from the

information gathered during the

requirement so both of these combined

together ok we'll provide the usage

description so what goes on in the you

skate description each use case

description must have values

is name this use case name is a result

oriented name for the use case s appears

in your use case diagram you can include

a use case ID this use case ID is a

unique identifier and specify by the

organization so that function

requirements can be tracked then there

is a use case description this

description describe the reason for and

the outcome of this use case they might

include a high-level description of the

sequence of actions you can also specify

the outcome of executing the use cases

and you could include the input data

required the description any business

rules and constraints then you might

include the primary actor as described

in the previous session the primary

actor is someone who triggers or

initiate the use case problem call the

initiator you may also include the

secondary actor the actor that interact

with the use case after it is triggered

some time also called a participator

following the app will be your

preconditions so what are preconditions

preconditions are activities that must

have taken place or any conditions that

must be true before the use case can be

started after the preconditions comes

the post conditions the post conditions

list the state of the system at the

conclusion of the use case execution the

most important part of the use case

description is the main flow the main

flow will listen users actions and

system responses that will take place

during the execution of the use case

under normal expected conditions the

sequent actions and response will

ultimately lead to accomplishing the

goal stated in the news case name in the

description following the main flow are

the alternate flows the alternate flows

as previously stated other scenarios

this document other legitimate use usage

scenarios that can take place

within the use case each floor should

normally be preceded with a scenario

name in each of this alternate flow you

should also list the user's actions and

the system responses for this alternate

scenarios guidelines for writing use key

description you will know does not

provide any standard rules for writing

detail you escape descriptions when you

google on the internet you will find

many different of variations and ways

that people write use this description

but for the purpose of this module we

will provide certain guidelines which

you should follow so these guidelines

that you should a hill to are using

programmer example library enters the

book ID in stay off the ball ID is

entered by the librarian your system

displays the book detail rather than the

book detail at is filled by the system

each of these statements should clearly

show who is in control at any point in

time so always start with the actor

hence the actor must be replaced with

the actor's name in the use case the

actor name obviously can be found in

your use case diagram then the system

example the customer enters the quantity

to purchase the system s items into the

order list however do not impose

constraints on user interface because at

this point you might not have actually

have any idea what the user interface is

going to look like so do not write

things such as user clicks on OK button

to submit personal details instead you

should put user submits personal detail

to the system so here are some

guidelines for instance when you want to

indicate how user to inputs by entering

data by the keyboard this is what you

could normally do the actor enters the

actors submits then the system validates

followed by the system verifies

if you have actor inputting data by

selecting data from a list provided by

the system then this is how you would

normally phrase the use case description

sequence the system retrieves a list off

the system displays the list off the

actor then selects etc then the address

submits if selection is compulsory then

the system I validate the selection

after the validation then the system

might be able to do can continue other

actions some of the system responses in

response to the actor actions as follows

the system computes the system prints

this is some triggers or the system

creates insert update delete or display

by pulling the simplest guideline you

could write you schedule very simple

simply here is the example of a use case

description templates however you do not

have to draw draw the boundaries or

format in such a table what you can see

are the use case component on the

left-hand column the Nueske's ID the use

case name and sometimes you might even

want to include created by and the date

created this could track the use case as

written by who and when is the latest

version here's another example with some

detail of a use case this is a use case

call login here you can see a use case

ID ACC underscore UC underscore one as

stated previously this use case ID does

not have to follow any particular format

normally this is indicated by individual

organization so in this case it might be

an account underscore use case

description one as you can see in the

description you actually give you a

high-level description or what this use

case is supposed to do what the outcome

of this use case is as well as

what the data are required and there are

any business through for instance the

user only have a maximum three attempts

to log in after which the account

unlocked and you will have to contact

the sister demonstrator to unload a

account upon successful login to the

system then the system will display and

user homepage here are the details of

the main flow and the alternate flow

take note of the alternate flow where

each of the new flow have a scenario

name so how does this particular steps

number arise from for instance if let's

say we have now the system verifies the

stop ID

note that this is actually step 4 what

if the system fails to verify this stop

ID and the password what this means is

that if the system go and retrieve the

information from the database and the

stop ID does not match with the password

so in this particular case the alternate

flow would be step for a embedded staff

ID or password and following the

scenario name are the steps by which the

systems or the actor you have to do the

system will display invalid stop ID and

password and the system will prompt for

the stop ID and password what happens if

you have use cases which extends or

include another use case as shown in

this diagram here here we can see that

tick customer order is the base case

then we have a tick purse product

specific requirement which is the

extended use case

extending the base case the customer

order and the customer order use case

includes ok the retrieve customer

details use case so how do you write

this in a use case description following

our example to illustrate how you write

such situations this is the base case

which is the take customer order in this

particular case we might actually have a

new

heydo call include use cases and this

particular include use case column we

will have retrieved customers detail and

at this particular point in a vein flow

we can indicate the point at which the

use case is in is is needed

hence the way to write this is the

system triggers the receive customer

details use case here we also illustrate

how you can write repetition steps if

you have a series of step that need to

be repeated then all you have to do is

to indicate as follows repeat step

number one to number one for our

products we normally do not use repeat

until not for such-and-such construct

this is a extent based case description

so this is again the base case the

customer order okay and when in the

Yusuke description in the main flow we

have to indicate the point at which the

extended use case might be triggered and

this is how you indicated by using the

phrase extension point they product

specific requirements then when we are

writing the extended use case in this

case they'll take product our specific

requirement use case then in this case

we might actually put that this

particular use case the product specific

requirement which is Casey extends it

extends that the customer order use case

so if you include the extent and the

include use case header this is what a

complete Yusuke description might look

like

hence in this session we have seen what

our use case scenarios we also look at a

components of each use case description

the use case description describe the

flow of each use case an alternate flow

a path of the main flow that captures

errors branches and interruptions the

include and xn use cases are included in

the main flow description