Admin Sub System

{Pizza Vera}
Author (s): _______Lushan Chokalingam ________ Date: ____2015/03/28_______
Version: ___1.0________

USE CASE NAME: Place Order USE CASE TYPE

USE CASE ID: 3.1 Business Requirements: 
PRIORITY: High System Analysis: 
SOURCE: Pizza Vera System Design: 
PRIMARY BUSINESS ACTOR Client
PRIMARY SYSTEM ACTOR Clerk
OTHER PARTICIPATING  None
ACTORS:
OTHER INTERESTED  Kitchen staff
STAKEHOLDERS:  Driver
DESCRIPTION: This use case describes the event of a client submitting a new order for any of Pizza Vera’s
products. The client gives the order to the clerk who then adds it to the system. And the order is
placed.
PRE-CONDITION: The client must be a registered client
TRIGGER: The client wants to place an order
TYPICAL COURSE Actor Action System Response
OF EVENTS: Step 1: The client wants to place an
order
Step 2: the clerk requests the client to
verify if the client is register with Piazza
Vera and asks the client to provide client
information such as, contact number or
name
Step 3: the client verifies that they are
register and provides the clerk with the
contact number or name
step 4: the clerk requests the system to Step 5: the system will ask the clerk to add client
place a new order information such as the contact number or name
Step 6: the clerk adds the client Step 7: the system searches for the client with that
information such as contact number or contact number or name and displays the client
name information, such as, client name, surname.
Cellphone number, address and email by invoking
use case 2.4 search client
Step 8: The clerk request the client to
provide order details
Step 9: The client provides the order
details to the clerk, such as, product
name, quantity and preferences
Step 10: the clerk request the system to Step 11: the system asks the clerk to add new order
add a new order details details
Step 12: the clerk adds the order details
such as the product name ,quantity and
order preferences
Step 13: the clerk requests the client to
choose whether the order is for delivery
or for pick up
Step 14: the client selects the order for
pick up
 Step 15: the clerk selects the pick-up Step 16: the system asks the clerk to confirm the
option on the system order details.
Step 17: the clerk communicates the
reordered order details to the client and
requests the client to confirm the details.
Step 18: the client confirms the order
details to the clerk

Step 19: the clerk confirms the order Step 20: the system adds a new order to the order
details on the system table and notifies the kitchen staff of a new order
Step 21: the system notifies the clerk that the order
was successfully placed.
Step 22: the system generates an invoice with an
order number , client name, surname, address,
contact number, items ordered with quantity and price
as well as order total
Step 23: the clerk communicates the
order total to the client and requests the
payment information.
Step 24: the client provides the payment
information to the clerk
Step 25: the clerk requests the system to Step 26: the system asks the clerk to choose the type
record the payment information of payment (cash or card)
Step 27: the clerk chooses the type of Step 28: the system asks the clerk to confirm the
payment and adds the payment payment information
information
Step 29: the clerk confirms the payment Step 30: the system records the payment information
information
Step 31: the system notifies the clerk that the
payment information was successfully recorded.
Step 32: the system generates a receipt with order
details and payment information.
Step 33: the system generates a preparation order
which includes the order details (order number,
products and quantity)
Step 34: the user action information is added to the
audit trail
ALTERNATE COURSES: Alt step 3: the client is not registered and use case 2.1 – Register client is invoked
Alt step 14: the client selects the order for delivery and the order is added to the a delivery list and
the use case continues at step 15
Alt step 23: the clerk communicates the order total to the client and if the order is for delivery, the
use case concludes.
CONCLUSION: The use case concludes when the order is placed and payment is received.
POST-CONDITION: The order number is generated.
BUSINESS RULES  The client can request a delivery or pick up, order options for receiving order method.
IMPLEMENTATION  None
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS: None
OPEN ISSUES:  None
USE CASE NAME: Update Order USE CASE TYPE
USE CASE ID: 3.2 Business Requirements: 
PRIORITY: High System Analysis: 
SOURCE: Pizza Vera System Design: 
PRIMARY BUSINESS ACTOR Client
PRIMARY SYSTEM ACTOR Clerk
OTHER PARTICIPATING  Kitchen staff
ACTORS:  Driver
OTHER INTERESTED  None
STAKEHOLDERS:
DESCRIPTION: This use case describes the event of a client updating or changing any details of his/her order. The
client requests the clerk to edit the order on the system and provides his/her changes and
concludes when the order is updated.
PRE-CONDITION: There must be an existing order
TRIGGER: The client wants to update an order
TYPICAL COURSE Actor Action System Response
OF EVENTS: Step 1: The client wants to update an
order
Step 2: the clerk requests the client to
provide the order details
Step 3: the client provides the order
details to the clerk
Step 4: the clerk requests the system to Step 5: the system invokes use case 3.7 search order
update an order
Step 6: the system asks the clerk to update the order
details
Step 7: the clerks requests the client to
provide the updated information for the
order
Step 8: the client provides the updated
order information
Step 9: the clerk add the updated order Step 10: the system asks the clerk to confirm
information onto the system updating the order

Step 11: the clerks communicates the

recorded information and requests the
client to confirm updating the order
Step 12: the client confirms updating the
order
Step 13: the clerk confirm updating the Step 14: the system updates the order details and
order updates the information in the order table and notifies
the kitchen staff of the new updated order
Step 15: the system notifies the clerk that the order
update is successful.
Step 16: the system updates the delivery type of an
order.
Step 17: the user action information is added to the
audit trail
Step 18: The clerk notifies the client that
the order has been updated.
ALTERNATE COURSES: Alt Step 12: the client doesn’t confirm the order details and the use case continues at step 7
Alt step 13: the clerk doesn’t confirm the order details, the use case is terminated.
CONCLUSION: The use case concludes when an order is successfully updated
POST-CONDITION: Order details is updated
BUSINESS RULES  Clients can only update an order within five minutes of placing an order
IMPLEMENTATION None
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:  The client wants to update the order within the five minutes
OPEN ISSUES: Orders cannot be updated once they are already in the production phase.
USE CASE NAME: Cancel Order USE CASE TYPE
USE CASE ID: 3.3 Business Requirements: 
PRIORITY: High System Analysis: 
SOURCE: Pizza Vera System Design: 
PRIMARY BUSINESS ACTOR Client
PRIMARY SYSTEM ACTOR Clerk
OTHER PARTICIPATING  Kitchen Staff (ERA)
ACTORS:
OTHER INTERESTED  None
STAKEHOLDERS:
DESCRIPTION:
This use case describes the event of a client cancelling an order from Pizza Vera. The client gives
the cancellation to the clerk who then adds it to the system.
PRE-CONDITION: There must be an existing order
TRIGGER: The client wants to cancel an order
TYPICAL COURSE Actor Action System Response
OF EVENTS: Step 1: The client wants to cancel an
order.
Step 2: the clerk requests the client to
provide the order details
Step 3: the client provides the order
details
Step 4: the clerk requests the system to Step 5: the system invokes use case 3.7 search order
cancel an order
Step 6: the system asks the clerk to confirm canceling
an order
Step 7: the clerk requests the client to
confirm the canceling of the order
Step 8: the client confirms canceling the
order
Step 9: the clerk confirms canceling the Step 10: the system cancels the order and removes it
order to the system from the order table
Step 11: the system cancels the preparation order
and delivery request
Step 12: the system records the refund amount.
Step 13: the user action information is added to the
audit trail

ALTERNATE COURSES: Alt Step 8: the client doesn’t confirm that the order be canceled. The use case terminates
Alt step 9: the clerk doesn’t confirm that the order be canceled. The use case terminates
CONCLUSION: This use case concludes when an order is successfully canceled.
POST-CONDITION: Order is canceled
BUSINESS RULES  Refunds on card payments will be given in cash.
 Canceling order must be done within five minutes of placing the order.
IMPLEMENTATION  None
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS: The client cancels the order within five minutes of placing the order.
OPEN ISSUES:  None
USE CASE NAME: Confirm Prepared Order USE CASE TYPE
USE CASE ID: 3.4 Business Requirements: 
PRIORITY: High System Analysis: 
SOURCE: Pizza Vera System Design: 
PRIMARY BUSINESS ACTOR Kitchen Staff
PRIMARY SYSTEM ACTOR  None
OTHER PARTICIPATING  Clerk
ACTORS:  Client
OTHER INTERESTED  None
STAKEHOLDERS:
DESCRIPTION: This use case describes the event of an order completing its preparation and being handed over to
the clerk for the client to collect. The kitchen staff updates the order status to complete and the
clerk and client are notified.
PRE-CONDITION: An order must have been placed
TRIGGER: The order is prepared and ready
TYPICAL COURSE Actor Action System Response
Step 1: The order is prepared and ready
OF EVENTS: Step 2: the kitchen staff request the Step 3: the system displays a list of orders which are
system to update the order status not ready and prompts the kitchen staff to select the
order which is prepared and ready
Step 4: the kitchen staff selects the order Step 5: the system updates the order status of that
order to prepared and ready
Step 6: the system adds the order to the prepared
order list
Step 7: the system notifies the client and the clerk
that the order is ready
Step 8: the user action information is added to the
audit trail
ALTERNATE COURSES:  None
CONCLUSION: The use case concludes when the order status is changed to prepared and ready and the client
and the clerk are notified.
POST-CONDITION: The order is prepared.
BUSINESS RULES  None
IMPLEMENTATION  None
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS: none
OPEN ISSUES:  None
USE CASE NAME: Deliver order USE CASE TYPE
USE CASE ID: 3.5 Business Requirements: 
PRIORITY: High System Analysis: 
SOURCE: Pizza Vera System Design: 
PRIMARY BUSINESS ACTOR Driver
PRIMARY SYSTEM ACTOR  None
OTHER PARTICIPATING  Client
ACTORS:
OTHER INTERESTED  Clerk
STAKEHOLDERS:
DESCRIPTION:

PRE-CONDITION: Orders must have been placed for delivery

TRIGGER: The driver wants deliver the order
TYPICAL COURSE Actor Action System Response
OF EVENTS: Step 1: The driver wants deliver the order Step 2: the system generates a list of orders to be
delivered.
Step 3: the driver selects the order to be
delivered and request the system to
confirm delivery
Step 4: the driver communicates the
order information to the client and
requests the client to confirm the order
details
Step 5: the client confirms the order
details
Step 6: the driver communicates the
order total to the client and requests the
payment information
Step 7: the client provides the payment Step 8: the system asks the driver to enter the
information amount paid by the client
Step 9: the driver enters the amount Step 10: the system displays the amount of change
received that is due to the client
Step 11: the system asks the driver to confirm the
delivery is complete.
Step 12: the driver confirms that the Step 13: the system updates the order status
delivery is complete.
Step 14: the user action information is added to the
audit trail
ALTERNATE COURSES: Alt Step 5: the client doesn’t confirm the order details and the use terminates
Alt step 12: The driver doesn’t confirm the order is delivered and the use case is terminated.
CONCLUSION: The use case concludes when the delivery confirmed
POST-CONDITION: The order is delivered
BUSINESS RULES  Client who requested for delivery can only pay by cash.
.

IMPLEMENTATION  None
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:  The order prepared was correct for the appropriate client
OPEN ISSUES:  None
USE CASE NAME: Reconcile Delivery Payments USE CASE TYPE
USE CASE ID: 3.6 Business Requirements: 
PRIORITY: High System Analysis: 
SOURCE: Pizza Vera System Design: 
PRIMARY BUSINESS ACTOR Driver
PRIMARY SYSTEM ACTOR  Clerk
OTHER PARTICIPATING  None
ACTORS:
OTHER INTERESTED  Owner and manager
STAKEHOLDERS:
DESCRIPTION: This use case describes reconciliation delivery payments, in which the system reconciles that a
payment received from a delivery matches the payment for the order delivered.

PRE-CONDITION: Orders must have been delivered

TRIGGER: The driver wants hand over the money received from deliveries
TYPICAL COURSE Actor Action System Response
OF EVENTS: Step 1: The driver wants hand over the
money received from deliveries
Step 2: the clerk asks the system to Step 3: the system generates a list of orders that
reconcile the delivery payments were delivered with the order number, product name
quantity ,price order total and driver name
Step 4: the system asks the clerk to reconcile
Step 5: the clerk ticks off the order for Step 6: the system saves the information and
which payment was received. reconciles the deliveries with the payments
Step 7: the driver confirms that the delivery is
complete.
ALTERNATE COURSES: Alt Step 5: the clerk doesn’t tick off an order if the payment was not received and this unpaid order
is added to the unpaid order list
CONCLUSION: The use case concludes when the delivery payments are reconciled.
POST-CONDITION: Delivery payments are reconciled.
BUSINESS RULES  None

IMPLEMENTATION  None
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:  Check
OPEN ISSUES:  None
USE CASE NAME: Search order USE CASE TYPE
USE CASE ID: 3.7 Business Requirements: 
PRIORITY: Medium System Analysis: 
SOURCE: Pizza Vera System Design: 
PRIMARY BUSINESS ACTOR Manager
PRIMARY SYSTEM ACTOR None
OTHER PARTICIPATING  none
ACTORS:
OTHER INTERESTED  none
STAKEHOLDERS:
DESCRIPTION: This use case describes the event of performing a search of orders and selecting an order and
displaying that order information.
PRE-CONDITION:  The manager must be logged into the system.
 An order must already exist
TRIGGER: The manager wants to search an order
TYPICAL COURSE Actor Action System Response
OF EVENTS: Step 1:The manager wants to search an Step 2: the system asks the manager to add order
order search information
step 3: the manager adds the search step 4: the system displays a list of all relevant orders
information that meet the search information
Step 5:the system asks the manager to select an
order
Step 6: the manager selects an order Step 7: the system displays the selected order
information
ALTERNATE COURSES: None
CONCLUSION: The use case ends when an order has been successfully searched and information regarding the
order is displayed.
POST-CONDITION: Order information is displayed.
BUSINESS RULES  none
IMPLEMENTATION  none
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:  none
OPEN ISSUES: none