A Case Study in

The Design of a
“Restaurant Management System”

Submitted By –
Submitted to – Miss Garima Mathur Maam
Computer Science and Engineering
University Institute Of Technology
 INDEX
Serial no. Topic Name Date Remarks

1. Introduction

1.1 Overview

1.2 Foreword

1.3 Problem

2. Project Plan

2.1 Project Scope

2.2 Project Estimates and Schedule

3. Software Design

3.1 Test Planning

4. Proposed System Features

1. Introduction

1.1 Overview
This 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 Foreword
In the experience of the authors, some restaurant management
software while having reasonable utility features geared towards
tracking money and profits, seem to have a significant lack where
intuitiveness and usability are concerned. Some restaurant
management software has weak or non-existent security, and in some
cases, functionality needed for day to day operations are only
available to managers. This results in the undesirable situation where
access to manager-level functions are granted to lower-level
employees. These problems may have resulted from the designer’s
lack of domain knowledge, or from a lack of user involvement in the
design process.
This paper reports on the design of a restaurant management
software created as a team project in an undergraduate software
engineering course. The overall goal of the project was to create an
application where both utility and usability are addressed. In particular,
the software should be easy to navigate and use while providing
basic restaurant management and security features. In addition, the
software should grant each employee a level of access that is
commensurate with the duties and responsibilities required in
performing duties. When deployed, the application will serve as a
single working “point of management” system that acts as both a
terminal for taking orders and a terminal for generating reports and
managing changes to employee records.

1.3 Problem
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. 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.
2. Project Plan
The main 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,

that can act as both a terminal for taking orders and a terminal for
generating reports and making changes to employees or items on the
menu. Project planning was done to define the scope of the project,
assess risks, and estimate and schedule project activities and thereby
lay the foundation for the execution, monitoring and control of the
project.
2.1 Project Scope
The overall scope of the software is reflected in the use case
diagram shown in Figure 1. Major software functions of the restaurant
management system include managing orders, inventory, and
employee records, and generating reports.
Order management includes creating and deleting orders, adding and
removing items from an order and closing orders. Orders should also
be stored in the database to be
used to calculate total sales. Inventory management includes adding
new products, deleting products and updating products and resources.
The software is responsible for a number of other functions. Our
software must be able to add employees, edit their information, and
remove employees from the employee database. Menu items must be
added, edited, and deleted from the menu item database. Items that
can be ordered must be able to be added and removed from an
order. All employees must be able to clock in and clock out. Servers
must be able to do what all employees do as well as take orders.
Managers should be able to do what all employees do and be able
to edit item and employee information and generate reports. Reports
that should be generated include sales reports showing sales by food
category and the total sales from the start of the day. Orders should
also be stored in the database to be used to calculate total sales.
For a complete look at desired functionality see page six. The non-
functional requirements of the project included creating an intuitive,
simple application that performs consistently. To achieve these goals
the project should make menus effortlessly navigable and group user
interface (UI) components in a manner that makes them easy to find.
In addition, it was the opinion of the development team that giving
each employee the appropriate level of access to resources was
imperative for usability and security.

2.2 Project Estimates and Schedule

Estimates for time and resources were calculated based on a
developed work breakdown structure (WBS) for the project. The first
two layers of the WBS is shown in Figure 2. Based on the WBS,
tasks were assigned to members of the development team as shown
in Table 2. The table identifies the persons who had primary
responsibility for the development of a specific artifact or the
management of a project task. However, all the members were given
opportunity to modify and perfect artifacts and tasks assigned to other
team members.

3. Software Design
While it is acknowledged that design is not always rational [8] and
while we do not expect any silver bullet [3], in our experience,
software design becomes better with practice and experience. For this
project, the design of the software included both architectural and
subsystem design. The architecture of software defines the major
software subsystems and the dependencies and interrelationships
among subsystems [1,2,4,6,7,10]. Architectural styles define a
vocabulary for different classes of architectures [5,9]. Examples of well
known architectural styles include pipe-and-filter, shared repository and
event driven. In this course, each software development team was
required to design the software using two architectural. The
architectural styles chosen by the restaurant management team were
the three-tiered layered architectural style and the shared-repository
style.

The shared repository architectural style is shown in Figure 4. The

design shows five major subsystems interacting with a shared data
store. While this design is ideal for data driven applications that share
a common database schema, it constraints the evolution of the data
base as well as the data formats on the individual subsystems. A
layered architecture is shown in Figure 5.
3.1 Test Planning
Three goals were identified for the test plan: reliability, security, and
usability. Reliability and security testing was accommodated by
constructing test cases and comparing expected and actual results.
Usability testing, however, is completely different. Usability testing
would require some domain experts to use the software and perhaps
even deploy the software in a restaurant environment. Due to the
time constraints of the project we were unable to perform any formal
usability testing using persons external to the development team. Test
cases were created to test adding, deleting, and editing both items
and employees. Specifically these test cases make certain that
employee and items are stored and retrieved from the database
correctly. Test cases were also generated to perform boundary testing
on how many entries could be successfully added or updated. In
addition, test cases where created to verify the function of the
compare class, which is used to validate input. The table of test
cases listed on the following page shows what kinds of tests were
performed on the “add new employee” function, the intended results,
and the actual results.
4. Proposed System Features
The proposed system features can be split into two categories:
essential features and wish-list.
The essential features:-
1. The system will require a very simple user interface with touch
screen capability.
2. Colour co-ordinated menu is a necessity. Advanced options
incorporated into the simple front
end to reduce the potential limitations. Allow options for every meal
including extras that can
be added at an extra cost.

3. User credentials to track the transaction history and average table

turning time of every member
in the team.
4. SQL Server/Oracle relational database to hold all the ingredients
and courses with a hierarchy
so ingredients can be allocated into food types. Creating food types
will simplify the front end
with respect to showing extras and options of a meal.
5. Administrator options for voiding and applying discounts
6. Management features for viewing sales report, recipe costing etc.
7. Booking tool for allocating tables with table turn estimation.