This project computerizes restaurant operation so that all information pertaining to patron's orders and staff activity will be conveniently shared and stored over the restaurant's intranet. Hosts will be able to view table status with a click of a button. The wait staff will be able to enter the patron's orders quickly and efficiently and then have it electronically delivered to the kitchen. The kitchen staff will be able to view the incoming orders and notify the proper wait staff when the food is ready. Bus boys will be able to view real-time floor status allowing them to know which tables are clean, dirty, or occupied. Most importantly, all of the restaurant information is organized and saved in the system database for the management viewing and archival. The analysis will consist of by-the-day and by- the-hour breakdowns of: Revenue and revenue percentage per menu item Waterwes order on carbon paper Notification When the order is ready, the kitchen starings the call Order queue Kitchen gets a copy, and returns ith the food Archiving When the customer pays, the tab can be kept for record-keeping Figure 1: Ok-fashioned restaurant operation. Menu item popularity Personnel efficiency Average turnaround time (how long patrons spend in the restaurant) Average preparation time (time from when the order is placed to when it is ready) There is no more abundance of papers and long hours of punching numbers. All data is automatically collected and processed allowing management to focus on analyzing the data rather than calculating it. By using a touch screen the restaurant staff can quickly and efficiently log in and complete the desired task. When a waiter logs in, they are greeted with a floor status screen in which their assigned tables are colored in. Their tables are colored according to status, green is open, yellow is occupied, red is dirty (see Figure 2). At this point a waiter can select a table to view its tab. Once a table is selected, the staff can choose from a number they select to add an item to the table's tab, they are presented with various categories of food items offered. Here they can select the appropriate category and then find the desired item. For example, if a patron ordered a Caesar salad, the waiter would login, select the table, and choose "Add Item." They would then select the "Soups/Salads" from the category list, and then select the desired salad from the items presented. They are then returned to that table's screen where they can choose to perform another task or logout. This saves the waiter from walking back and forth to the kitchen to deliver and check up on food orders. Orders placed by wait staff using the computer terminals on the restaurant floor are displayed to the kitchen staff through a queue, i.e., on a first-in, first-out basis. The supported employee roles are: Host, Waiter, Cook, Busboy, and Manager. Some of the direct links between some of the staff include: Host Waiter, Waiter Cook, and Busboy Host. Every user account in the system should have its own privileges. All the role- personalized home screens for each employee will be refreshed automatically when needed (when a table is marked ready, a table's order is prepared; a host assigns a waiter to a table; etc.). The Manager should have administrative power over employee profiles: the ability to create and modify profiles, track employee activities, and authorize restricted waiter activities. If the employee is a waiter, his/her profile also contains information about the bles for which he/she is responsible. From this profile, the individual tabs for those tables can be accessed. The manager should also have ability to manage other aspects of restaurant operations, such as inventory tracking and sale analysis. Waiter places order at a computer on the restaurant floor 10 Order queue Kitchen sta Views orders on a computer in the kitchen Notification When the order is ready, the water will be notified the next time he logs in Archiving Record-keeping is done by the server Figure 2: Restaurant automation facilitates staff coordination and record keeping There is an important choice of the type of computer terminals used by the waiters. All other personnel are either stationary, e.g., kitchen staff and hosts, or can access information at stationary terminals, e.g., busboys. If the waiters are required to use stationary terminals, they must memorize or jot down a specific table's order and then find an open computer, login and enter the information into the system. At this point everything else is done electronically. Another option is to have the waiters provided with handheld devices, which will be connected wirelessly to the rest of the system, completely eliminating the use of carbon paper. There are certain advantages of stationary computer terminals over handheld devices: (i) a small number of fixed terminals can be time-shared by multiple personnel, so this solution may be cheaper and easier to maintain; (ii) they are fixed, so they cannot be lost or damaged in handling. Thus, in the first instantiation we will assume fixed terminals for the entire staff Throughout the restaurant there will be computer terminals for the staff to login. The system requires each user to login, complete their task and logout. Because this will require frequent logins and logouts, it may appear as an unnecessary overhead. With a limited number of terminals, staff will not be able to remain logged in because other employees need to use the computers. Logging in and out events can be exploited to trigger data updates and reorganization, as well as for delivering user-specific notifications of environment changes, such as to announce that the food is done or that a table needs to be cleaned. The only users who will be constantly logged in are the kitchen staff and the host. They will be the only people using those terminals and therefore will not require frequent logouts. Another design issue is that of how users identify themselves with the system. The considerable options are a touch screen, a card reader, or a typical keyboard. A touch screen allows users to carry less and use the system quickly and efficiently, although they need to memorize their login information. Another option is swipe cards, which would work by having the management assign each employee a swipe card. To make this system useful, a ard reader would be needed to accompany every computer station, as illustrated in Figure 2. To make new cards for employees, the management would also need a card writer, as well as blank, non-programmed cards. The staff at many restaurants is constantly changing and this ongoing employee turnaround may lead to a considerable waste in time and money for making new cards. Our final option is to use a typical keyboard system. This would work the same as a touch screen but a keyboard would take up more space and be potentially slower. A touch screen serves the same purpose as a keyboard and allows for a smaller computer station. This is selected as the working solution. Having to login frequently is annoying, particularly for cooks working with food. If you decide to have open access, then you may argue that certain restaurant areas are physically secure, so electronic security is less of a concern. The final interface issue is specifying the floor plan of the restaurant and the table arrangement. Ideally, this feature should be included with the system to allow managers to alter the floor plan by moving, adding and removing tables. If the development team experiences lack of time in the course of the semester, an acceptable workaround should be sought. For example, a generic restaurant floor plan can be designed specifically for demo purposes. When a restaurant orders our software we will build and develop a floor plan for that specific establishment, making the software package unique to that establishment. In addition to staff coordination, the system tracks everything electronically then organizes it. Employee hours are kept, allowing for rapid processing of the payroll. Revenue is tracked by day, week, or month. All this information is collected, saved, and then entered into table format for easy reading by the management. The automatically generated statistics allow the management to see what portion of the revenue comes from what item, i.e., what are the most popular items. All this is done automatically and stays up to date with restaurant performance. The developer(s) should count the number of clicks/keystrokes that are necessary to accomplish individual tasks. Make every effort to reduce the number of clicks/keystrokes in the system interaction, while not compromising functionality and security. a. Identify the actors for the system and their goals [6 marks) b. List and describe eight (8) functional requirements for the system-to-be. [8 marks) c. List and describe four (4) non-functional requirements for the system-to-be. [4 marks) Note: The non-functional requirements may not be explicitly mentioned in the description given however, consider the medical problem domain in deriving these requirements. [10 marks) d. Derive the basic use cases for the restaurant automation system. [17 marks] e. Draw the use case diagram [25 marks)