Super Take-out System Problem Description Traditional take-out industry mostly depends on the artificial way to conduct a series of management. For example, when receiving orders, it requires people to record dishes, delivery address and guests’ telephone number, and to calculate the take-out cost, which not only wastes time and reduces the efficiency, but also increases the cost, reduces the profits of the industry, and then makes the traditional take-out consumption suffer bottleneck limitation. Besides that, traditional take-out industry’ marketing means such as publicity and external service are confined to the original medium, for example, to distribute leaflets still needs human to complete. The traditional shop take-out management also adopts papery materials to save information. This method is inconvenient to query or update and easy to tear, and it is also difficult to save with low confidentiality. In take-out industry, the e-commerce is still in the initial stage of development. But with the continuous increase of Internet users, and accelerating pace of people’ work and life, the network consumption demand will be huge, while the online meal ordering is just developed in this context. Online meal ordering can largely reduce the waste of time, and at the same time help merchants earn more profits, so the network online meal order is bound to become a part of young Internet users’especially white-collars’life. System Capabilities · The new system should capable of: · Collecting the basic information, phone number, address, ordered take-out products of consumers · Collecting the basic information, phone number, address, unit price of delivery products, and the delivery fee of the merchants. · Allowing merchants inquire consumers’ order information · Connecting System through various devices (I.E. desktop and smart phones) Business benefits · save operating cost for merchants · improve the ordering efficiency · obtain more detailed and accurate consumer information · provide more efficient publicity channels · offer more excellent customer experience Schedule Plan- First Version Collect relevant information 7days Begin planning team project idea 7days Designing breakdown Structure 7days Designing reception-ordering system 7days Designing backstage management system 7 days Designing the Database 7 days Debugging the system 7 days Budget Plan A. Summary Actual Budget: Server for web hosting and database: $0 Labor: $0 (college students working on this for a project grade) Total Estimated Budget: $0 B. Summary “Actual” Budget Server for web hosting and database: $200 Labor: 2 Systems designers half time: $45/hour Total estimated bid: $15000 3.1 Functional Requirements Web Order System Module This allows the customer to interact with the system by placing an order. For the restaurant customers to complete this task, they need to provide the following functions: 1. Create an account 2. Manage their accounts 3. Log in ...

1. Super Take-out System
Problem Description
Traditional take-out industry mostly depends on the artificial
way to conduct a series of management. For example, when
receiving orders, it requires people to record dishes, delivery
address and guests’ telephone number, and to calculate the take-
out cost, which not only wastes time and reduces the efficiency,
but also increases the cost, reduces the profits of the industry,
and then makes the traditional take-out consumption suffer
bottleneck limitation. Besides that, traditional take-out
industry’ marketing means such as publicity and external
service are confined to the original medium, for example, to
distribute leaflets still needs human to complete. The traditional
shop take-out management also adopts papery materials to save
information. This method is inconvenient to query or update and
easy to tear, and it is also difficult to save with low
confidentiality.
In take-out industry, the e-commerce is still in the initial stage
of development. But with the continuous increase of Internet
users, and accelerating pace of people’ work and life, the
network consumption demand will be huge, while the online
meal ordering is just developed in this context. Online meal
ordering can largely reduce the waste of time, and at the same
time help merchants earn more profits, so the network online
meal order is bound to become a part of young Internet
users’especially white-collars’life.
System Capabilities
· The new system should capable of:
· Collecting the basic information, phone number, address,
ordered take-out products of consumers
· Collecting the basic information, phone number, address,
unit price of delivery products, and the delivery fee of the

2. merchants.
· Allowing merchants inquire consumers’ order information
· Connecting System through various devices (I.E. desktop and
smart phones)
Business benefits
· save operating cost for merchants
· improve the ordering efficiency
· obtain more detailed and accurate consumer information
· provide more efficient publicity channels
· offer more excellent customer experience
Schedule Plan-
First Version
Collect relevant information
7days
Begin planning team project idea
7days
Designing breakdown Structure
7days
Designing reception-ordering system
7days
Designing backstage management system
7 days
Designing the Database
7 days
Debugging the system
7 days

3. Budget Plan
A. Summary Actual Budget:
Server for web hosting and database: $0
Labor: $0 (college students working on this for a project grade)
Total Estimated Budget: $0
B. Summary “Actual” Budget
Server for web hosting and database: $200
Labor: 2 Systems designers half time: $45/hour
Total estimated bid: $15000
3.1 Functional Requirements
Web Order System Module
This allows the customer to interact with the system by placing
an order. For the restaurant customers to complete this task,
they need to provide the following functions:
1. Create an account
2. Manage their accounts
3. Log in to the system
4. Go to the restaurant menu
5. Select an item from the menu.
6. Add a project to the current order.
7. View their current order.
8. Delete item / delete all items from the current order.
9. Provide payment details.
10. Place an order.
11. Receive confirmation in order form.
12. View the order

4. Menu management system module
The module provides a powerful user with only the functionality
of the administrator. No other users of the system (such as
restaurant employees or customers) are not available.
Using the graphical interface, it will allow the administrator to
manage the menu that is displayed to users of the Web
subscription system:
1. Add / update / delete food categories from the menu.
2. Add / update / delete food from the menu.
3. Update the price of the given food.
4. Update the additional information (description, photo, etc.)
of the given food

5. Order Retrieval System Module
This is the simplest module in all three modules. Its design is
only used by restaurant staff and offers the following features:
1. Retrieve a new order from the database.
2. Display the order in an easy-to-read, graphical way.
Restaurant staff offers the following features:
•Log in system
•View pending orders
•Mark the order status as delivered or delivered
•Cancel order
3.2 Non-functional Requirements
The subcategories of non-functional requirements given are
security and performance requirements.
Security
The identified non-functional security requirements include:
• All data transmitted over the network will be encrypted using
openSSl.
• All employees can only log in to one device at a time
• The password strength for all users will be performed during
account creation.
Performance requirements

6. The server can support at least 200 connections at the same
time.
The server can support any number of activities, in any case
will not lose the meal / order and any payment will not be lost
3.3 software and hardware requirements
Supported hardware platforms
For initial development of Take-out management system only a
single computer is required. The recommended minimum system
should have 3GHz processor, 4GB RAM, and disk space as
required. For a typical, full deployment of take-out management
system, the minimum hardware environment should have:
· Web application server - 3 GHz processor, 4GB RAM, 30GB
disk
· Database server -3 GHz processor, 4GB RAM, 100 GB RAID
4 + disk
· File-server - 2 GHz processor, 512 MB RAM, RAID 5 storage
with appropriate disk space
· Application cluster - Application-dependent sizing
Prerequisite Software Requirements
The following software applications must be available on the
planned hardware environment before installing the take-out
management system. The applications are:
· Browser (one required, client-side)
· Web application server (one required, server-side)
· Relational Database (one required, server-side)
· File vault server (one required, server-side)
Server-side Software Requirements
· Web Application Server (1 required) - Apache Tomcat

7. · Relational Database Server (1 required) - MariaDB database
server
Client side software requirements
The client side the following software to be to access the
system:
· A web browser – Firefox version 41 and above, Microsoft
internet explorer version 11 and above or Chrome.
Java Web Start (Standard Edition) version 1.4.2 - 1.5.0
UML DESIGNUse CasesIn order to facilitate a clear and clear
view of how end users interact with the system, actors (end
users), use case diagrams, and detailed use cases are described
for use cases. Find the use cases that are used to log in, log out,
add menu items, update menu items, delete menu items, add
employees, delete employees, place orders, process payments,
accept orders, and deliver items. Actors
There are three actors in system including the admin, restaurant
employee/waiter and customer. The Admin is a super actor and
can access virtually everything in the system
4.1 Use Case Diagram
Pic 4-1 show the use case diagram for the take-out ordering
system.
Login
Log out
Place order
Add menu item
Update menu
Add employee
Remove employee
Process payment
Cancel order

8. Deliver order
View order
Administrator
customer
Waiter/restaurant employee
Take-out ordering management system
Pic. 4-1 Use case diagram
4.2 Use case descriptionsLogin use case is shown in the figure
below
Use Case
Log In
Primary Actor
Customer
Goal In Context
Enable a consumer access to the system for order placement
Preconditions
The consumer has a valid username and password and is not
already logged in
Trigger
The customer requires access to the system to perform their
action
Scenario

9. 1) The customer selects ‘Log In’ from the menu
2) The system prompts the user for their username and password
3) The user enters their username and password
4) The device enables access to the system according to access
control
Exceptions
The user enters an invalid username or password
log out use case
Use Case
Log out
Primary Actor
Customer
Goal in Context
Disable user access to the system
Preconditions
The user is already logged in
Trigger
The user no longer requires access to the system.
Scenario
1) The user selects ‘Log Out’ from the menu
2) The device disables access to the system
Exceptions
The user enters an invalid username or password
Place order use case
Use Case
Place order
Primary Actor
Customer
Goal in Context
Allow user to place meal order
Preconditions
The user is already logged in
Trigger
The user wants to place an order of the selected meals

10. Scenario
1) The user selects all the desired meals from the menu
2) The customer selects check out button.
3) The customer confirms the order and selects payment mode
4) The systems confirm a valid payment mode.
5) A confirmation message is displayed
Exceptions
The user enters an invalid payment mode.
View order use case
Use Case
View order
Primary Actor
Restaurant employee
Goal in Context
View consumer orders
Preconditions
The user is already logged in
Trigger
Restaurant employee need to check the placed orders
Scenario
1) The user selects orders from the menu.
2) The device display a list of placed and pending orders.
Exceptions
No orders placed
Deliver order use case
Use Case
Deliver order
Primary Actor
Restaurant employee.
Goal in Context
Deliver a pending order.
Preconditions
The user is already logged and is the pending orders menu.
Trigger

11. The user requires to deliver certain orders.
Scenario
1) The user selects all the orders he or she wants to deliver.
2) The user clicks deliver button
3) The system changes the status of order into delivering and
alerts the customer.
Exceptions
No pending orders.
Cancel order use case
Use Case
Cancel order
Primary Actor
Restaurant employee
Goal in Context
The user want to cancel a certain pending order.
Preconditions
The user is already logged in and is in the pending order menu.
Trigger
The user wants to cancel an order that cannot be delivered due
to technical details.
Scenario
1) The user selects all the orders to be cancelled
2) The user clicks the cancel button.
3) the system prompts the user for a confirmation.
4) on clicking ok the system changes the status of the order to
cancelled and alerts the customer.
Exceptions
No pending orders.
Process Payment use case
Use Case
Process payment
Primary Actor
Restaurant employee
Goal in Context

12. Process payment for a delivered order.
Preconditions
The user is already logged in
Trigger
The user wants to process payment for a delivered order.
Scenario
1) The user selects process payment from the menu.
2) The device displays a list of the orders the specific user is
delivering.
3) the user selects all the orders he or she wants to process
payment for.
4) the user clicks process payment button.
5) the systems processes payments, displays a confirmation
message and sends a receipt to the customer.
Exceptions
Add Menu Item Use Case
Use Case
Add menu item
Primary Actor
administrator
Goal in Context
Add a new meal to the menu.
Preconditions
The user is already logged in
Trigger
The restaurant needs to include a new meal to the menu
Scenario
1) The user selects add menu item from the main menu.
2) The system displays a form where the user enters name of the
meal, category, description, images and price.
3) the user clicks add button and confirms the details.
4) the system updates the database and displays the meal on the
customer menu.
Exceptions

13. Update Menu item use case
Use Case
Update menu
Primary Actor
Administrator
Goal in Context
Change details of an item such as price of a meal.
Preconditions
The user is already logged in
Trigger
The user wants to update the menu.
Scenario
1) The user selects menu items from the main menu.
2) The system displays a list of all the items in the menu.
3) The user selects an item to update.
4) The system displays a form with details of the menu item in
editable fields.
5) The user edits the intended fields and clicks save button.
6) The system prompts the user to confirm the given details.
7) On confirmation, the system saves the changes in the
database, updates customer and displays a confirmation message
to administrator.
Exceptions
No menu item added.
Delete menu item use case
Use Case
Delete menu item
Primary Actor
Administrator
Goal in Context
Delete meals from the menu
Preconditions
The user is already logged in
Trigger

14. A certain is no longer available in the restaurant and the admin
wants to remove it from the menu.
Scenario
1) The user selects menu items from the main menu
2) The system displays a list of all the menu items.
3) The user marks all the meals to delete and clicks the Delete
button.
4) The system prompts for confirmation.
5) On confirmation, the system deletes the items from the
database, update the customer menu and displays a confirmation
message to the administrator.
Exceptions
No items in the menu.
Add employee use case
Use Case
Add Employee
Primary Actor
Administrator
Goal in Context
Create a new user in the system.
Preconditions
The user is already logged in
Trigger
The user wants to add a new employee to the system.
Scenario
1) The user selects Add employee form the main menu.
2) The system displays a form where administrator add the new
employee details
3) The user clicks add button.
4) the system displays a random password which the
administrator is supposed to take down and click ok.
5) the systems commit the changes to the database and displays
a confirmation message to the user.
Exceptions

15. Delete Employee use case
Use Case
Delete Employee
Primary Actor
Administrator
Goal in Context
Block an employee from accessing the system.
Preconditions
The user is already logged in
Trigger
The user wants to deactivate an employee in the system.
Scenario
1) The user selects delete employee from the main menu
2) The system display a list of all the employees.
3) The user selects the desired employee and clicks the delete
button.
4) The system prompts the user for a confirmation.
5) On confirmation, the system sets a flag to inactive in the
database and displays a confirmation message to the user.
Exceptions
No Employee in the system.
Domain Class Diagram
The following subsection presents descriptions for the classes
identified for the take-out ordering management system and
their relationships.

16. Admin class
This class represents the system administrator and all the
operation he or she can perform in the system. The functions
include View Food, Add Menu, Delete Food, Modify Menu, Add
employee, Delete Employee.
Products Class
This represent the individual dishes and their attributes include
name, category, and subcategory and unit price.
Guest Class
This class represent a individual who visit online order web
application for the first time. The individual can be able to view
menu as well as Signing Up.
Customer class
This class represent a consumer with an established account.
The class attributes include customer ID, name, address, phone
number and email. The class functions View Menu, Buy Food,
Add to Cart, Make Payment and Delete from cart.
Cart Class
This represent the cart with all the meals or dishes to be
ordered. The class attributes include order Id, number of items
in the cart, list of products and their unit place as well the total
price.
Restaurant Employee Class
This class represents the restaurant staff member. The class
attributes include: staff Id and name.
The class functions include view order, deliver order, process
payment and cancel order.
Payment Class
This class represent the payment. Its attributes include customer
Id, name, and card type and card no.

17. Sequence Diagram
Use Interface Design
This is the sample login interface,
This is the sample payment interface
DATABASE DESIGNi. Data Description
This subsection describes the data requirement for take-out
management system. The data will be organized into tables. The
tables with their description are shown below.Orders
Field name
Brief Description
Field type
Restriction
Order_no
Order number (KEY FIELD)
Integer (20)
0-999999
Order_time
Order time
Time
-----
Order_date

18. Order date
Date
-----
Payment_status
Status of payment
String
Orderline
Field name
Brief Description
Field type
Restriction
Order_no
Order number
Integer (20)
0-999999
Item_no
Item number
Integer (10)
0-999
Quantity
Quantity of the item
Integer (10)
0-99
Menu
Field name
Brief Description
Field type
Restriction
Item_no
Item number (KEY FIELD)
Integer (20)

19. 0-999
Item_price
Item price
Currency
$1-999
Item_name
The name of Item
String(20)
1-20char
Status
Status of the item
String(2)
BX, LX, DX, PX
Discount
Discount value
Percentage
0%-100%
Photo
Photo of the item
Object
-----
Description
Description of the item
String (40)
1-40 char
Employee
Field name
Brief Description
Field type
Restriction
Employee_no
Employee number (KEY FIELD)
Integer (10)
1-99
Name
Employee name

20. String (20)
1-20 char
Tel
Employee telephone number
Integer
8 digits
Address
Employee address
String (60)
1-60 char
Work_in_time
Start work time
Time
-----
Work_out_time
End work time
Time
-----
Day_off
Day off
Integer (10)
1-7
Salary
Salary of the employee
Currency
$1-99999
Email
Employee email address
String(100)
1-100 char
password
Employee login password
String(20)
1 – 20 char
Customers
Field name

21. Brief Description
Field type
Restriction
Customer_no
customer number (KEY FIELD)
Integer (10)
1-99
Name
customer name
String (20)
1-20 char
Tel
customer telephone
Char(20)
8 digits
Email
Customer email address
String(100)
1- 100 char
Address
customer address
String (60)
1-60 char
password
Login password
String(20)
1-20 char
Admin
Field name
Brief Description
Field type
Restriction
username
Admin username (KEY FIELD)
String (30)

22. 1-30 char
Password
Admin login password
String (20)
1-20 charii. Relational Schema
Order (Order_no, Table_no, Order_time, Order_date, Head_no,
Payment_status)
Orderline (Order_no, Item_no, quantity)
Menu (Item_no, Item_name, Item_price, Status, Discount,
Photo, Description)
Employee (Employee_no, Work_in_time, Work_out_time,
Employee_name, Tel, Address, Salary, Dayoff, email,
password)
Customer (customer_no, Work_in_time, Work_out_time,
customer_name, Tel, Address, email, password)
Admin (username, password)