Use Cases
1
Question 1
• Each waiter is assigned a group of tables, after taking orders for a table the waiters
enter the orders (a list of dishes and drinks ordered by the diner or group of diners)
into the system at the PC. The waiter usually knows of any dishes that are unavailable
before taking an order but occasionally one of the specials will sell out. The system
must confirm the availability of dishes. Should an item not be available the system
must allow the waiter to change or even delete a customer’s order. Dishes to be
prepared are sent to the kitchen, drinks orders to the drink section. Starters and main
course orders are usually taken together. Drinks and desert orders may be taken
separately.
• Kitchen staff sees the dish orders on their screen, prepare them in an appropriate
sequence and confirm preparation to the system when complete, similarly with the
drink section.
• When a waiter sees the completion indications on his terminal he collects the items
and takes them to the table. The waiter can also check on the status of dish and drink
orders.
• At the end of the meal the waiter will have the system print a bill, and he will enter
the details of payment for it. The management can give discounts.
• The system keeps track of the numbers of customers served by each waiter and the
amount of money taken by each waiter. The management can view these statistics.
2
Question 1
Write down the functional and non- functional requirements.
• The Waiter shall enter order of drinks and food into the system
• The system shall alert the waiter that the food is out of stock. Then the Waiter shall
change or delete the order in the system
• The system shall alert the Kitchen staff of the food orders
• The system shall alert the Bar staff of the drink orders
• Kitchen and Bar staff shall confirm preparation to the system when complete
• The system shall alert the Waiter that the drink or food order is ready
• The Management should grant a discount from the bill
• The Waiter shall use the system to print out the bill
• The Waiter shall enter the payment details into the system
• The Management shall use the system to view the statistics regard numbers of customers
served by each waiter and the amount of money taken by each waiter
Non- functional requirements
• Experienced users shall be able to use all the system functions after a total of two hours
training. After this training, the average number of errors made by experienced users
shall not exceed two per day.
• (Reliability) If the connection between the user and the system is broken prior to an
order being either confirmed or canceled, the Online Bookshop System shall enable the
user to recover an incomplete order.
3
Question 1
We should be very careful when specifying nonfunctional requirements. Why?
If you don’t do it right you will build a very elegant software
solution that solves the wrong problem. The result is project
failure, wasted time and money, personnel frustration, and
customer dissatisfaction.
4
Question 1
Use the following table to identify the: actor and unit of functionality.
Actor
Unit of Functionality


Waiter



Kitchen staff
Bar staff
Management
The Waiter shall enter order of drinks and food into the system
The system shall alert the waiter that the food is out of stock.
Then the Waiter shall change or delete the order in the system
The system shall alert the Waiter that the drink or food order is
ready
The Waiter shall use the system to print out the bill
The Waiter shall enter the payment details into the system
• The system shall alert the Kitchen staff of the food orders
• Kitchen staff shall confirm preparation to the system when
complete
• The system shall alert the Bar staff of the drink orders
• Bar staff shall confirm preparation to the system when
complete
• The Management shall use the system to view the statistics
regard numbers of customers served by each waiter and the
amount of money taken by each waiter
• The Management should grant a discount from the bill
5
Question 1
• Draw the use case diagram.
6
Question 1
• Draw the use case diagram.
7
Question 1
• Draw the use case diagram.
8
Question 1
• Write the high level description of all use cases.
•
•
•
•
•
Use case: Input Order
Actors: Waiter
Goal: To input an order for a meal
Description:
When a Diner orders a meal, the Waiter writes down the order and puts it into
the
• system. The system presents this order to the Kitchen staff who prepare the
food.
•
•
•
•
•
•
Use case: Prepare orders
Actors: Kitchen staff and Bar staff
Goal: To prepare the orders presented by the system
Description:
The system presents the meal order to the Kitchen staff to prepare the food. The
system also presents the drinks order to the Bar staff to prepare the drink.
9
Question 1
•
•
•
•
•
•
•
•
Use case: Announce order readiness
Actors: Kitchen staff and Bar staff
Goal: To Alert the Waiter to the readiness of the order
Description:
The Bar staff prepare the drinks and use the system to send an announcement to the
Waiters terminal that they are ready to be served. The Kitchen staff prepare the
dishes and use the system to send an announcement to the Waiters terminal that
they are ready to be served.
•
•
•
•
•
•
Use case: Print Bill
Actors: Waiter
Goal: To print a bill for the Diner
Description:
Once the Diner has finished their meal, the Waiter uses the system to print a bill
for presentation to the Diner
•
•
•
•
•
•
Use case: Input payment details
Actors: Waiter
Goal: To input payment details to the system
Description:
The Waiter takes the payment from the Diner and uses the system to input the
details about the payment.
10
Question 1
• Write the high level description of all use cases.
•
•
•
•
•
Use case: Grant discount
Actors: Management
Goal: To grant a discount from the bill
Description:
Management use the system to alter the bill that is to be presented to
the Diner.
•
•
•
•
•
Use case: View statistics
Actors: Management
Goal: To view statistics
Description:
Management use the system in order to view various statistics about
the Waiters
• and the amount of money that they have taken.
11
Question 1
• Write the expanded description of the two most
important use cases.
• Take order
• Take payment
12
Question 1
13
Question 1
14
Question 2
• The concrete use cases are Phone Order (initiated by the Customer actor)
and Internet Order (initiated by Internet Customer). These are both
variations of the more general Place Order use case. To simplify the Place
Order use case, the Request Catalog use case and Supply Customer Data use
case are used.
• Draw the use case diagram showing use cases relationships and actors
generalization if exist.
• The Request Catalog use case represents an optional segment of behavior
that is not part of the primary purpose of Place Order.
• The Supply Customer Data use case represents a segment of behavior that
was factored out since it is a separate function of which only the result is
affecting the Place Order use case. The Supply Customer Data use case can
also be reused in other use cases.
15
Question 2
• Draw the use case diagram showing use cases relationships and actors
generalization if exist.
16
Question 2
• Identify abstract use cases. What could be changed if Order Registry Clerk
actor, who can enter orders into the system on behalf of all kind of
customers, are added to the model?
*This actor would initiate
the general Place Order
use case.
*The child use cases can
add behavior to the
structure that the parent
use case provides, and also
modify behavior in the
parent
* Place Order can also be
specialized by the use
cases Phone Order or
Internet Order
17
Question 2
• Are use cases always related to actors? Are there exceptions?
The execution of each use case includes communication with one or more
actors.
A use case instance is always started by an actor asking the system to do
something. This implies that every use case should have communicatesassociations with actors.
The reason for this rule is to enforce the system to provide only the
functionality that users need, and nothing else.
Having use cases that no one requests is an indication that something is wrong
in the use-case model or in the requirements.
18
Question 2
• Are use cases always related to actors? Are there exceptions?
However, there are some exceptions to this rule:
• If a use case is abstract (not separately instantiable), its behavior may not
include interaction with any actor. In that case, there will not be any
communication-associations to actors from that abstract use case.
• A child use case in a generalization-relationship does not need to have an
actor associated with it if the parent use case describes all actor
communication.
• A base use case in an include-relationship does not need to have an actor
associated with it if the inclusion use case describes all actor
communication.
• A use case may be initiated according to a schedule (for example, once a
week or once a day), which means the system clock is the initiator. The
system clock is internal to the system - and the use case is not initiated by
an actor, but by an internal system event. If no other actor interaction
occurs in the use case, it will not have any associations to actors. However,
for clarity, you can use a fictive actor "Time" to show how the use case is
initiated in your use-case diagrams.
19
Concrete and Abstract Use
Cases
• A concrete use case is initiated by an actor and constitutes a
complete flow of events. "Complete" means that an instance of the
use case performs the entire operation called for by the actor.
• An abstract use case is never instantiated in itself. Abstract use cases
are included in (Include-Relationship), extend into (ExtendRelationship), or generalize (Use-Case-Generalization) other use
cases.
• When a concrete use case is initiated, an instance of the use case is
created. This instance also exhibits the behavior specified by its
associated abstract use cases. Thus, no separate instances are
created from abstract use cases.
• The distinction between the two is important, because it is concrete
use cases the actors will "see" and initiate in the system.
• You indicate that a use case is abstract by writing its name in italics.
20
Simple Online shopping portal
• An online shopping portal allows their customers to browse or buy
different items. A customer may buy item(s) or just view the items and
logout. If the customer decides to purchase an item, he/she selects the
item and adds it to the shopping cart. Once the customer finishes
selecting the item(s) the cart can be viewed. The customer can edit the
final cart then submit the final cart for payment, or logout from the site
without buying the items. The site's administrator can add or update
different items in the system, manage the registration of new customer,
and ensure the authorization of already registered customers.
• Draw the use case diagram for this system,
• without using extends or includes use cases…
21
Simple Online shopping portal
• An online shopping portal allows their customers to browse or buy
different items. A customer may buy item(s) or just view the items and
logout. If the customer decides to purchase an item, he/she selects the
item and adds it to the shopping cart. Once the customer finishes
selecting the item(s) the cart can be viewed. The customer can edit the
final cart then submit the final cart for payment, or logout from the site
without buying the items. The site's administrator can add or update
different items in the system, manage the registration of new customer,
and ensure the authorization of already registered customers.
• Draw the use case diagram for this system,
• without using extends or includes use cases…
22
Customer
Online shopping System
Browse Items
Log in
Log out
Add item to cart
View the cart
Edit the cart
Make Payment
Add new Item
Update Item
Register
Authorize Customers
Admin
23
Question 4
• Do the following operations on the use case diagram
stated bellow
24
Question 4
• Update the use case diagram such that a new patient
can open a file. Also nurses help in making
appointments and they can view a schedule. Also,
Management and doctors can view the schedule. Add
any other appropriate missing things.
25
Question 4
Nurse
View
Schedul
e
<<extends>>
Open File
26
Question 4
• Write a high level format for make appointment use case.
• Write typical course of events and alternatives for make
appointment use case.
27
Use case: Make appointment
• Use Case: Make appointment.
• Actor: Patient (initiator), Nurse.
• Purpose: To record a new appointment.
• Overview (Success Scenario):
This use case begins when the patient ask a nurse to reserve an
appointments with a certain doctor. On completion, an appointment
slip is produced.
• Type: Primary, Essential.
28
Use case: Make appointment
Actor Action
System Response
1. This use case begins when the patient
come to the nurse or call her to ask for an
appointment.
2. The nurse request the patient id from the
patient and enter it.
3. Show patient information.
4. Nurse ask the patient for doctor name and 5. System returns all possible appointment
department and enter them.
dates and times for the specified doctor.
6. Nurse tell the patient about all the
possibilities and get from him/her the
most desired one, and reserve it.
7. Reserves the appointment.
8. The nurse request the appointment slip.
9. Generate appointment slip.
10. The nurse gives the printed appointment
slip to the patient.
11. The patient leaves with appointment slip.
29
Use case: Make appointment
Alternatives:
Line 2. If patient was a new one, then a new file should be created; see open
file use case.
Line 2. If patient forgot ID, provide Phone number.
Line 3. If the ID was wrong, the system will display a message to indicate
that.
30