Requirements Analysis and Design Engineering Southern Methodist University CSE 7313

Module 9 - 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 PlaceOrder GetStatus OnOrder

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 CheckOrder Status Send Catalog Send Catalog Shipping company dispatcher Mail order system actor Communication relationship Use case System name System boundary

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: Time Government Preconditions: 1. It is the end of a business quarter Flow of events: 1. The use case starts when it is the end of the business quarter 2. The system determines the amount of VAT owed to the government 3. The system sends an electronic payment to the government Postconditions: 1.The government receives the correct Amount of VAT { Use case name { Unique identifier Actors involved in the use case {

Flow of events  The use case starts when an  the  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: UC10 Actors: 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 basket 2. If the customer selects delete item 2.1 The system removes the item from the basket 3. If 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

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 ID: UC11 Actors: customer Preconditions: 1. The customer is logged on to the system Flow of events: 1.The use case starts when the customer selects “Display basket” 2. If 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 terminates 3. The system displays a list of all items in the Customers shopping basket including product ID, name, quantity, and item price

Postconditions: Alternative flow 1: 1.At any time the customer may leave the shopping basket screen Postconditions: Alternative flow 2: 1.At any time the customer may leave the 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 ID: UC12 Actors: customer Preconditions: 1. The customer is logged on to the system Flow of events: 1. The customer selects “find product” 2. The system asks the customer for search criteria 3. The customer enters the required criteria 4. The system searches for products that match the customer’s criteria 5. If the system finds matching products then 5.1 For each product found The system displays a thumbnail sketch of the product The system displays a summary of the product details The system displays the product price 6. Else 6.1 The system tells the customer that no matching products could be found

Postconditions: Alternative flow 1: 1.At any time the customer may move to 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 ID: UC13 Actors: customer Preconditions: 1. The customer is logged on to the system Flow of events: 1.The use case starts when the customer selects “show company details” 2.The system displays a web page showing the company details 2.While the customer is browsing the company details 3.1 The system plays some background music 3.2 The system displays special offers in a banner ad Postconditions:

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 UC1UC2UC3 R1X R2XX R3X R4X R5X

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 ID: UC14 Actors: customer Preconditions: 1. The customer is logged on to the system Flow of events: 1.The use case starts when the customer selects “go to checkout” 2.The system displays the customer order 3.The system asks for customer identifier 4. The customer enters a valid customer identifier 5.The system retrieves and displays the Customer’s details 6.The system asks for credit card information (name, expiry date, number) 7.The customer enters credit card information 8.The system asks for confirmation of the order 9.The customer confirms the order 10.The system debits the credit card 11.The system displays an invoice

Secondary scenarios: InvalidCustomerIdentifier InvalidCreditCardDetails CreditCardLimitExceeded CreditCardExpired 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: CheckOut Secondary scenario: InvalidCustomerIdentifier 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 identifier 2.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 customer identifier was not recognized Postconditions:

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

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