Use Cases

Use Case Modeling Chapter 7 of the Text Book and Applying Use Cases: A Practical Guide Geri Schneider and Jason P. Winters

User Centred Design • Software development should focus on the needs of users – Understand your users – Design software based on an understanding of the users’ tasks – Ensure users are involved in decision making processes – Design the user interface following guidelines for good usability – Have users work with and give their feedback about prototypes, on-line help and draft user manuals

The importance of focusing on users – – – –

Reduced training and support costs Reduced time to learn the system Greater efficiency of use Reduced costs by only developing features that are needed – Reduced costs associated with changing the system later – Better prioritizing of work for iterative development – Greater attractiveness of the system, so users will be more willing to buy and use it

Characteristics of Users • Software engineers must develop an understanding of the users – Goals for using the system – Potential patterns of use – Demographics – Knowledge of the domain and of computers – Physical ability – Psychological traits and emotional feelings

Use Cases • Used to describe the outwardly visible requirements

Order Processing Problem Statement •

Problem Description – We are developing order processing software for a mail order company called National Widgets, which is a reseller of products purchased from various suppliers. – Twice a year the company publishes a catalog of products, which is mailed to customers and other interested people. – Customers purchase products by submitting a list of products with payment to National Widgets. National Widgets fills the order and ships the products to the customer’s address. – The order processing software will track the order from the time its is received until the product is shipped. – National Widgets will provide quick service . They should be able to ship a customer’s order by the fastest, most efficient means possible. – Customers may return items but will sometimes pay a fee.

•

Assumptions – An electronic interface, such as web, would be good for some customers.

Identifying System Boundaries • Finding out what things are inside – you have to worry about creating them, and what things are outside – you don’t have to create them but have to worry about interfacing with them.

What is the boundary of this system? National widgets will need to ship orders to customers. Shipping needs to include packaging and labeling orders, weighing them, and determining postage based on shipping method, speed of delivery, insurance, weight, destination, and so on. Should our system include the printing of mailing labels and calculating postage?

Identify actors and the use cases to determine the system boundary

Actors • Actors are anything that interface with our system. – people, other software systems, hardware devices, etc.

• Each actor defines a particular role. • Actors are outside the system. • Each entity outside our system may be represented by one or more actors.

Identifying Actors • Ask the following questions: – – – – – – – – –

who uses the system? who installs the system? who starts up the system? who maintains the system? who shuts down the system? what other systems use the system? who gets information from this system? who provides information to this system? does anything happen automatically at a preset time?

Sample Actors • Customer – a person who orders products from National Widgets • Customer Rep – an employee of National Widgets who processes customer requests • Shipping company – such as DHL, FedEX • Clerk – an employee of NW who packages, labels, and ships orders • Inventory system – software that tracks the company inventory • Accounting system – software that keeps the company books

Use Cases • Things actors want the system to do. • Represent system functions • A use case is almost always started by an actor. • It represents the interaction between the actor and the system. – User’s action and the system’s reaction

Developing Use-Case Models of Systems • A use case is a typical sequence of actions that a user performs in order to complete a given task – The objective of use case analysis is to model the system … from the point of view of how users interact with this system … when trying to achieve their objectives. – A use case model consists of • a set of use cases • an optional description or diagram indicating how they are related

Use cases • In general, a use case should cover the full sequence of steps from the beginning of a task until the end. • A use case should describe the user’s interaction with the system ... – not the computations the system performs.

• A use case should be written so as to be as independent as possible from any particular user interface design. • A use case should only include

Use Cases • Ask the following questions: – what functions will the actor want from the system? – does the system store information? what actors will create, read, update, or delete (CRUD operations) that information? – does the system need to notify an actor about changes in its internal state? – are there any external events the system must know about? what actors inform the system about these events?

• Other kind of use cases to consider are: – start-up, shut down, diagnostics, installation, training, and changing a business process. – Maintenance – will you have to shut it down or can you do your maintenance on it while still using it?

• When considering these and other questions, determine whether these functions are handled by our system?

Use Cases • For each of the identified requirements ask: – Are these requirements necessary for this system? – Are these requirements something this system would logically do? – Can these requirements be handled by one of the current actors? In other words, is someone else responsible for them? – Are these requirements something our customers would expect our system to do?

Order Processing Use Cases • From a customer – place order, send catalog, get status on order, return product, cancel order, register complaint • From a customer rep – place order, send catalog, get status on order, return product, cancel order, register complaint • To shipping companies – packages ready for delivery • From clerk – print mailing labels, calculate postage • To inventory system – give product information, update product quantities • from inventory system – back-ordered items

USE CASE If DIAGRAM the use case diagram is too big or messy, we can create several use case diagrams. Each diagram might represent a major area of functionality or we could have one per actor. At various points in the project we need to compare these diagrams to remove redundancies and to keep them

Scenarios • Each use case must include details about what has to be done to accomplish the functionality of the use case. – – – –

basic functionality alternative paths error conditions pre-condition: a condition that must be true before starting – post-condition: a condition that must be true at the end.

• The use case may contain conditionals, branching, and loops.

Scenarios • A scenario is an instance of a use case – It expresses a specific occurrence of the use case • a specific actor ... • at a specific time ... • with specific data.

Scenarios • Scenarios are written from an actor’s point of view. • Each scenario is a sequence of events that describes the functionality of the use case. • It can be thought of as a list of steps to go through to accomplish the use case. • The primary scenario is written as if everything goes right. • There must be one primary scenario for each use case. • Use cases are built iteratively.

Place Order Use Case Pre-condition: A valid user has logged into the system

Flow of Events: Basic Path: 1. The use case starts when the customer selects place order. 2. The customer enters his/her name and address 3. If the customer enters only the zip code the system will supply the city and the state. 4. The customer will enter product codes for desired products. 5. The system will supply a product description and

1. The customer will enter credit card payment information. 2. The customer will select submit. 3. The system will verify the information, save the order as pending, and forward the payment information to the accounting system. 4. When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case end.

lternative Path:

Showing Alternatives with Branching • Find Order Use Case Flow of Events: – – –

The user may enter an order ID, customer ID, or customer name. The user will press find. If the user entered an order ID a) The system will display the order.

4. If the user entered a customer name or customer ID a) The system will return a list of all orders for that customer. b) The user will select one order from the list c) The system will display the order

Repetition Flow of Events: Basic Path: –

– –

–

–

The use case starts when the customer selects place order. The customer enters his/her name and address If the customer enters only the zip code the system will supply the city and the state. The customer will enter product codes for desired products. For each product code entered • The system will supply a product description and the price for each item.

1.

2. 3.

4.

The customer will enter credit card payment information. The customer will select submit. The system will verify the information, save the order as pending, and forward the payment information to the accounting system. When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case end.

Repetition Flow of Events: Basic Path: –

– –

–

–

The use case starts when the customer selects place order. The customer enters his/her name and address If the customer enters only the zip code the system will supply the city and the state. The customer will enter product codes for desired products. While the customer enters product codes • The system will supply a product description and the price for each item. • The system will add the

1.

2. 3.

4.

The customer will enter credit card payment information. The customer will select submit. The system will verify the information, save the order as pending, and forward the payment information to the accounting system. When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case end.

Alternative Paths Flow of Events: Basic Path: 1.

2. 3.

4.

5.

The use case starts when the customer selects place order. The customer enters his/her name and address If the customer enters only the zip code the system will supply the city and the state. The customer will enter product codes for desired products. While the customer enters product codes • The system will supply a product description and the price for each item. • The system will add the

1.

2. 3.

4.

The customer will enter credit card payment information. The customer will select submit. The system will verify the information, save the order as pending, and forward the payment information to the accounting system. When payment is confirmed, the order is marked Confirmed, an order ID is returned to the customer, and the use case end.

lternative Paths At any time before selecting

Other alternative scenarios • Is there any difference between the way the customer and the sales rep interact with the system? • Are there any other error conditions? – an order arrives that is missing a payment. – an order arrives that is missing a shipping address.

Place Order Use Case Pre-condition: Flow of Events: Basic Path: Alternative Paths: Post Condition: Special Requirements: The system must always respond to the user input within one second.

Presentation Styles • Cancel Order Use Case • Primary Scenario When the customer rep receives a request to cancel order, the customer rep finds the order in the system and marks it cancelled. Then a request is sent to the accounting system to credit the customer’s account.

Presentation Styles • Cancel Order Use Case • Primary Scenario 1. The use case begins when a customer rep receives a request to cancel order. 2. The customer rep enters the order ID 3. The customer rep presses find 4. The system will display the order 5. The customer rep presses cancel-order 6. The system marks the order cancelled 7. The accounting system is notified to credit the customer’s account and the use case ends.

Secondary Scenarios • To completely define a use case we need to identify scenarios for alternative paths and scenarios for error conditions • These can be added to the basic path or written as secondary scenarios.

Place Order Secondary Scenarios • • • • • • • • • • •

Payment not there order incomplete order gets lost customer can’t login shipping address is incomplete product code does not match actual products product no longer carried payment bad customer pays by check customer sends order by mail customer phones in order

Dependencies <<extend>> and <> Stereotypes

• Extend dependencies are used when we have an optional sequence of events we want to include in the use case. • Used to make optional interactions explicit or to handle exceptional cases. • By creating separate use case extensions, the description of the basic use case remains simple. • A use case extension must list all the steps from the beginning of the use case to the end. – Including the handling of the unusual situation.

Dependencies <<extend>> Stereotypes • Determine what should be added and where it should be added. • More than one use case can extend from the same point. • More than one extension can be executed from the same point. • When the extension point is reached, the conditions for all the extending use cases for that point are evaluated. • Every extension with a true condition is executed. • The order of evaluation of the extending use cases is undefined.

Place Order Use Case 1. The customer will enter credit card payment information. 1. The use case starts 2. The customer will select when the customer submit. selects place order. 3. The system will verify 2. The customer enters the information, save his/her name and the order as pending, address and forward the 3. The customer will enter payment information to product codes for the accounting system. desired products. 4. When payment is 4. The system will supply a confirmed, the order is product description and marked Confirmed, an the price for each item. order ID is returned to 5. The system will keep the customer, and the running total items We need to add a of requirements to: use case end. ordered ason they are Place Order 2. offer sales various ___________ entered. merchandise on various items

Flow of Events: Basic Scenario:

3. offer special discounts to frequent customers

Sale Item , before step 5 Frequent customer , before step 6

Extending Use Case Seasonal Sale Price If product in Seasonal sale list then Sale Item Extension 1. The system will get the sale discount for the product 2. The system will display the discount on the order 3. The system will calculate a discount amount 4. The system will subtract the discount amount from the order total

Extending Use Case Frequent Customer Discount If the customer in Special Customer list then Special Customer Extension 1. The system discount 2. The system the order 3. The system amount 4. The system

will get the customer will display the discount on will calculate the discount will subtract the discount

Extending Use Case Overstock Product Sale If product in Overstock list and amount of product on hand > maximum stock level them Sale Item Extension 1. The system will for the product 2. The system will the order 3. The system will amount 4. The system will

get the sale discount display the discount on calculate a discount subtract the discount

If the product is overstocked and is also on sale then it will be discounted twice! Is the order important?

<> • Reuse the common behavior • Allow one to express commonality several different use cases.

between

• Inclusions are included in other use cases – Even very different use cases can share sequence of actions. – Enable you to avoid repeating details in multiple use cases. • Represent the performing of a lower-level task with a lower-level goal.

<> • Identify common steps • Put them in a use case and give it a name • Now remove these steps from the original use cases and replace them with a reference to the new use case. • It is important to note that the Using use case is no longer complete by itself.

Find Order Use Case Flow of Events: 1. The user may enter an order ID, customer ID, or customer name. 2. The user will press find. 3. If the user entered an order ID a)

The system will display the order.

4. If the user entered a customer name or customer ID a) b) c)

The system will return a list of all orders for that customer. The user will select one order from the list The system will display the order

Cancel Order Use Case – – – – –

6.

The use case begins when a customer rep receives a request to cancel order. The customer rep enters the order ID The customer rep presses find The system will display the order If the order status is Confirmed a) The order is marked Cancelled b) The accounting system is notified to credit the customer’s account and the use case ends. If the order status is Shipped a) The customer is notified of NW’s return policy

Cancel Order Use Case –

The use case begins when a customer rep receives a request to cancel order. – <> Find Order. – If the order status is Confirmed a) The order is marked Cancelled b) The accounting system is notified to credit the customer’s account and the use case ends. 4. If the order status is Shipped a) The customer is notified of NW’s return policy

Generalization • Much like super-classes in a class diagram. • A generalized use case represents several similar use cases. • One or more specializations provides details of the similar use cases. • Mostly used between actors. • Generalization between actors means that one actor fills the same roles as another actor. • It also may fill additional roles.

Example of generalization, extension and inclusion Open file

Ordinary User Open file by typing name

«extend»

System Administrator

Attempt to open file that does not exist

Open file by browsing

«include»

Browse for file

Example description of a use case Use case: Open file    Related use cases:  Generalization of:  • Open file by typing name  • Open file by browsing    Steps:  Actor actions  1. Choose ‘Open…’ command  3. Specify filename  4. Confirm selection   

System responses  2. File open dialog appears    5. Dialog disappears 

Example (continued) Use case: Open file by typing name    Related use cases:  Specialization of: Open file    Steps:  Actor actions  System responses  1. Choose ‘Open…’ command  2. File open dialog appears  3a. Select text field    3b. Type file name    4. Click ‘Open’  5. Dialog disappears   

Example (continued) Use case: Open file by browsing    Related use cases:  Specialization of: Open file  Includes: Browse for file    Steps:  Actor actions  1. Choose ‘Open…’ command  3. Browse for file  4. Confirm selection   

System responses  2. File open dialog appears    5. Dialog disappears 

Example (continued) Use case: Attempt to open file that does not exist    Related use cases:  Extension of: Open file by typing name    Actor actions  System responses  1. Choose ‘Open…’ command  2. File open dialog appears  3a. Select text field    3b. Type file name    4. Click ‘Open’  5.  System  indicates  that  file  does not exist  6. Correct the file name    7. Click ‘Open’  8 Dialog disappears   

Example (continued) Use case: Browse for file (inclusion)    Steps:  Actor actions  System responses  1.  If  the  desired  file  is  not  displayed,  2.  Contents  of  directory  is  select a directory  displayed  3. Repeat step 1 until the desired file is    displayed  4. Select a file     

Activity Diagram

User Interface