Restaurant Automation Software Requirements Specification

Purpose goal for this reject is to introduce automation in privately-owned restaurants, that is, small- to medium-sized establishments. Typical problems restaurant personnel are facing include: ; Coordination of their work activities ; Anticipating and handling periods of low/high patron traffic ; Recognizing trends early enough to take advantage of bestsellers or abandon the flops ; Lowering operating costs, and increasing efficiency/productivity and profits Scope aim of this project is to develop a software system that would eliminate the need of traditional pen/paper approach for privately- owned restaurants.

The project s focused on making the restaurant fully automated such that it is easier to co- ordinate various work activities that go on inside a typical restaurant.

The main features of the project include: Organizing a database for a medium sized restaurant Coordinating work activities of the various actors – Host, Waiter, Cook, Busboy and Manager Increase efficiency by minimizing time between an order is placed and the billing Increase profits by reducing operating costs and increasing revenues by increasing efficiency Archiving information of the workers and hours worked Definitions, Acronyms, and Overcompensation’s – Manages inventory, payroll, employee list and charts and statistics for the restaurant Host – Assigns and seats people who come to the restaurant Waiter – Takes the order from the customer onto a PDA and delivers the order to the customer Cook – Reads the order placed from a terminal in the kitchen and cooks food accordingly.

Also the cook informs the waiter when the order is ready. Busboy – Keeps track of the dirty tables and updates status when he/she is done cleaning Add/Edit Employee – Button on the Management page to add or edit the information of an employee at the restaurant such as employee identification number, their password, employee type and their wages.

Get quality help now

KarrieWrites

Verified

Proficient in: Internet

5 (339)

“ KarrieWrites did such a phenomenal job on this assignment! He completed it prior to its deadline and was thorough and informative. ”

+84 relevant experts are online

Hire writer

Manage Inventory – Button on the Management page of all the items required for food preparation in the restaurant Manage Payroll – Button on the Management page to manage the payrolls of the various employees in the restaurant Reports Screen – statistical data analysis of the traffic flow in the restaurant Grid – GUI layout of the tables in the restaurant Efficiency analysis – Performance measure of all waiters in the restaurant Overviews restaurants today still use the same basic methods from years ago to handle orders from customers. Often times this leads to complicated coordination of activities between chefs and waiters. This also means that other tedious tasks, such as inventory checks, fall to the managers to perform. This project seeks to introduce associated with current restaurant management practices. Overall Description propose a software solution to the above problems which would allow the restaurant management to be easier and offer more coordination for the everyday work. A touch screen will be used by the staff to log in and complete the desired task.

The supported employee roles are: Host, Waiter, Cook, Busboy and Manager. The various employees have user accounts and login using their passwords they need to member except the cook. Logging in and out will be exploited as triggering events to update and organize the data. When a person enters the restaurant the host will greet the customer and log in to see the tables that are free. The host can also show the floor status to the customer for their preference (e. G. If the customer prefers a free table near the window etc. ). After being seated the assigned waiter for that particular table takes over from the host and takes the order from the customer on a PDA.

The order is seen by the cooks in the kitchen who can right away start preparing the order. After the customer is done eating they are billed and the order is archived in the database for calculation of the restaurant revenues for that day/month/year. This also allows preparing easy statistics regarding high patron service hours etc. The Busboy who checks the table status can then take care of the dirty table and after he is done cleaning can mark them as ready to use in the system. The manager has administrative power over employee profiles. They can do the following: 1. The ability to create and modify profiles 2. Track employee activities 3. Authorize restricted waiter activities.

We will take into account the number of clicks that are necessary to accomplish the individual tasks and try to minimize the number of clicks for efficient deployment of our system. Product perspectives system will consist of two parts: one mobile application and one web portal. The mobile application will be used to view table status, enter customers’ orders, view orders information and status. The web portal will be used for managing restaurant information, staff information, and data analysis. Since this is a data-centric product it will need somewhere to store the data. For that, a database will be used. Both the mobile application and the web portal will communicate with the database.

Both the mobile application and the web portal will be able to get, add and modify data in the database. All of the database communication will go over a LANA. Product functionalist the mobile application, the user will be able to modify personal information, add orders, view or modify orders and table status and information, depending on the user’s position in the restaurant: Hosts and bus boys will be able to view and update table status. Table status will be displayed in a map of the restaurant’s floors, based on their real location in the assistant. Table status can also be modified on this map. There will 3 table statuses: Ready, Occupied and Dirty. Waiters will be able to add and modify orders.

The menu’s items will be displayed in a list view, with a check box, a quantity field and a note field on each of the item. When the waiter press the “Create Order” button, the order will be created and submitted to the database. Waiters can also edit and cancel orders upon customers’ requests. After customers finished the food, waiters can also generate bills base on the orders. Chefs will be able to view incoming orders and modify order status. Orders will be display in a list, which is sorted base on the time of the orders. The orders will also be grouped base on their items for easy preparation. After the order is completed, the chefs will have to update the order status, and a notification will be sent to the waiters.

The web portal will provide functionality to manage the system, the restaurant data, and staff information. The web portal will also provide a variety of report generating tools. The report’s analysis will consist of by-the-day and by-the-hour breakdowns of: ; Revenue and revenue percentage per menu item ; Menu item popularity ; Personnel efficiency Average turnaround time ; Average preparation time User characteristically are two types of users that interact with the system: users of the mobile application and the system administrators. All mobile application users can use the application to modify personal information. Users are also able to view, add or modify orders and table status depending on their position at the restaurant.

Users can also retrieve lost password through email. The administrators will not use the mobile application but the web portal instead. There they will manage the information about the restaurant such as menus, table maps and employees’ accounts. The web portal will also provide administrators with report generating tools for management purpose. Constraints LANA connection is a constraint for the mobile application. Since the application fetches and modifies data from the database over the LANA, it is crucial that there is a stable LANA connection for the application to function. Both the web portal and the mobile application will be constrained by the capacity of the database.

Since the database is shared between both applications, it may be forced to queue incoming requests and therefore increase the time it takes to fetch data. FUNCTIONAL Requirements The actors# Main functions Waiter Kitchen Staff Host Bus Boy Manager 1 View Menu Food (View , Update) x xx 2 Odder Food (View , Update) x X 3 List table(View ,update) x xx 4 Invoices xx 5 Report X 6 Create update User X 7 Shift (Create , update) X 8 View Shift xx The use systematic Functions Main Use Cases Use Case # Login This is Authentication User. When is use Application. LO_I . 1 View Status Table We have seen status table. (Find Table is blank). SST_I . 1 Update Status Table Change Status Table. (Table have got Guest). SST_I . Create Order Food Create are List Order Food. OF 1. 1 Update Status Order Food Change Status Order Food When chef cooked. OF_I . 2 Create Bills The Payment request. CB_I . 1 View Bill View is total payment. CB_I . 2 Daily report Report is payment, food etc. DRY_I . 1 Add employee Manager add employee into database ICC_II Update employee Manager update employee into database US_02 Delete employee Manager delete employee in database US_03 Add menu Manager add food into menu in database US_04 Update menu Manager update food into menu in database US_05 Delete menu Manager delete food in database US_06 View report Manager view report CO_07 Use Cases Diagram

Functional Requirement one user case ID US 1 Name Add employee Goal Want to add a employee Actors Manager Pre-conditions User must log in with role “Manager” Post-conditions Main Flow 1 . Add a employee. 3. Enter employee information: Name, age… 2. Display add a employee form and request to enter skill employee information. 4. Validate employee information. Display “Complete! ” message. Exception IA: if role is not correct, show error message and ask to log in again. AAA: if skill category information is not correct, show error message and ask to input again. Open Issues user case ID US 2 Name Update employee Goal Want to update a employee Post-conditions Main Flow 1. Update a employee. 3. Enter employee information: Name, age…. 2.

Display update a employee form and request to enter employee information. 4. User case ID US 3 Name Delete employee Goal Want to delete a employee Post-conditions Main Flow 1 . Choose employee. 2. Display “Success! ” message. Exception IA: if role is not correct, show error message and ask to log in again. AAA: if skill category information is not correct, show error message and ask to input again. Open Issues N/A user case ID US 4 Name Add menu Goal Want to add menu Post-conditions Main Flow 1 . Add menu. 3. Enter food information: Name, money…. 2. Display add menu form and request to enter food information. 4. Validate menu information. Display “Complete! Message. Exception IA: if role is not correct, show error message and ask to log in again. AAA: if skill category information is not correct, show error message and ask to input again. Open Issues N/A user case ID US 5 Name Update menu Goal Want to update menu Post-conditions Main Flow 1. Update menu. 3. Enter employee information: Name, money…. 2. Display update menu form and request to enter food information. 4. Validate employee information. Display “Complete! ” message. Exception IA: if role is not correct, show error message and ask to log in again. AAA: if skill category information is not correct, show error message and ask to input again.

Open Issues N/A user case ID US 6 Name Delete menu Goal Want to delete menu Post-conditions Main Flow 1 . Choose food. 2. Display “Success! ” message. User case ID US 7 Name View Report Goal Want to view report Post-conditions Main Flow 1 . View report. 2. View report user case ID SST 1. 2 Name Change status table Goal Want to change status table Actors Host, waiter, bus boy Post-conditions Main Flow Change status table. Host change to empty from people +Waiter change to people from clear *Bus boy change to clear from empty Notify message + host send message for waiter+waiter send message for bus boy + bus boy send message for host user case ID SST 1. 1 Name View status table Post-conditions Main Flow View status table. User case ID OF 1. Name Create order Goal Want to create order Actors waiter-conditions User must log in with role “waiter” Post-conditions Main Flow 1 . Create order 3. Enter number 2. Display create order form and choose food 4. Send information for chef. Display “Complete! ” message. Exception IA: if role is not seer case ID OF 1. 2 Name Modify order Goal Want to modify order Actors Waiter-conditions User must log in with role “waiter” Post-conditions Main Flow 1 . Modify order 3. Enter order information: number 2. Display modify order form and request to enter update order information. 4. Send information for chef. Display “Complete! ” message. Exception IA: if role is not correct, show error message and ask to log in again. A: if skill category information is not correct, show error message and ask to input again. Open Issues N/A user case ID CB 1. 1 Name Create bill Goal Want to create bill Actors Cashier Pre-conditions User must log in with role “Cashier” Post-conditions Main Flow 1. Create bill 2. Display bill and send for waterproofing IA: if role is not correct, show error message and ask to log in again. AAA: if skill category information is not correct, show error message and ask to input again. Open Issues N/A Name View and Update Food. Goal Want to view and update food Actors Chef Pre-conditions User must log in with role “chef” Post-conditions Main Flow 1 . U food 2. Chef choose food and change status food. Display “Complete! “.

Send message for waterproofing IA: if role is not correct, 3. 4 <Database Diagram> . 5<Sequence Diagram> 3. 5. 1 View table status View table status 3. 5. 2: Login 3. 5. 3: Manage Order 3. 5. 4: Manage Payment 3. 5. 5: Manage Table 3. 6<Class Diagram> NON-FUNCTIONAL Requirements The menu (Android Interface) should contain text and graphics that describe each item to an average customer. Usability The system’s user interface will be very simple and self-explanatory. The manager and the cook will interact with the system through touch-screen LCD. They are very easy to adapt to and use. The users Just have to touch the option they want. The waiters will interact with Pads.

They will each be able to access the tables that they are responsible for. The menus for the restaurant will show up as drop-down menus on the Pads. The waiters only have to select the item that the customer ordered from the drop-down list. Reliability The system is guaranteed to be reliable. All inputs to the system will be selections from options that the system will show on the screen. Since the system will only provide valid options, there is absolutely no possibility that invalid inputs can be entered. Each user will have a unique surname and password. Dichotomies the risk of unauthorized access to the system. Also, users can only access parts of the system that they require for their Job.

For example, a waiter cannot access the inventory management or the payroll feature of the system. Those parts among a few otherness only be accessed by the manager. All these constraints will ensure the reliability of the system. Performance product shall be based on web and has to be run from a web server. The product shall take initial load time depending on internet connection strength which also depends on the media from which the product is run. The performance shall depend upon hardware components of the client/customer. Supportability system will support changes that the restaurant might need to make in future. The manager will have the ability to modify items from the menu.

He will also be able to add or delete users to the system for layoffs, retirements or new hires Design Constraints-line User Documentation and Help System Argumentativeness’s Counterintelligence’s section provides a detailed description of user, hardware, software and communication interfaces of the “Restaurant Automation” software system. User Interfaces Mobile application user should be able to see the login page when he/she opens the application. After the user logged in, he/she will be taken to the main screen of the application. The application main screen will differ base on the user position in the restaurant: Host and Bus Boy: the main screen will consist of a table map of the restaurant. The user can navigate between different table map in each floor of the restaurant by swiping the screen left or right.