Business system analysis
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
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
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
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
The subcategories of non-functional requirements given are security and performance requirements.
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.
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 platformsFor 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
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)
Web Application Server (1 required) - Apache Tomcat
Relational Database Server (1 required) - MariaDB database server
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
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
Pic 4-1 show the use case diagram for the take-out ordering system.
Pic. 4-1 Use case diagram
4.2 Use case descriptions Login 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 | 1) The customer selects ‘Log In’ from the menu |
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 |
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 |
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. |
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 |
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 | The user requires to deliver certain orders. |
Scenario | 1) The user selects all the orders he or she wants to deliver. 3) The system changes the status of order into delivering and alerts the customer. |
Exceptions | No pending orders. |
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. |
Use Case | Process payment |
Primary Actor | Restaurant employee |
Goal in Context | 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 |
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. 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 |
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. 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. |
Use Case | Delete menu item |
Primary Actor | Administrator |
Goal in Context | Delete meals from the menu |
Preconditions | The user is already logged in |
Trigger | 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. |
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 |
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. |
The following subsection presents descriptions for the classes identified for the take-out ordering management system and their relationships.
Admin classThis 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 ClassThis represent the individual dishes and their attributes include name, category, and subcategory and unit price.
Guest ClassThis 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 classThis 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 ClassThis 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 ClassThis 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 ClassThis class represent the payment. Its attributes include customer Id, name, and card type and card no.
Sequence Diagram
This is the sample login interface,
This is the sample payment interface
DATABASE DESIGN
- 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 | Order date | Date | ----- |
Payment_status | Status of payment | String | |
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 |
Field name | Brief Description | Field type | Restriction |
Item_no | Item number (KEY FIELD) | Integer (20) | 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 |
Field name | Brief Description | Field type | Restriction |
Employee_no | Employee number (KEY FIELD) | Integer (10) | 1-99 |
Name | Employee name | 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 |
| Employee email address | String(100) | 1-100 char |
password | Employee login password | String(20) | 1 – 20 char |
Field name | 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 |
| Customer email address | String(100) | 1- 100 char |
Address | customer address | String (60) | 1-60 char |
password | Login password | String(20) | 1-20 char |
Field name | Brief Description | Field type | Restriction |
username | Admin username (KEY FIELD) | String (30) | 1-30 char |
Password | Admin login password | String (20) |
|
- 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)