Restaurant Management System
Third Year Project Report
BSc. Computer Science and Mathematics
School of Computer Science
University of Manchester
Author: Supervisor:
Carl Abernethy Prof. Chris Taylor
5th May 2010
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community
Ask the community for help and clear up your study doubts
University Rankings
Discover the best universities in your country according to Docsity users
Free resources
Our save-the-student-ebooks!
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Restaurant Management System, Schemes and Mind Maps of Computer Science
The design and implementation of a restaurant management system, including the development of various graphical user interfaces (guis) for order entry, kitchen management, and administrative tasks. It covers the use of a relational database management system (rdbms) for data storage, the design of the entity relationship model, and the implementation of specific features such as synchronized gui, ingredient choices, and cooking preferences. The document also discusses the testing techniques used to ensure the system's functionality, including unit testing and integration testing. Overall, the document provides a comprehensive overview of the development process for a restaurant management system, covering requirements gathering, design, implementation, and testing.
Typology: Schemes and Mind Maps
2022/2023
1 / 84
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Restaurant Management System and more Schemes and Mind Maps Computer Science in PDF only on Docsity!
Restaurant Management System
Third Year Project Report
BSc. Computer Science and Mathematics
School of Computer Science
University of Manchester
Author: Supervisor:
Carl Abernethy Prof. Chris Taylor
5th May 2010
Restaurant Management System
Carl Abernethy
Supervised by Prof. Chris Taylor
5th May 2010
Abstract
This report documents the process of designing, developing and testing a software system to be used in a restaurant; usually given the name restaurant management system. The restaurant management system is there to help communication between all teams within a restaurant by minimising the probability of human errors. This report was written by Carl Abernethy as part of his 3rd year project and was published on May 5, 2010.
Contents
Chapter 1
Introduction
1.1 Chapter Overview
This chapter gives an introduction to the project by defining the problems encountered by restaurants, the main objectives that the system expects to achieve and a brief introduction to existing solutions.
1.2 The Problem
According to a research article written by Horizons [7], in 2006 within the UK there was just over 26, restaurants with 734 million meals served that year. As this restaurant sector was worth £7.61 billion, any restaurant generating a good business reputation could lead to the making of a very successful and profitable business. The problem for many businesses is to ensure that they not only attract new customers but to ensure they maintain their existing clientele. It has been argued many times that an existing customer is worth more to a business than a new customer as the cost to attract a new customer can be up to five times the cost to retain an old customer. An online article by Paul Lemberg [9], discusses the pros and cons of this argument. Within the restaurant sector, a customer is likely to return to the restaurant in the future if they received an excellent customer service as well as appetising food. However, if they had to wait for an unreasonable amount of time or there was a mistake in the order, it’s very unlikely the customer would return. Therefore a solution to this problem would be to minimise mistakes within the order and bill, and help eradicate delays as well as encouraging team work and communication within the team. The next section will go into the objectives of the proposed solution.
1.3 Project Objective
The objective of this project is to build an electronic restaurant management system using all of the skills and techniques from the field ensuring that no common development mistakes are reproduced. Project management is critical to all software engineering projects and keeping to a project plan will be of similar importance. One of the main objectives of any business is to maximize profit by increasing efficiency and de- creasing overheads^1 without compromising customer satisfaction. Currently, many restaurants use a paper-based system to communicate between the restaurant and kitchen which can be shown to be one
(^1) Ongoing expense of operating a business also known as operating costs.
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 1. Introduction
of the least efficient approaches. Even though this approach is implemented in successful profitable restaurants, there are several problems which could be seen as reducing the restaurant’s efficiency:
- Miscommunication caused by handwriting.
- Unmanageable order logging.
- Inefficient restaurant-kitchen communication.
- Difficult order tracking and time management.
- Difficult stock management.
- Limited statistical output.
By introducing an electronic restaurant management system these problems can be avoided or improved leading to an increase in profits. The initial project plan drafted at the beginning of the project can be found in Appendix A.
1.4 Existing Solutions
There are many computerised restaurant management systems available but for each system there exist disadvantages or missing features. The most common type of restaurant management system contains a static order entry computer system usually in the shape of a desktop computer with a touch screen. Typically this common approach is adequate to the restaurants requirements but still requires handwritten orders to be relayed to the order entry computer system. A table comparing features of existing solutions will be presented in Section 2.3. A slightly different approach was implemented in a restaurant in Nuremberg, Germany, named s Baggers [16]. The restaurant utilises a roller coaster approach to serving the food and an order entry system fully operated by the customer. As reviewed by the BBC [15], there is no need for any waiters as the customers use touch-screen monitors to browse the menu. This new invention can save on operating costs, but the initial injection of cash required is substantial as every table requires the necessary hardware. The next section will introduce the project proposal listing the proposed features of the system.
1.5 Project Proposal
The aim of this project is to create a restaurant management system that can incorporate the benefits of all the existing solutions but without any of the drawbacks as well as including many new features. A list of proposed features can be found in table 1.1. Many of the existing solutions to POS (Point-of-Sale) systems are sold with the required expensive hardware so for any business looking to work to a budget, the more enriched software solutions are just out of their range.
(^2) An order that has been taken but not yet paid for.
7 Carl Abernethy
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 1. Introduction
Table 1.2: A table showing the commonly used words throughout this report. Word Definition Ingredient Ingredient of a meal. Prepared ingredient Collection of ingredients. Item A meal or drink. Menu section A section of menu for example starters, meats, puddings etc. Suborder A collection of customer ordered items. Order A set of suborders.
1.8 Closing Remarks
This chapter has introduced the foundations of the project. The next chapter gives some background investigation into the problem.
9 Carl Abernethy
Chapter 2
Background
2.1 Chapter Overview
This chapter gives an insight to Point of Sale (POS) systems similar in nature to that of the one being developed in this project. It also gives a brief introduction to the importance of requirement gathering, a discussion on the development methodologies available as well as a justification on the platform and software used in this project.
2.2 Point-of-Sale (POS) Systems
According to A. Nutt [12], POS systems first dated back to the 1870s, when James Ritty became frustrated with dishonest employees stealing money from the customers in a saloon in Dayton, Ohio. With the inspiration from a counter on a ship’s propeller that counted the number of revolutions, he and his brother in 1879 developed the first cash register called ‘Ritty’s Incorruptible Cashier’. By the 1970s, the first computerised cash register was developed that was basically a mainframe but packaged as a store controller that had the ability to control the registers. Then in the 1980’s, cash registers began to be PC operated which meant that many of the basic PC functions were now available. Today, the POS systems are much faster, safer and reliable and with the introduction of credit cards and direct communication to the credit card company, transactions are almost instant.
2.3 Existing Point-of-Sale (POS) Systems
Table 2.1: Comparison of existing POS system solutions. POS Table Stock General Advanced Kitchen PDA Order System Service Control Reporting Discounts Display Input Point of Success [13] X ✗ X ✗ ✗ ✗ (Standard) RPS (HOSPOS) [18] ✗ X X ✗ X ✗ Abacre POS [14] X ✗ X X X ✗ eZee Burrp [2] X X X ✗ X X
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 2. Background
Figure 2.1: UML class model.
Figure 2.2: Boehm’s cost model [11].
12 Carl Abernethy
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 2. Background
when the project has a strict deadline to work to. Roughly a £ 1 cost of change in the requirement gathering can cost up to £ 100 in the testing stage and £ 1000 in the deployment stage to fix.
2.8 Development Methodology
A software development methodology is a framework used to plan the design of a software system controlling the process of development. According to Geoffrey Elliott [5], software development meth- odologies first emerged in the 1960’s with systems development life cycles (SDLC) being considered the first formalised methodology. Since then there have been numerous popular software development approaches including the waterfall model, prototyping, incremental, spiral and agile. The agile methodology refers to a collection of different agile methods. This project will be based on Extreme programming (XP) which is one of these agile methodologies using an iterative based framework. Each iteration has a development cycle very similar to the waterfall model consisting of planning, requirements analysis, design, development and testing. At each iteration, the business representative sometimes referred to as the ‘customer’ is given a demonstration to promote useful feedback. This type of methodology reduces risk and lets the project adapt to requested changes quickly with minimum cost. According to the Agile Manifesto [10], some of the main principles behind the agile methodology are:
- Customer satisfaction by rapid, continuous delivery of useful software.
- Working software that is delivered frequently.
- A welcomed late change in requirements.
- Simplicity.
- Regular adaptation to changing circumstances.
Given these principles and the nature of the project, extreme programming was the best choice methodology to use as we expected frequent customer communication and constant requirement changes post customer feedback. Therefore for this project, the supervisor acted as the customer regularly reviewing the work. Any errors or unthoughtful designs were then picked up and fixed relatively early in the process helping to minimise costly errors as shown in Boehm’s cost model (Figure 2.2).
2.9 Chapter Summary
This chapter has given examples of POS systems that are directly related to this project as well as general information about requirement gathering and development methodologies. The next chapter starts the process of the development methodology by generating the requirements of the system.
13 Carl Abernethy
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 3. Requirement Analysis
Table 3.1: A table showing the stakeholders of the project. Stakeholder Role Carl Abernethy Project developer. Prof. Chris Taylor Project supervisor. Management User of the management application. Waiters User of the restaurant application. Kitchen Staff User of the kitchen application. Bar Staff User of the restaurant application. Customer Indirect user of the system. Cashier External stakeholder; accepts payment.
Figure 3.1 shows several use case scenarios of the system that convey how the stakeholders interact with the features to achieve a business requirement. The use case scenarios from figure 3.1 can be found in Appendix B. The use case diagram is designed to be sequential so by following the use cases down the spine, one can follow the major steps of an order and several post features to query the data.
3.4 Features
An important part of requirements gathering is the production of a list of system features that cat- egorises on priority.
Table 3.2: A table showing the proposed system features and allocated priorities. Feature Priority Communication of data between each application. 1 Minimum click touch screen GUI design for efficient ordering. 1 Meal ingredient and cooking preference options. 1 Interface to view active orders in the kitchen. 1 Ability to add flexible discounts; calculating best price for the customer. 1 Interface to maintain and manage the menus and associated meals. 1 Stock control for all ingredients; reducing/increasing stock automatically. 1 Ability to define groups of ingredients that may be used in numerous meals. 2 Flexible meal grid design to fit any screen size. 2 Real time waiter status alerts. 2 User login functionality. 3 Interface for table management and selection. 3 Figure generation; management can view statistics in numerous forms. 3 Automatic daily stock level alerts. 3 Ability to define meals by images as well as text. 3
3.5 Measureable Goals and Requirements
The measurable goals and requirements of the system are a list of manageable^1 requirements and goals for each application that can be prioritised and ‘ticked off’. The software requirements specification
(^1) Requirements that are realistic and can be completed within the allocated time.
15 Carl Abernethy
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 3. Requirement Analysis
Manager
Waiter
Customer
Bar Staff
Chef
Order Food/Drink
Cook Food
Serve Food/Drink
Eat Food
Pay
Generate Reports
Check/Deduct Stock
<
Login
Place Order
Receive Order Confirm Order
Pay for Meal
Cashier
Accept Payment
Book Table
Check Offers
<
Call Server
<
Staff^ Collect Order
Manage menu & ingredients
Prepare Drink
<
Order Stock
Update Stock Levels
Stock Check
<
<
Restaurant Management System
Figure 3.1: Use case diagram showing some of the major features within the restaurant management system.
16 Carl Abernethy
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 3. Requirement Analysis
Table 3.5: Order application functional requirements. Requirements Priority Ability to view the active suborder details. 2 Ability to add a new order to a table. 1 Ability to add a new order without defining a table. 1 Ability to add a suborder to an existing order. 1 Ability to delete a suborder that has not yet been confirmed within the order system. 1 Ability to view optional ingredients in a meal. 1 Ability to view cooking preferences of ingredients that can be cooked different ways. 1 Ability to only view the active^4 menus. 1 Ability to view the status of all active suborders. 2 Ability to print customer receipts on order completion. 3 Ability to view transaction list of current order. 3 Ability to alert the waiter when the drinks are complete. 3 Ability to delete an item or clear the transaction list. 2
3.5.2 Non-Functional Requirements
Non-functional requirements are usually some form of constraint or restriction that must be considered when designing the solution. The non-functional requirements of the kitchen, management and order application can be found in tables 3.6, 3.7 and 3.8 respectively. The priority value is in the range from 1 to 3 where 1 is high priority and 3 is low priority.
Table 3.6: Kitchen application non-functional requirements. Requirements Priority Ability to interact with the MySQL database. 1 Means of refreshing the orders within the ordered list. 1 Means of refreshing the status of orders. 3 (How many items in the suborder have been cooked) Means of refreshing the status of orders. 3 (How many items in the suborder have not been cooked) Means of refreshing the menu section list. 2 (How many items in the menu section have been cooked) Means of refreshing the menu section list. 2 (How many items in the menu section have not been cooked) Means of refreshing the meal colours within the ordered list: 3 ==> White: not started ==> Yellow: in progress ==> Green: complete Means of displaying only the food items so drink items are omitted. 1 Means of clearing the suborder from the kitchen display. 1
(^4) A menu is active when the current time is within the specified time interval of the menu.
18 Carl Abernethy
R ESTAURANT MANAGEMENT SYSTEM CHAPTER 3. Requirement Analysis
Table 3.7: Management application non-functional requirements. Requirements Priority Ability to interact with the MySQL database. 1 Means of refreshing menus, menu sections and meals live. 3 Only accessible by management staff. 3 Means of displaying the links therefore being able to view the ingredients in a meal etc. 1 Means of searching the database using wild cards for easier data input. 2
Table 3.8: Order application non-functional requirements. Requirements Priority Ability to interact with the MySQL database. 1 Ability to update the suborder status every 5 seconds. 1 Ability to run on a PDA by defining smaller grid and font sizes. 2 Ability to use the application using a touch screen 1 without the need of a keyboard or mouse. Colour co-ordinated meal buttons to visually warn the user of low stock. 2 Ability to disable meals that have run out of compulsory stock items. 1 Ability to only show an ingredient as an optional ingredient choice 1 if there exists enough ingredient stock. Ability to calculate stock ingredient price, order price and discounted price. 1 Live refreshing of the menus depending on the starting time of the order. 1 Ability to apply offers depending on the starting time of order 1 even if the offer is inactive on completion of the order. Minimum clicks from the beginning to the end of an order. 1
3.6 Chapter Summary
This chapter has discussed the requirements of the system and the development methodology that will be used throughout this project. The design of the system is documented in the next chapter.
19 Carl Abernethy