Name: Mustafa Hani Mousa Alzaghal

Use Case Modeling

Use-case Glossary:
1- Registering an Account.

2- Placing an Order

3- Searching for Item

4- Displaying Location of Restaurant

5- Adding Food to Cart

6- Changing Password

7- Changing Username

8- Displaying Menu Items

9- Displaying Order History

10- Sending a Complaint

Use-case Scenarios:
1: Registering an Account
Use-Case Name: Registering an Account
Description: The purpose of this use-case is for registering the user to the database. If all the
credentials are confirmed and follow the policies, the user will be saved to the database with all
their information as a customer and a confirmation message will be displayed.
Actors:
1- Primary Actor: The user registering.
2- Secondary Actor: Database system storing the data of the user.
3- External Server Actor: Restaurant.
Preconditions:
1- Credentials must follow security policies.
2- Username must be unique.
Postconditions:
1- The data of the user must be stored in the system.
2- Confirmation message must appear.
Trigger: The use-case will be initialized when the user clicks the “Register” button.
Normal Flow:
1- The user indicates that they want to register.
2- The system asks for their username, email and password
3- The user provides the required information while complying with the policies.
4- The system will confirm that the user has been registered.
Alternate Flow:
1- If the user leaves required information empty, the system will provide an error message
to tell them to provide the said information.
2- If the user doesn’t follow the security policies for the password, the system will provide
a message that will explain how the password should be structured.
Business Rules: Null
2: Placing an Order
Use-Case Name: Placing an Order
Description: The purpose of this use-case is to allow registered users to place their order to the
database so they could get their meals ready.
Actors:
1- Primary Actor: The user ordering.
2- Secondary Actor: Database system storing order.
3- External Server Actors: Restaurant - Credit bureau.
4- External Receiver Actor: Kitchen.
Preconditions:
1- User must be registered to the system.
2- Cart must not be empty.
Postconditions:
1- Order will be placed into the system.
2- The customer will need to pay in advance if online payment is chosen.
3- The order will have a unique id displayed to the customer.
4- Customer will know the estimated delivery date.
Trigger: The use-case will be initialized when the user places the products to their cart and
clicks the “Order” button.
Normal Flow:
1- The customer indicates that they want to place an order.
2- The system will show the amount due to the customer.
3- The customer will choose their payment method.
4- The customer will confirm their order and check the order details.
Alternate Flow:
1- If the user does not have an account, he/she can register first.
2- The user could change the items in the order or their quantities by canceling the place
order use-case and goes back to select the products.
3- If the customer chooses online payment, then they will have to pay in advance.
4- If the customer chooses online payment and he/she has insufficient funds, then the
order process will be cancelled.
Business Rules: The customer must be registered and will be billed in cash when they get their
food, or they will pay in advance using online payment.
3: Searching for Item
Use-Case Name: Searching for Item
Description: The purpose of this use-case is to allow users to search for a specific food item
from the menu by typing its name in a search bar.
Actors:
1- Primary Actor: The user searching.
2- Secondary Actor: Database system storing the menu items.
3- External Server Actor: Restaurant.
Preconditions:
1- The searched food item must exist in the database.
Postconditions:
1- If the item exists, then it must appear in front of the customer.
2- Customer will be able to add the item to their order.
Trigger: The use-case will be initialized when the user searches for a specific food item from the
menu using the search bar.
Normal Flow:
1- The customer indicates that they want to search for a specific item.
2- The system will show the item.
Alternate Flow:
1- If the item does not exist, then an error message will appear that clarifies that.
Business Rules: Null
4: Displaying Location of Restaurant
Use-Case Name: Displaying Location of Restaurant
Description: The purpose of this use-case is to allow all users (registered or not) to know the
location of the restaurant by clicking a button.
Actors:
1- Primary Actor: User wanting to see the location
2- Secondary Actor: Location Program that shows the location.
3- External Server Actor: Restaurant.
Preconditions: Null
Postconditions:
1- User must see the location of the restaurant once he/she clicks the button.
Trigger: The use-case will be initialized when the user clicks the “Show Location” button.
Normal Flow:
1- The user indicates that they want to see the location of the restaurant.
2- The user clicks the button and sees the location.
Alternate Flow: Null
Business Rules: Null
5: Adding Food to Cart
Use-Case Name: Adding Food to Cart
Description: The purpose of this use-case is to give users the ability to add different types of
menu items to their order so they could confirm it.
Actors:
1- Primary Actor: User adding the menu items.
2- Secondary Actor: Datastructure used for displaying and ordering the items.
3- External Server Actor: Restaurant.
Preconditions:
1- User must be registered to the system.
Postconditions:
1- Menu items must be added to the order of the customer.
2- The system must display a confirm message after the addition.
Trigger: The use-case will be initialized when the user clicks the “Add to Cart” button next to
the different menu items.
Normal Flow:
1- The user indicates that they want to add menu items to their order.
2- The user clicks the add button next to the items and adds them to the order.
3- The system will display a message that confirms the addition of the item.
Alternate Flow:
1- If the user is not registered, then he/she will need to registered first before adding any
item to their cart.
2- If the item is unavailable at the moment, then an error message that explains that will
appear.
Business Rules: The user must be registered to the system.
6: Changing Password
Use-Case Name: Changing Password
Description: The purpose of this use-case is to give users the ability to change their passwords
whenever they feel like it.
Actors:
1- Primary Actor: User wanting to change their password.
2- Secondary Actor: Database system that stores the password.
3- External Server Actor: Restaurant.
Preconditions:
1- User must be registered to the system.
2- User must know the old password.
3- New password must be compliant with the policies.
Postconditions:
1- The password of the user must be changed.
2- The system must show a confirmation message.
Trigger: The use-case will be initialized when the user clicks the “Change Password” button in
the account page.
Normal Flow:
1- The user indicates that they want to change their password
2- The user receives an email that requests them to click a link to change their password.
3- The user clicks the link and provides the old password and the new password.
4- The system displays a confirmation message.
Alternate Flow:
1- If the user does not click the link sent to their email, nothing will happen, and the
account will work with the original password.
2- If the user enters an incorrect old password, an error message will appear explaining
that.
3- If the user enters a new password that does not satisfy the policies, then a message will
appear explaining that.
Business Rules: The user must be registered to the system and the new password must be
compliant with the policies.
7: Changing Username
Use-Case Name: Changing Username
Description: The purpose of this use-case is to give users the ability to change their usernames
whenever they feel like it.
Actors:
1- Primary Actor: User wanting to change their username.
2- Secondary Actor: Database system storing the username.
3- External Server Actor: Restaurant.
Preconditions:
1- The user must be registered to the system.
2- The new username must be unique.
3- The new username must be compliant with the policies.
Postconditions:
1- The username must be changed.
2- The system must show a confirmation message.
Trigger: The use-case will be initialized when the user clicks the “Change Username” button in
the account page.
Normal Flow:
1- The user indicates that they want to change their username.
2- The user clicks the button and goes to the “Change Username” page.
3- The user provides the required credentials.
4- The system displays a confirmation message.
Alternate Flow:
1- If the user enters a username that does not comply with the policies, an error message
will appear explaining that.
2- If the user enters an already used username, an error message will appear explaining
that.
Business Rules: The user must be registered to the system and the new username must be
compliant with the policies.
8: Displaying Menu Items
Use-Case Name: Displaying Menu Items
Description: The purpose of this use-case is to show the users the menu items of the restaurant
whether they are registered or not.
Actors:
1- Primary Actor: User wanting to see the menu items.
2- Secondary Actor: Database system storing the menu items.
3- External Server Actor: Restaurant.
Preconditions: Null
Postconditions:
1- The user must have seen the menu items.
Trigger: The use-case will be initialized when the user opens the “Menu Items” tab.
Normal Flow:
1- The user indicates that they want to see the menu items.
2- The user sees the different menu items.
Alternate Flow: Null
Business Rules: Null
9: Displaying Order History
Use-Case Name: Displaying Order History
Description: The purpose of this use-case is to show the users their entire order history since
the moment they registered their account.
Actors:
1- Primary Actor: User wanting to see their order history.
2- Secondary Actor: Database system storing the user’s order history.
3- External Server Actor: Restaurant.
Preconditions:
1- The user must be registered to the system.
2- The user must have placed one order at the very least.
Postconditions:
1- The user must have seen their order history.
Trigger: The use-case will be initialized when the user presses the “Order History” button in the
account page.
Normal Flow:
1- The user indicates that they want to see the order history.
2- The user sees their order history.
Alternate Flow:
1- If the user has not placed an order yet, then an error message will appear that explains
that.
2- If the user is not registered to the system, then an error message will appear that
explains that.
Business Rules: The user must be registered to the system and made at least one order.
10: Sending a Complaint
Use-Case Name: Sending a Complaint
Description: The purpose of this use-case is to allow the user to send a complaint regarding an
incident that happened while using the program.
Actors:
1- Primary Actor: User that wants to file a complaint.
2- Secondary Actor: Database system that stores the complaints with their unique IDs.
3- External Server Actor: Restaurant.
4- External Receiver Actor: Staff Member.
Preconditions:
1- The user must be registered to the system.
2- The user must have placed one order at the very least.
Postconditions:
1- The complaint will be sent to the staff members.
2- A response is sent in about 3 days.
Trigger: The use-case will be initialized when the user presses the “File a Complaint” button in
the account page.
Normal Flow:
1- The user indicates that they want to file a complaint.
2- The user writes the ID of the order and the description of their complaint.
3- The user receives a response in their email a couple of days later.
Alternate Flow:
1- If the user is not registered, an error message will appear explaining that.
2- If the user has not placed an order yet, then an error message will appear that explains
that.
3- If the issue is complicated, then it might take more time to receive a response.
Business Rules: The user must be registered to the system and made at least one order.
Use-case Diagram: