1 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use cases

Version 1.0 02/05/2004© 2004 Robert Oshana

Requirements Engineering 1

Use cases



Use cases

• Formal definition; a use case describes a sequence of actions a system performs that yields a result of value to a particular actor– Describes the interactions between a user and a

system– Focus on what the system does for the user



Use case modeling steps

• Find the system boundary• Find the actors• Find the use cases

– Specify the use case– Create scenarios



Use case model components

• Actors; roles played by people or things that use the system

• Use cases; things that the actors do with the system

• Relationships; meaningful relationships between actors and use cases

• System boundary; a box drawn around the use cases to denote the edge or the boundary of the system being modeled



The system boundary

• What is part of the system and what is external to the system

• Positioning of boundary has big impact on functional and non-functional requirements

• Defined by who or what used the system• Drawn as a box



Actors

• Specifies a role that some external entity adopts when interacting with the system directly

• Represents a user role or a role played by another system

• Always external to the system– Outside our control



Finding actors

• Who or what uses the system?• Who installs the system?• Who starts and shuts down the system?• Who maintains the system?• Who gets and provides information to the

system?



Time as an actor

• For modeling things that happen to your system at a specific point in time but which don’t seem to be triggered by an actor– Automatic system backup that runs every

morning



Building the use case model

• Consists of all the actors of the system• All the use cases by which the actors

interact with the system• Describe totality of functional behavior of

the system (not really!)



Use cases

• Use cases are always started by an actor• Use cases are always written from the point

of view of an actor

PlaceOrderGetStatusOnOrder



Identifying use cases

• Consider how each actor is going to use the system

• Give the use case a short descriptive name that is a verb phrase

• May also discover new actors• Iterative process of stepwise refinement

– Start with a name, fill in details, refine to complete spec



Identifying use cases

• What functions will a specific actor want from the system?

• Are any actors notified when the system changes state?

• Are there any external events that affect the system? What notifies the system about those events?

• Does the system store and retrieve information? Which actors trigger this behavior?



Use case diagram

customer

PlaceOrder

CancelOrder

CheckOrderStatus

SendCatalog

SendCatalog

Shippingcompany

dispatcher

Mail order system

actor

Communicationrelationship

Use case

System name

Systemboundary



Detail a use case

• Each use case has a name and a specification– Preconditions; these are things that must be

true before the use case execute – they are constraints on the state of the system

– Flow of events; the steps in the use case– Postconditions; things that must be true at the

end of the use case



Pre and post conditions

• Preconditions; constrain the state of the system before the use case can start. Think of them as gatekeepers that prevent the actor from triggering the use case until all their conditions are met

• Postconditions; constrain the state of the system after the use case has executed



Use case: PayVAT

ID: UC1

Actors:TimeGovernment Preconditions:1. I t is the end of a business quarter

Flow of events:1. The use case starts when it is the

end of the business quarter2. The system determines the amount

of VAT owed to the government3. The system sends an electronic

payment to the government

Postconditions:1. The government receives the correctAmount of VAT

Use case: PayVAT

ID: UC1

Actors:TimeGovernment Preconditions:1. I t is the end of a business quarter

Flow of events:1. The use case starts when it is the

end of the business quarter2. The system determines the amount

of VAT owed to the government3. The system sends an electronic

payment to the government

Postconditions:1. The government receives the correctAmount of VAT

Use case for PayVAT



Flow of events

• The use case starts when an <actor> <function>

• <number> the <something><some action>• Can also use prose but this can be too

imprecise• Simple declarative statement of some thing

performing some action



Ill formed use case

• “Customer details are entered”• Three important deletions

– Who is it that enters the customer details? Who triggers the use case?

– Into what are the details entered?– What



When encountering vagueness

• Who specifically…..?• What specifically…..?• When specifically…..?• Where specifically…..?



Branching within a flow

• Alternative flows must be represented• Can be argued that a branch indicates a

new use case• But also leads to more use cases• Keyword If



Use case: ManageBasket

ID: UC10Actors:customer

Preconditions:1. The shopping basket contents are visible

Flow of events:1. The use case starts when the customer

selects an item in the basket2. I f the customer selects delete item

2.1 The system removes the item fromthe basket

3. I f the customer types in a new quantity 3.1 The system updates the quantity

of the item in the basket

Postconditions:1. The basket contents have been

updated

Use case: ManageBasket


Preconditions:1. The shopping basket contents are visible


selects an item in the basket2. I f the customer selects delete item

2.1 The system removes the item fromthe basket

3. I f the customer types in a new quantity 3.1 The system updates the quantity

of the item in the basket

Postconditions:1. The basket contents have been

updated

Use case for ManageBasket



Alternative flows

• Sometimes its hard to express branching– Things that can happen at any point in time– Where in the main flow would the If go?

• Express as one or more alternative flows



Alternative flows

• 1. Specify the preconditions for the use case – these must be true for all possible paths through the use case

• 2. Specify the normal flow of events• 3. Specify the postconditions of the normal

flow of events• Append a new section to the end of the use

case for each alternative flow



Alternative flows

• 1. Specify the flow of events for the alternative flow– Must always begin with a boolean condition

• Specify postconditions for the flow of events



Use case: DisplayBasket


Preconditions:1. The customer is logged on to the system


selects “Display basket”2. I f there are no items in the basket

2.1 The system informs the customer that there are no items in the basket yet

2.2 The use case terminates3. The system displays a list of all items

in the Customers shopping basket including product ID, name, quantity, anditem price

Use case: DisplayBasket




selects “Display basket”2. I f there are no items in the basket

2.1 The system informs the customer that there are no items in the basket yet

2.2 The use case terminates3. The system displays a list of all items

in the Customers shopping basket including product ID, name, quantity, anditem price

Use case for DisplayBasket



Postconditions:

Alternative flow 1:1. At any time the customer may leavethe shopping basket screen

Postconditions:

Alternative flow 2:1. At any time the customer may leavethe system

Postconditions:



Repetition within a flow: For

• May have to repeat an action several times within a flow of events

• Iterates a positive whole number of iterations

n. For (iteration expression) n.1 Do something n.2 Do something else n.3 ….n+1



Use case: FindProduct



Flow of events:1. The customer selects “find product”2. The system asks the customer for search criteria3. The customer enters the required criteria4. The system searches for products that match the

customer’s criteria5. I f the system finds matching products then

5.1 For each product found5.1.1 The system displays a thumbnail sketch of

the product5.1.2 The system displays a summary of the

product details5.1.3 The system displays the product price

6. Else6.1 The system tells the customer that no matching products

could be found

Use case: FindProduct



Flow of events:1. The customer selects “find product”2. The system asks the customer for search criteria3. The customer enters the required criteria4. The system searches for products that match the

customer’s criteria5. I f the system finds matching products then

5.1 For each product found5.1.1 The system displays a thumbnail sketch of

the product5.1.2 The system displays a summary of the

product details5.1.3 The system displays the product price

6. Else6.1 The system tells the customer that no matching products

could be found

Use case for FindProduct



Postconditions:

Alternative flow 1:1. At any time the customer may moveto a different page

Postconditions:



Repetition within a flow: While

• Use the keyword While to model a sequence of actions in the flow of events that is performed while some boolean condition is true

n. While (Boolean condition) n.1 Do something n.2 Do something else n.3 ….n+1



Use case: ShowCompnyDetails



Flow of events:1. The use case starts when the customer selects“show company details”2. The system displays a web page showing the companydetails

2. While the customer is browsing the company details3.1 The system plays some background music3.2 The system displays special off ers in a banner ad

Postconditions:

Use case: ShowCompnyDetails



Flow of events:1. The use case starts when the customer selects“show company details”2. The system displays a web page showing the companydetails

2. While the customer is browsing the company details3.1 The system plays some background music3.2 The system displays special off ers in a banner ad

Postconditions:

Use case for ShowCompnyDetails



Requirements tracing

• Important to understand if anything in SRS is not in a use case

• Many to many relationship between individual functional requirements in the SRS and use cases

• CASE tools help• Manually create a requirements traceability

matrix



Traceability matrix

Use case

UC1 UC2 UC3

R1 X

R2 X X

R3 X

R4 X

R5 X



Complex use cases

• Use cases should be as simple as possible• May encounter irreducible complexity that

will lead to complex use cases• In this cases model the main flows through

through this branching network as separate scenarios



Scenarios

• A scenario is one specific path through a use case

• Scenarios do not branch– Each possible branch in a use case is a possible

scenario

• Each use case has one and only one primary scenario– “perfect world” path through complex flow



Scenarios

• Each use case has many secondary scenarios– Alternative paths through the flow of events– Exception scenarios (capture errors)



Use case: CheckOut



Flow of events:1. The use case starts when the customer selects“go to checkout”2. The system displays the customer order3. The system asks for customer identifier4. The customer enters a valid customer identifier5. The system retrieves and displays the Customer’s details6. The system asks for credit card information (name,

expiry date, number)7. The customer enters credit card information8. The system asks for confirmation of the order9. The customer confirms the order10. The system debits the credit card11. The system displays an invoice

Use case: CheckOut



Flow of events:1. The use case starts when the customer selects“go to checkout”2. The system displays the customer order3. The system asks for customer identifier4. The customer enters a valid customer identifier5. The system retrieves and displays the Customer’s details6. The system asks for credit card information (name,

expiry date, number)7. The customer enters credit card information8. The system asks for confirmation of the order9. The customer confirms the order10. The system debits the credit card11. The system displays an invoice

Use case for CheckOut



Secondary scenarios:InvalidCustomerIdentifierInvalidCreditCardDetailsCreditCardLimitExceededCreditCardExpired

Postconditions:



Specifying secondary scenarios

• Specify in the same way as a primary use case

• Secondary scenarios should be traceable back to its use case

• Can also reference the primary scenario



Use case: CheckOutSecondary scenario: I nvalidCustomerIdentifier

ID: UC14

Actors:customer

Preconditions:

Secondary scenario:1. The use begins in step 3 of the use case Checkout when the

customer enters an invalid customer identifier2. For three invalid entries

2.1 The system asks the customer to enter the customer identifier again

3. The system informs the customer that their customeridentifier was not recognized

Postconditions:

Use case: CheckOutSecondary scenario: I nvalidCustomerIdentifier

ID: UC14

Actors:customer

Preconditions:

Secondary scenario:1. The use begins in step 3 of the use case Checkout when the

customer enters an invalid customer identifier2. For three invalid entries

2.1 The system asks the customer to enter the customer identifier again

3. The system informs the customer that their customeridentifier was not recognized

Postconditions:

Secondary use case



Finding secondary use cases

• Identified by inspection to the primary use cases

• For each step in the primary use case look for;– Possible alternative paths– Errors that might be raised– Interrupts that might occur to the flow – things

that might happen at any time



How many scenarios?

• Should limit the number of secondary use cases to the necessary minimum– Pick the most important ones and document

those– Where there are groups of secondary scenarios

that are similar, document one as an exemplar and add notes explaining how the others differ



How many scenarios?

• Basic principle in use case modeling is to keep the amount of information captured to a necessary minimum

• Used to understand the desired behavior of the system– Because of the iterative process, can always go

back and add more



Top 10 Mistakes to Avoid When Writing Use Cases

10. Write functional requirements instead of usage scenario text. 9. Describe attributes and methods rather than usage. 8. Write use cases too tersely. 7. Divorce yourself completely from the user interface. 6. Avoid explicit names for your boundary objects. 5. Write using a perspective other than the user’s, in a passive

voice. 4. Describe only user interactions; ignore system responses. 3. Omit text for alternative courses of action. 2. Focus on something other than what’s “inside” a user case,

such as how you get there or what happens afterwards. 1. Spends a month deciding whether to use include or extends.

[Rosenburg p. 60]



Summary

• Use case modeling is part of the requirements flow

• Find the system boundary, find the actors, find use cases

• Time is often an actor• Find use cases by considering how each

actor interacts with the system

Documents

1 Version 1.0 02/05/2004 © 2004 Robert Oshana Requirements Engineering Use cases