HARAMAYA UNIVERSITY

COLLEGE OF COMPUTING AND INFORMATICS

DEPARTMENT OF INFORMATION TECHNOLOGY

PROJECT TITLE : RESTAURANT MANAGEMENT SYSTEM

GROUP MEMBER

No Name Id No
1. Abdulbari Ibrahm.………..1946/14
2. Melka Amsalu……………..3378/14
3. Elsiye Bunro……………….0924/13
4. Omar Murad………………2251/13
5. Firaol Gonde..……………...2946/14

Project Advisor:
Mr.Kelemu D.(MSc)

MAY 12, 2025

 Approval sheet
We, the undersigned, hereby certify that all materials and data included in this
Research Method document have been obtained and presented in full compliance with
the guidelines set forth by the Information Technology Department. We also declare
that this work is entirely original and has not been previously submitted or used in any
form by any other departments or individuals.
Students Name Signature Date
Abdulbari Ibrahm _________ _________
Melka Amsalu _________ _________
Elsiye Bunro _________ _________
Omar Murad _________ _________
Firaol Gonde _________ _________

As an authorized Advisor, I have approved the submission of this Practical

Attachment document.

Advisor Name: Mr.Kelemu D.

Signature __________________
Date ______________________

I
 Acknowledgment
We would like to take this opportunity to express our heartfelt gratitude to all those
who have supported us throughout the completion of this group project.

First and foremost, we extend our deepest appreciation to our project advisor,
Mr.Kelemu D (MSc), for his invaluable guidance, encouragement, and unwavering
support. His expertise and constructive feedback were instrumental in shaping this
project and helping us navigate through its challenges.

We are also grateful to our teammates for their dedication, collaboration, and hard
work. The success of this project is a testament to our collective effort and
commitment, and we could not have achieved it without their contributions.

Additionally, we would like to thank our families for their constant love,
understanding, and encouragement. Their unwavering support has been a source of
motivation throughout our academic journey and has enabled us to focus on our
studies and this project.

Lastly, we extend our sincere gratitude to the faculty and staff of the Information
Technology department at Haramaya University for providing us with the necessary
resources and guidance during our time as students. Their dedication to fostering a
supportive learning environment has been invaluable to our growth as individuals and
professionals.

This project would not have been possible without the combined efforts and
encouragement of these individuals, and we are truly thankful for their contributions.

II
 List of Abbreviation
1.DB - Database
2.DBMS - Database Management System
3.IDE - Integrated Development Environment
4.IT - Information Technology
5.OS - Operating System
6.PHP - Personal Home Page
7.RBS - Restaurant Billing System
8.RDBMS - Relational Database Management system
9.SDK - Software Development Kit
10.SQL - Structured Query Language

III
 Table of contents
Approval sheet ................................................................................................................I
Acknowledgemt ............................................................................................................ II
List of abbreviation ......................................................................................................III
Abstract ...................................................................................................................... VII
Chapter One: Introduction ............................................................................................. 1
1.1. Background Harla Cafe and Restaurant ........................................................... 1
1.2. Introduction ...................................................................................................... 1
1.3. Statement of the problem ................................................................................. 2
1.4. Objectives .........................................................................................................3
1.4.1. General Objective ...................................................................................3
1.4.2. Specific Objectives .................................................................................3
1.5.Scope and Limitation of the Project ..................................................................4
1.5.1 Functional Scope ..................................................................................... 4
1.5.2 Technical Scope .......................................................................................4
1.5.3 User Roles ............................................................................................... 5
1.5.4.Limitation ................................................................................................ 5
1.6 Significance of the Project ................................................................................ 5
1.7. Methodology .................................................................................................... 6
1.7.1. System Development Methodology ....................................................... 6
1.7.2. Data Collection Methods ........................................................................6
1.7.3. System Development Tools ....................................................................7
1.8. Project schedule ............................................................................................... 8
Chapter Two: System Requirements ............................................................................. 9
2.1. Introduction ...................................................................................................... 9
2.1.1. Existing System Overview ..................................................................... 9
2.1.2. Drawbacks of Existing System ...............................................................9
2.2. Proposed system .............................................................................................10
2.2.1. Overview .............................................................................................. 10
2.2.2. Functional requirements ....................................................................... 10
2.2.3. Nonfunctional requirements ................................................................. 11
2.2.3.1. Usability ......................................................................................11
2.2.3.2. Reliability ....................................................................................11
2.2.3.3. Performance ................................................................................ 12

IV
 2.2.3.4. Scalability ................................................................................... 12
2.2.3.5. Legal ........................................................................................... 12
2.2.4. Glossary ................................................................................................13
Chapter Three: Requirements Analysis ....................................................................... 14
3.1. System models ............................................................................................... 14
3.1.1. Scenarios ...............................................................................................14
3.1.2. Use case model ..................................................................................... 15
3.1.3. Object model (Class and Object diagrams) .......................................... 18
3.1.4. Dynamic model (Sequence, Activity, state Chart Diagrams) ...............25
3.1.5. User interface ........................................................................................31
Chapter Four: System Design ...................................................................................... 33
4.1. Introduction .................................................................................................... 33
4.1.1. Overview of System Design .................................................................33
4.1.2. Design Goal .......................................................................................... 34
4.2. Current Software architecture ........................................................................ 34
4.3. Proposed Software Architecture .................................................................... 35
4.3.1. Overview .............................................................................................. 35
4.3.2. Sub-system Decomposition with Services (with Deployment Diagram)36
4.3.3. Hardware / Software mapping ..............................................................38
4.3.4. Database design .................................................................................... 39
4.3.4.1. Normalization: ............................................................................ 39
4.3.4. Persistent Data Management ......................................................... 42
4.3.5. Access Control and Security ................................................................ 42
4.3.6. Global control flow ...............................................................................43
4.3.7. Boundary Condition ............................................................................. 43
4.4. Subsystem services .........................................................................................44
4.5. Data dictionary ............................................................................................... 45
4.6. Glossary ..........................................................................................................46
Chapter Five: Implementation......................................................................................47
5.1. Introduction.....................................................................................................47
5.2. Development Environment.............................................................................47
5.3. Key Implementation Steps..............................................................................48
5.4.Quality Assurance........................................................................................,,..49
Conclusion and Recommendation...............................................................................51
Appendix......................................................................................................................52
References....................................................................................................................53

V
 List of Tables

Table 1: Login ....................................................................................................... 15

Table 2: Sign Up ................................................................................................... 16
Table 3: View Menu ..............................................................................................16
Table 4: Edit Menu ................................................................................................16
Table 5: Take Order .............................................................................................. 17
Table 6: Bill Generation ........................................................................................17
Table 7: Make Payment ........................................................................................ 17
Table 8: View Order ..............................................................................................18
Table 9: Manage ....................................................................................................18
Table 10: Manage Class Diagram ......................................................................... 19
Table 11: Kitchen Staff Class Diagram ................................................................ 20
Table 12: Customer Class Diagram ...................................................................... 20
Table 13: Cashier Class Diagram ..........................................................................20
Table 14: Order Class Diagram .............................................................................20
Table 15: Menu Class Diagram .............................................................................21
Table 16:Payment Class Diagram .........................................................................21
Table 17:Billing Class Diagram ............................................................................21
Table 18:Manager Object Diagram .......................................................................22
Table 19:Customer Object Diagram ..................................................................... 23
Table 20:Cashier Object Diagram .........................................................................23
Table 21:Kitchen Staff Object Diagram ............................................................... 23
Table 22:Payment Object Diagram .......................................................................24
Table 23:Billing Object Diagram ..........................................................................24
Table 24:Customer Object Diagram ..................................................................... 24
Table 25:Order Object Diagram ............................................................................25
Table 26:Data Dictionary ......................................................................................46
Table 27: Appendix ...............................................................................................52

VI
 List of Figure
Figure 1.Gantt chart for project schedule ................................................................8
Figure 2.UseCase Diagram ................................................................................... 15
Figure 3.Class Diagram .........................................................................................19
Figure 4.Object Diagram .......................................................................................22
Figure 5. Sequence Diagram for Manager ............................................................ 25
Figure 6. Sequence Diagram for Customer ...........................................................26
Figure 7. Sequence Diagram for Cashier .............................................................. 26
Figure 8. Sequence Diagram for Kitchen Staff ..................................................... 27
Figure 9. Activity Diagram for Manager .............................................................. 27
Figure 10. Activity Diagram for Customer ........................................................... 28
Figure 11. Activity Diagram for Cashier .............................................................. 28
Figure 12. Activity Diagram for Kitchen Staff ..................................................... 29
Figure 13. state Chart Diagram for Manager ........................................................ 29
Figure 14. state Chart Diagram for Customer .......................................................30
Figure 15. state Chart Diagram for Cashier .......................................................... 30
Figure 16. state Chart Diagram for Kitchen Staff .............................................. 31
Figure 17. Home Page User interface ................................................................... 31
Figure 18. Login Page User interface ................................................................... 32
Figure 19. Cashier Dashboard User interface ....................................................... 32
Figure 20. Proposed system architecture .............................................................. 36
Figure 21. Sub-system Architecture ......................................................................37
Figure 22. Hardware and Software Mapping ........................................................38
Figure 23. Database design ...............................................Error! Bookmark not defined.

VII
 Abstract

The Management System for a Restaurant is a web-based application. The main aim
is to provide better communication between customers and restaurants. By using this
application, the user can order from any location. This application will reduce all the
manual processes. So,users can view the restaurant menu from nearby locations, and
can place an order and view the status of the order like cooking/packed/delivered.

There are five main actors in this application:Restaurant manager,Cashier,Kitchen

Staff and Customer.The manager will create all menus with their corresponding price
lists. Also, the manager will be able to view statistical reports for foods. Restaurant
managers will receive orders from customers. Users/Customers can place orders using
this application and they will be able to view available food items.

The system is designed as a 3-tier architecture. Each user must register with the
system; after logging in successfully, they are able to perform operations. Separate
login pages are provided for logging into the system. To develop this system, we use
HTML, CSS, JavaScript, and bootstrap for the front end, MySQL database as the
back end.

VIII
Chapter One: Introduction

1.1. Background Of Harla Cafe and Restaurant

Harla Cafe and Restaurant is a must-visit dining destination for tourists exploring the
historic city of Harar, Ethiopia. Known for its welcoming atmosphere, this restaurant
combines traditional Ethiopian cuisine with a variety of international dishes, making it
an ideal spot for diverse palates. As you step inside, you'll be greeted by friendly staff
who are eager to make your dining experience memorable.

The menu at Harla Cafe features a range of delectable options, from savory injera
served with flavorful stews to mouth-watering grilled meats that showcase the rich
culinary heritage of Ethiopia. Vegetarian and vegan options are plentiful as well,
ensuring that every guest can find something delightful to savor. The restaurant’s
cozy ambiance is enhanced by tasteful decor that reflects local artistry, creating an
inviting environment where you can unwind after a day of sightseeing.

In addition to its excellent food offerings, Harla Cafe is conveniently located near
many attractions in Harar. After enjoying your meal, take a stroll through the
charming streets of this UNESCO World Heritage site, where you can immerse
yourself in the unique culture and history that surrounds you. Whether you're seeking
a casual lunch or a relaxing dinner after exploring the vibrant markets and ancient
sites of Harar, Harla Cafe and Restaurant promises an unforgettable culinary
experience.

1.2. Introduction

A Restaurant Management System is a web based application system. This system

developed to automate day to day activity of a Harla Cafe and Restaurant.This system
developed to provide service facility to Harla Cafe and Restaurant. This restaurant
management system can be used by employees in a restaurant to handle the clients.
The services that are provided is ordering items and sales management by the owner
through the system, and waiter information management, menu information
management and report. The restaurant menu is organized by categories (lunch,

1
breakfast, and dinner) of menu items. Each menu item has a name, price, associated
recipe and picture. A recipe for a menu item has a chef, preparation instruction sands
associated ingredients. With this system, ordering and sales management will become
easier and systematic to replace traditional system where are still using paper.

Restaurant management system is the system for managing the restaurant business.
After successful login the user can access the menu page with the items listed
according to the desired time. The main point of this system is to help restaurant
administrator manage the restaurant business. In system user can login into the system,
but the user (waiter) will be there to serve the customer and recording the order into
system.

The system will have admin page in which, he/she will control all system by adding
and deleting users, manage stock, viewing daily sales and price arrangement. The
users will be able to record orders and print receipt.

1.3. Statement of the problem

Harla Cafe and restaurants manage their business by manual especially take customer
ordering. In traditional booking system and restaurant waiter takes the customer
ordering by manual system with using paper. Customer does some formal
conversation like hello, hi, etc. Than he demands for today's menu and do some
discussion over menu items then he orders. It takes 5 to 10 minutes to book the order
and waiter book the order on paper so there is probability of lost and duplication of
customer information. Restaurant management system puts the order in a queue with
specific priority according to time and quantity, and then a cook is assigned for the
specific order to complete it.

Besides, the restaurant waiter information also by manual system kept use paper and
this is difficult for restaurant administrator to find waiter information, probability
missing the paper and difficult to arrange the schedule. Initial problem is that the
customer has to get connected over the phone; it would be harder if the restaurant is
very popular and busy. Sometimes, waiter information and customer information is
important to restaurant administrator for reference in the future. The chances of

2
committing mistakes at the restaurant side in providing a menu list for a specific time
would be more.

Many people have experienced going to a restaurant where the service is poor and
there is a lack of attention from the wait staff. The paper menus can be flimsy, hard to
navigate, and outdated. This restaurant menu and management system will replace the
paper waste, is more maintainable, and allows for greater customer engagement. The
problem confronting the research is to determine the Documentation for online
restaurant management system.

Also owners many restaurant has failed to going with the business because of fraud
and dishonest of the many employees. They still some of the money from the
restaurant hence to reduce the profit of the business, this has led to loss ultimately
business die.

1.4. Objectives

1.4.1. General Objective

The general objective of this project is to develop a web based system for Harla Cafe
and restaurant.

1.4.2. Specific Objectives

Specific Objectives for the Restaurant Management System of the Harla Cafe And
Restaurant
 To gather the requirements using requirement gathering techniques such as
interviews, surveys, and document analysis.
 To analyze the gathered requirements using tools like Use Case Diagrams,
Scenarios, and Object Models.
 To design the system architecture using Modeling Tools like E-draw-Max,
including data flow diagrams and user interface mockups.
 To implement security measures such as encryption, authentication, and access
 To test the system through manual and automated testing approaches.

3
 To deploy the system and integrate it into the Harla Cafe and Restaurant
infrastructure.
 To provide training and support for staff on how to use the new RMS.
 To monitor and maintain the system post-deployment with ongoing updates.

1.5.Scope and Limitation of the Project

Scope of the Restaurant Management System (RMS) outlines the functionalities,

objectives, and limitations of the system. This project aims to develop a
comprehensive software solution to streamline and automate the operations of a
restaurant, enhancing efficiency, customer satisfaction, and overall management.

1.5.1 Functional Scope

 Customer Management: The system will allow restaurant staff to manage

customer orders, reservations, and feedback efficiently.
 Menu Management: Admins can update, add, or remove items from the menu,
including pricing and descriptions.
 Order Management: The system will handle order placement, order tracking, and
billing for both dine-in and takeaway services.
 Employee Management: The system will include features for managing staff
schedules, roles, and performance.
 Reporting and Analytics: The system will generate reports on sales, inventory,
customer preferences, and employee performance.
 Payment Integration: The system will support multiple payment methods
generate receipts.

1.5.2 Technical Scope

 The system will be developed using modern technologies such as mention

programming languages, frameworks, and tools.
 It will be a web-based application with a responsive design to ensure
compatibility across devices (desktop, tablet, and mobile).
 Data will be stored securely in a relational database, ensuring data integrity and
privacy.

4
1.5.3 User Roles

Admin: Full access to all system functionalities, including menu updates, employee
management, and reporting.
Staff: Access to order management, inventory tracking, and customer service features.
Customers: Access to online menu browsing, reservation booking, and feedback
submission (if applicable).

1.5.4.Limitation

The limitations of the system is it only supports the English language. The system will
not handle complex accounting or payroll management, as these are outside the
primary focus of the project. The internet network is required and it only recognize
Ethiopian currency only.

1.6 Significance of the Project

 Track down sales for each item: All transactions are captured by the system,
including orders, payments, data are accurate and spot on to the last item.
Revenues, therefore, are accurately giving the real health of operation.
 Generate financial statements fast and accurately: Where transactions are
captured digitally, manual errors are avoided. For example, each transaction is
time-stamped and the recorded with other details such as sold items and the
Customer name who performed the transaction.
 Better Custosmer Service: This is probably the best reason why use Restaurant
Management System to make customers happy. Most Restaurant Management
Systems come with a CRM. This module records customer information like name,
contact details, and transactions. With more knowledge of customer that can
deliver a more satisfying service.
 Efficient Staff Management: A Restaurant Management System with an
employee scheduler will help allocate more staff during peak hours and less on
downtime. By aggregating sales data with staff schedule, you can match demand
with supply and ensure resources those are optimized, neither over nor under-
utilized.

5
1.7. Methodology

1.7.1. System Development Methodology

We chose the Agile methodology for our project because it gave us the flexibility to
make changes quickly and allowed us to adapt to the feedback we received during
development. Agile breaks the project into smaller parts, called sprints, where we
focused on building and testing specific features before moving on to the next.
Agile was a good fit for our project because:
 Flexibility: If new requirements or changes came up, we could easily adjust
without disrupting the whole project.
 Continuous Feedback: After each sprint, we got feedback from the Restaurant
manager , making sure we were building something useful.
 Faster Progress: We delivered small parts of the system early, so the organization
could start testing while we kept working.
 Team Collaboration: Agile encouraged us to communicate regularly, which kept
the team on track and helped solve issues quickly.
 Risk Management: Breaking the project into sprints allowed us to spot and fix
problems early, reducing the chance of big delays.

1.7.2. Data Collection Methods

To understand the current challenges and processes at Harla Cafe and Restaurant and
identify areas for improvement, several data collection methods were employed.
These methods were instrumental in gathering insights into how the current manual
administrative and operational systems function, as well as identifying specific areas
that require automation.

Interviews: we conducted interviews with key staff members at Harla Cafe and
Restaurant, including managers, waitstaff, and kitchen personnel, to gain insights into
their daily operations and the challenges they face with the existing manual system.
These interviews highlighted inefficiencies such as delays in order processing,
communication breakdowns between the front-of-house and kitchen, and difficulties
in inventory management. We also consulted with the restaurant's management to

6
better understand their technical requirements and how the proposed system could
enhance operational efficiency and integrate seamlessly with their workflows.

Questionnaires:We distributed questionnaires to the restaurant staff to collect

specific feedback regarding system requirements, including desired features related to
order tracking, communication, inventory management, and security. Staff responses
provided critical insights into the priorities for the new system, such as role-based
user access, ease of use, and the need for real-time data access. This feedback
informed the system design to ensure it aligns with the restaurant’s unique needs.

Direct Observation: we also conducted direct observations of the current manual

processes at Harla Cafe and Restaurant. We examined how tasks such as order-taking,
communication with the kitchen, inventory tracking, and billing are handled.
Observations revealed key pain points, including miscommunication between staff,
delays in order preparation, and difficulties in tracking stock levels. These findings
helped us better understand operational challenges and identify specific areas where
the proposed system could streamline processes and improve overall efficiency.

By combining information from interviews, questionnaires, and direct observation,

our group developed a comprehensive understanding of the operational challenges at
Harla Cafe and Restaurant. This informed the design and implementation of a tailored
system that addresses the specific needs of the restaurant.

1.7.3. System Development Tools

A range of development tools will be utilized to support the RMS project. Project
management will be facilitated by tools like Microsoft Project, which will help in
planning, scheduling, and tracking progress through each phase. Development tools
such as
 Visual Studio Code as an IDE
 Modeling tools like E-draw-Max and Figma Software.
 For web development, HTML, CSS, and JavaScript will be used for the front end,
while PHP and MySQL will handle the back-end.
Additionally, various hardware components will be crucial, including servers to store
and manage records securely, networking equipment to ensure smooth

7
communication between departments, and high-performance desktops/laptops for
developers to efficiently run and test the system.

1.8. Project schedule

Figure 1.Gantt chart for project schedule

8
Chapter Two: System Requirements

2.1. Introduction

2.1.1. Existing System Overview

Harla Cafe and Restaurant stores and maintain their day to day transactions
manually.But some of them are having automation system which is helping them to
store the data. But such restaurants are storing the information about the orders and
the customer information. They don’t have facility to store the information of
feedback and favorite orders of customers over some period of time.Restaurants are
having standalone applications so at one time, they have the facility of many screens
or many operations which is happening at one time. So they are storing them and then
at last, the restaurant managers will able to see the data of last day.The software
which restaurants are using is very costly and their maintenance which is very high.

2.1.2. Drawbacks of Existing System

 This software is basically used only for reservation means table booking.So if we
want to just order some food or store any feed backs then it wont be any helpful.
At last the restaurants have to store by themselves which will became no use of
software.
 The user interface of the application is also not that much attractive
 So from the restaurants point of view, they are able to store only one kind of
information. There is no security feature also.
 If any of party order is canceling at the last moment, it will make avariation in the
already created records and also will causes the wastage of foods.
 Many of the systems will not store the budget details for a long time.
 This will creates lot of mistakes like misspellings, calculation problems,duplicate
entries etc.
 It is difficult for Managers to supervise all the sides of restaurants like kitchen,
waiter, and counter simultaneously.
 There is no functionality to get the updated details at all time to the Owners and
Managers from all the branches

9
2.2. Proposed system

2.2.1. Overview

New system makes it easier to manage the employees effectively. However,The

restaurant management system that is computer based application will provide a
working environment that will be flexible, efficient and user-friendly by affording
easy of work with significant reduction of time. In an computer platform that many
remote clients can access; the system will need more reliable security to uniform
application in secure manner to the visitors of the site.The administrator of the system
will be capable to give different privileges and permissions to the users and visitors of
the system, and all permissions will be monitored in restricted way. Some systems
available now was developed with old versions of Software that causes the system’s
speed to be slow or totally unsuitable.They are static and unchangeable sites.
However we are trying to develop a new system with the latest versions of Software
to be fast and reliable.

2.2.2. Functional requirements

Restaurant Management is having many modules, which make the software more
efficient and user friendly. The modules make the maintenance of the database
easier.Every module is divided on the basis of the scenarios. The main three scenarios
are

Table Reservation and Queue Management

 Allows customers to book tables in advance through a user-friendly website.
 Customers receive timely notifications about their reservations, including
confirmation reminders and alerts when their order is ready.

Digital Menu and Self-Ordering System

 Provides digital menus available which can be accessed from the table.
 Gives each dish rich details describing the ingredients, nutritional information,
and presentation photos.
 Enables customers to order using their gadgets, which will send the command to
the kitchen immediately.

10
Kitchen Display System (KDS) for Order Tracking
 A digital display system that replaces traditional kitchen printing.
 Orders are displayed with real-time updates on how far along each one is in the
preparation process.
 Reduces errors while improving kitchen productivity.

2.2.3. Nonfunctional requirements

2.2.3.1. Usability

The system's interface was designed to be simple and intuitive to ensure all user roles
required minimal training:
 Consistent design principles were applied across all pages using Bootstrap,
ensuring familiar and user-friendly layouts.
 Drop-down menus, tool-tips, and placeholder text were used to guide users during
interactions.
 A user feedback mechanism was included to allow for reporting usability issues
and continuously refining the design.

2.2.3.2. Reliability

To maintain high availability and minimal downtime, especially during peak periods ,
the following reliability measures were taken:
 Regular automated database backups were planned to ensure data recovery in
case of a failure.
 Error-handling mechanisms were built to provide meaningful feedback to users
and log issues for debugging.
 Testing under simulated peak loads helped identify and address potential
bottlenecks, improving system robustness.

11
2.2.3.3. Performance

To ensure fast access to data and quick response times, even with a large number of
concurrent users, the following techniques were applied:
 Database optimization was achieved by indexing frequently accessed columns
and structuring queries efficiently to reduce response time.
 Pagination was implemented for data-heavy operations (e.g., displaying student
records) to minimize server load.
 Server-side caching techniques were used to store frequently accessed data
temporarily, reducing the need for repetitive database queries.

2.2.3.4. Scalability

To accommodate future growth in the number of Customer and staff, the following
scalability strategies were employed:
 The database schema was designed with normalization principles to allow
efficient handling of increased data volumes.
 Modular development practices were followed, ensuring new features could be
integrated without disrupting existing functionality.
The system architecture supported load balancing, enabling horizontal scaling by
adding more servers if user traffic increased significantly.

2.2.3.5. Legal

The system to be developed is not conflict with any government directives, because it
gives services for the people effectively and efficiently, Provide compliance with
health, safety, and taxing regulations. The processes are automated to eliminate the
risk of non-compliance.

12
2.2.4. Glossary

Restaurant Management System (RMS): A software system designed to manage,

store, and retrieve records efficiently throughout their life cycle.
Operational Interruptions: Breakdowns in system functionality that disrupt regular
operations and workflow.
User Adoption: The extent to which employees effectively utilize a new system or
technology in their daily tasks.
Centralized Database: A single storage system where all digital records are
organized and accessible.
Web Interface: A browser-based application that allows users to interact with the
system remotely.
Version Control: A feature that tracks changes made to documents, allowing users to
revert to previous versions.

13
Chapter Three: Requirements Analysis

3.1. System models

In this section, we present various system models used to describe the system from
multiple perspectives. These models help to understand the structure, behavior, and
interactions within the system.

3.1.1. Scenarios

In this section, we outline various scenarios that illustrate how users interact with the
proposed Restaurant management system. Each scenario represents a typical use case,
detailing the sequence of actions and the expected outcomes. Scenarios help in
understanding user needs and the functionalities required from the system.
Menu Creation and Management:
 Admin and waiter creates and edits the restaurant's menu, categorizing items (e.g.,
starters, main courses, desserts, beverages).
Order Management:
 Chefs access customer orders in real-time, including dish quantities and special
instructions.
Delivery Time Setting:
 Chefs estimate preparation times for each order to ensure timely service.
Order Status Updates:
 Waiter mark orders as "In Progress" or "Delivered" to notify customers.
Menu Browsing and Ordering:
 Customers view the menu, including popular items and daily specials, and place
orders directly.
Order Tracking:
 Customers track their order’s preparation status and expected delivery time, as
updated by chefs.
Order Review and Billing:
 Cashiers can view all customer orders to generate accurate bills

14
Payment Processing:
 Cashiers accept payments in forms (Chapa) and provide receipts to customers.
Transaction Records:
 Cashiers maintain a record of all transactions, ensuring daily income is accurately
reported

3.1.2. Use case model

Figure 2.UseCase Diagram

Use case Diagram Description

Use Case Name Login

Actors Manager, Chef, Customer, Cashier

Description Users log into the system with their credentials and log out
when their session ends.
Precondition User must be registered in the system and have valid
credentials.
Post-condition Users are authenticated and granted appropriate access levels.

Alternative If credentials are invalid, the system shows an error and

actions prompts for re-entry.
Table 1: Login

15
Use Case Name Sign Up

Actors Customer
Description A new customer creates an account in the system.

Precondition The user must not already have an account in the system.

Post-condition A new customer profile is created.

Alternative If required fields are not filled, the system prompts the user to
actions complete all necessary information.
Table 2: Sign Up

Use Case Name View Menu

Actors Customer
Description Customers can view the restaurant menu to browse food and
drink options.
Precondition The menu must be preload into the system.

Post-condition The menu is displayed to the customer for browsing

Alternative if no menu is available, the system displays a "Menu

actions unavailable" message.
Table 3: View Menu

Use Case Name Edit Menu

Actors Manager ,Waiter

Description The manager and Waiter can add, remove, or modify items
on the restaurant's menu.
Precondition The manager and Waiter must be logged in with appropriate
permissions to update the menu.
Post-condition The updated menu is saved and made available to all users.
Alternative If changes are invalid (e.g., missing fields), the system
actions prompts the manager to correct them.
Table 4: Edit Menu

16
Use Case Name Take Order

Actors Chef, Waiter

Description The chef or cashier processes and updates the status of an
order.
Precondition There must be a valid order placed by a customer.

Post-condition The order's status (e.g., "In Progress," "Completed") is

updated in the system.
Alternative If the chef cannot fulfill the order, it is flagged as "Unable to
actions Complete," and the customer is notified.
Table 5: Take Order

Use Case Name Bill Generation

Actors Cashier and Manger

Description The system calculates the bill for an order and generates a
receipt for the customer.
Precondition There must be a completed order.

Post-condition A receipt is generated and saved, and payment can proceed.

Alternative If bill generation fails, the system allows the cashier to retry.
actions
Table 6: Bill Generation

Use Case Name Make Payment

Actors Customer
Description Customers complete the payment process for an order.
Precondition The bill must be generated and presented to the customer.

Post-condition The payment is processed, and the transaction is saved.

Alternative If payment is declined, an alternative method is selected (e.g.,

actions cash, card, or digital wallets).
Table 7: Make Payment

17
 Use Case Name View Order

Actors Chef, Waiter

Description Allows actors to view details of an active or past order.
Precondition The system must have orders stored in its database.

Post-condition Order details are displayed to the user.

Alternative If no orders are found, the system displays a "No Orders

actions Found" message.
Table 8: View Order

Use Case Name Manage

Actors Manager
Description The manager oversees restaurant operations, including
monitoring staff, inventory, and performance.
Precondition The manager must be logged in with appropriate
permissions.
Post-condition The manager's requested actions (e.g., performance
updates, inventory changes) are completed.
Alternative actions If data updates fail (e.g., inventory changes not saved), the
system provides an error message.
Table 9: Manage

3.1.3. Object model (Class and Object diagrams)

Class diagrams
The Class Model is a vital part of the object-oriented design, representing the different
entities in the Restaurant management system. This model defines the classes, their
attributes, methods, and the relationships among them, forming the foundation for
system development.

18
 Figure 3.Class Diagram

Class Diagram Description

Manager
Class Attributes Methods Relationships
Manager - Id (int) - Login() One-to-Many
- Name (String) add_delete_updateCashier() with Customer,
-Username - add_delete_updateChef() Cashier, Kitchen
(String) - manageCustomer() Staff, and waiter
-Password - manageMenu() -Manages various
(String) - manageOrder() other entities.
Table 10: Manage Class Diagram

19
Kitchen Staff
Class Attributes Methods Relationships
Kitchen Staff - Id (int) - takeOrder() - Many-to-Many
- Name (String) - cook() with Order
- Username(String) - notify()
- Password (String)
Table 11: Kitchen Staff Class Diagram
Customer
Class Attributes Methods Relationships
Customer - Id (int) - Register() - Many-to-Many
- Name (String) - Login() with Order and
- Username(String) - Order() Payment.
- Password (String) - CancelOrder()
- modifyOrder()
- Payment()
Table 12: Customer Class Diagram
Cashier
Class Attributes Methods Relationships
Cashier - Id (int) - Take_Payment() - One-to-Many
- Name (String) - Check_Order() with Billing and
- Username(String) Order.
- Password (String)
Table 13: Cashier Class Diagram
Order
Class Attributes Methods Relationships
Order - Order_Id (int) - editOrder() - Many-to-Many
- Order_type - addOrder() with Menu and
(String) - deleteOrder() Kitchen Staff.
- Order_description - searchOrder() - Connected to
(String) Customer and
- Order_number Cashier.
(int)
Table 14: Order Class Diagram

20
Menu
Class Attributes Methods Relationships
Menu - menu_Id (int) Item() - Many-to-Many
- menu_item with Order
(String)
- menu_price (int)
Table 15: Menu Class Diagram

Payment
Class Attributes Methods Relationships
Payment - Payment_Id (int) - Pay() - Many-to-One
- Customer_Id (int) - CancelPayment() with Customer.
- Payment_type - One-to-One with
(String) Order.
Table 16:Payment Class Diagram

Billing
Class Attributes Methods Relationships
Billing - Bill_number (int) - printBill() One-to-One with
- Order_Id (int) Order and
- Customer_Id (int) Payment.
- Total_price (int)

Table 17:Billing Class Diagram

21
Object diagrams
The Object Model serves as a blueprint for the record management system,
illustrating the various classes, their attributes, methods, and relationships. It provides
a clear framework for understanding how different entities within the system interact,
facilitating the design and implementation of the system.

Figure 4.Object Diagram

1. Manager (M1)
Object Name Attributes Relationships Functionalities
Manager -Username: -Creates& manageCustomer()
"adminusername" Manages:Customers(C1), - manageMenu()

-Password: Menu (M2), Orders (O1) - manageOrder()

- Checks: Customers
"adminpassword"
(C1), Menu (M2), Orders
-Name:
(O1)
"abdulbari"
Table 18:Manager Object Diagram

22
2. Customer (C1)
Object Name Attributes Relationships Functionalities
Customer - Username: - Places Orders (O1) - order_item()
"customerusername" - Checks Menu (M2)
- Password: -MakesPayment (P1)

"customerpassword
Table 19:Customer Object Diagram

3. Cashier (C2)
Object Name Attributes Relationships Functionalities
Cashier -Username: - Receives Payment take_Payment()
"cashierusername" (P1) from - check_Order()
-Password: Customer (C1)
"cashierpassword" - Checks Orders
- Name: "melka" (O1)
- Generates Billing
(B1)
Table 20:Cashier Object Diagram

4. Kitchen Staff (K1)

Object Name Attributes Relationships Functionalities
Kitchen Staff -Username: - Receives & - takeOrder()
"cheifusername" Processes Orders - cook()
-Password: (O1)
"cheifpassword" - Prepares Menu
- Name: "elsiy" items (M2)
Table 21:Kitchen Staff Object Diagram

23
5. Payment (P1)
Object Name Attributes Relationships Functionalities
Payment - Payment ID: - Made by - pay()

"5748" Customer (C1)

- Payment Date: - Processed by
"3-4-2024" Cashier (C2)
- Amount: "1245"
Table 22:Payment Object Diagram

6. Billing (B1)

Object Name Attributes Relationships Functionalities

Billing - Bill ID: "325" - Generated by - printBill()
- Bill Amount: Cashier (C2)
"45.6" - Related to
Payment (P1)
Table 23:Billing Object Diagram

6. Menu (M2)

Object Name Attributes Relationships Functionalities

Menu - Menu Name: - Managed by - item()
"pizza" Manager (M1)
- Menu ID: "7645" - Ordered by
- Price: "12.56" Customer (C1)
- Prepared by
Kitchen Staff (K1)
Table 24:Customer Object Diagram

24
8. Order (O1)
Object Name Attributes Relationships Functionalities
Order - Order ID: "1235" - Placed by - list_menu()
- Order Date: Customer (C1)
"1/3/2017" - Checked by
Manager (M1)
- Processed by
Cashier (C2)
- Prepared by
Kitchen Staff (K1)
Table 25:Order Object Diagram

3.1.4. Dynamic model (Sequence, Activity, state Chart Diagrams)

Sequence Diagrams
1. Sequence Diagram for Manager

Figure 5. Sequence Diagram for Manager

25
2 .Sequence Diagram for Customer

Figure 6. Sequence Diagram for Customer

2. Sequence Diagram for Cashier

Figure 7. Sequence Diagram for Cashier

2 . Sequence Diagram for Kitchen Staff

26
 Figure 8. Sequence Diagram for Kitchen Staff

1 .Activity Diagram for Manager

Figure 9. Activity Diagram for Manager

27
2 .Activity Diagram for Customer

Figure 10. Activity Diagram for Customer

3 .Activity Diagram for Cashier

Figure 11. Activity Diagram for Cashier

28
3 .Activity Diagram for Kitchen Staff

Figure 12. Activity Diagram for Kitchen Staff

1. state Chart Diagram for Manager

Figure 13. state Chart Diagram for Manager

29
2.state Chart Diagram for Customer

Figure 14. state Chart Diagram for Customer

3.state Chart Diagram for Cashier

Figure 15. state Chart Diagram for Cashier

30
4.state Chart Diagram for Kitchen Staff

Figure 16. state Chart Diagram for Kitchen Staff

3.1.5. User interface

1. Home Page:

Figure 17. Home Page User interface

Navigational Paths
1. Path: Launch Application > Home Page
2. Description: Upon launching the application, users are greeted by the home page,
which contains an overview of the system's features and options to log in or
access help resources.

31
2 . Login Page

Figure 18. Login Page User interface

Navigational Paths
1. Path: Home Page > Login Page > Dashboard
2. Description: Users begin at the home page and click the "Login" button to access
the login page. After entering their username and password, they will be
redirected to their personalized dashboard.
3. Cashier Dashboard

Figure 19. Cashier Dashboard User interface

Navigational Paths
4. Path: Home Page > Login Page > Dashboard
5. Description: Users click "Login" on the Home Page, enter their username and
password (mandatory), and are redirected to the Cashier Dashboard with sections
like Process Orders, View Payments, and Logout.

32
Chapter Four: System Design

4.1. Introduction

Project has been designed using numerous diagrammatic techniques, the most general
modelling language to describe both the structure and behaviour of a software system
is Unified Modelling language (UML). Use case diagrams have already been used in
the requirements analysis as a way to graphically overview the order process with in
the system. Other diagrams from the UML family are used in the design stage to show
the structure and behaviour of numerous sophisticated design features.

4.1.1. Overview of System Design

Restaurant Management System (RMS) aims at automating and optimizing day-to-

day operations of the contemporary restaurant to increase efficiency, customer
satisfaction, and decision-making. The system follows client-server architecture with
a modular, cloud-based architecture to achieve a seamless interaction between users
(customers, managers, employees) and back-end services (order management,
inventory management, analytic). Key components are:
Presentation layer:
 Staff Interfaces: Touch screen terminal to take order, real -time order monitoring
kitchen view and manager dashboard for analysis.
 Customer interface: system application for reservation, self-service bookstall
for ordering.
 Administrate interface: Web -based dashboard for menu configuration, staff
access and financial reporting.
Application layer:
 Core business logic: Manages workflow such as order route, table reservation,
inventory updates and invoicing.
 API: Restful API integrates the front interface with backnd services and external
systems (eg payment port, distribution applications).

33
Data layer:
 Structured database: Keep SQL database (eg postgresql) Transaction data (order,
invoice, employee information).
 Collection: Collection or Redis in the memory speeds real -time functionality (eg
accessibility updates).

4.1.2. Design Goal

The system designs prefer to create a strong, scalability and safe solution for
operations, customer support and management requirements for modern restaurants.
These goals ensure that the system increases efficiency, user satisfaction and
adaptability as the business grows.

 To reduce manual errors and employee workload, you automate repeated tasks
such as order processing, table reservation and warehouse tracking.
 Protect customer payment data with end-to-end encryption and Safe Payment
Gateway Use the role -based access control (RBAC) to limit system access
 Provide interface with intuitive knowledge for different users touch screen
system with submission of a touch. user-friendly menu with allergen filters and
real -time orders.
 Support multi-launch management through centralized cloud-based
control.Handle top traffic with automatic scaling of cloud infrastructure.

4.2. Current Software architecture

Currently, the restaurant does not use any automatic software to manage operations.
All activities, including orders that take orders, stock tracking, reservation and staff
management, are handled manually. This leads to many operational challenges:

Time waste:The manual stream of taking orders, transferring them to the kitchen and
managing the customer's bills will take time. The waiter must physically transfer
orders to the kitchen, which delays the service and increases the possibility of errors.

Difficulty reaching the previous record:To look at previous sales, stock

consumption or customer rating, employees must turn through paper logs or

34
handwritten notes. It is boring and there is a possibility of loss of information or
inaccuracy.
Disabled Operations Management:The use of physical means to manage the
planning of orders, inventory and employees leads to operating barriers, especially in
busy hours. This prevents the growth efficiency of the restaurant with an increase in
customer demand.
Slow order processing:When orders are received in parties, workers must manually
filter them and cause dull treatment. It can give rise to delayed service and unhappy
customers.
Security issues:Without a protected method for financial transactions, warehouse use
and monitoring of employee work programs, sensitive company data is unsafe for
unauthorized reading or changes. There are no concrete audit tracks to monitor
individual orders or transactions.

4.3. Proposed Software Architecture

4.3.1. Overview

We’re design of the new Restaurant Management System is such that it employs a
client-server architecture. This means that the staff and customers can access the
system using any web browser without the need to install a special application. All the
processing is performed on the server, which enables a fast and reliable system easily
usable on different entities, that is desktops, tablets, and smartphones.

1. Client Layer:
• Web Interface: The system has a simple and user-friendly web interface, which is
built using HTML, CSS, and JavaScript. This ensures that the system can be accessed
from any device with a web browser, such as desktop computers, laptops, tablets, and
smartphones.
• User Roles and Permissions: Every user has a specific role in the system, such as
administrator, cashier, or chief. This helps ensure that only authorized users can
access information.

35
2. Application Layer:
• PHP Server Logic: The server-side part of the system is built using PHP. This part
of the system handles all the requests from users, such as order item or payment ,
and it communicates with the database to retrieve or store the necessary information.
• Validation and Error Handling: The application layer checks the input provided by
users to make sure it is correct and handles any errors that may occur.
3. Database Layer:
• MySQL Database: The MySQL database stores all the documents and the related
metadata, such as the sender, recipient, date. This structure allows for quick searches
and makes it easy to retrieve order. The database is designed to handle a growing
number of records as the restaurant needs expand.
4. Security Layer:
• Role-Based Access Control (RBAC): This ensures that only users with the
appropriate permissions can access or modify certain documents.

Figure 20. Proposed system architecture

4.3.2. Sub-system Decomposition with Services (with Deployment Diagram)

To make the system easier to understand and manage, we divided it into several
smaller parts, called sub-systems. Each sub-system is responsible for a specific task,
which makes the whole system more organized and efficient.

36
1. Authentication and Authorization Sub-system
 Purpose: Controls user login, sign-up, and access to make sure users with
permission can use specific system features.
 How It Works: Checks user login details and gives permissions based on roles
such as Manager, Waitstaff, Kitchen Staff, or Customer.
2. Order Management Sub-system
 Purpose: Takes care of customer orders for eating in taking out, and delivery.
 How It Works: Saves order details, keeps an eye on order status in real-time, and
lets the kitchen know what to prepare.
3. Reservation and Table Management Sub-system
 Objective : for holding the reservations in a table-ahead-seating
 How it works : This gives customers online table booking facility and staff real
time to see the availability of tables.
4. Inventory Management Subsystem
 Objective: Watch the stock and avoid out-of-stock and excess waste generation.
 How it works: monitors how much we are using of each ingredient and
automatically updates stock with every order placed, sending our managers when
they run out.
5. Notification Sub-system
 Objective: to send alerts to service staff of significant activities such as new
orders, low stock, or soon to be reservations.
 How This Works: The real-time notifications getting displayed in dashboards
(email or SMS if required).

Figure 21. Sub-system Architecture

37
4.3.3. Hardware / Software mapping

To ensure that the system runs efficiently and can handle the number of users and
documents it will manage, we carefully planned how the software will interact with
the hardware. Here’s how we mapped out the hardware and software:
1. Server-Side Hardware:
• The system will be hosted on a central server that has enough power to handle
multiple users at once. This server needs to have:
• Multi-core Processor: To manage multiple user requests at the same time.
• At least 8GB of RAM: To make sure the system runs smoothly and can handle the
database and application processes without slowing down.
• SSD Storage: Using solid-state drives (SSDs) will allow for faster access to files and
documents, which is important when dealing with large volumes of data.
2. Software:
• Operating System: We recommend using a Window-based OS, because it is secure,
reliable, and optimized for server environments.
• Web Server: The Apache web server will serve the web pages and handle the
requests coming from users.
• Database Server: MySQL will manage all the data storage, ensuring that documents
are stored safely and can be retrieved quickly when needed.

Figure 22. Hardware and Software Mapping

38
4.3.4. Database design

Data are known facts that can be recorded and that have implicit meaning. A database
is a collection ofrelated data. Database management system is a collection of
programs that enables users to create and maintain the database. It is a general-
purpose software system that facilitates the processes of defining,constructing,
manipulating, and sharing database among various users and applications

4.3.4.1. Normalization:

1. Goes Relationship
UNF:
Attributes: R_id, R_name, Contact_no, Address, Cus_id, Cus_name
1NF:
 Customer Table: Cus_id, Cus_name, Contact_no, R_id
 Manager Table: M_id, M_name, Contact_no, Address
2NF:
 Customer Table: Cus_id, Cus_name, Contact_no, R_id
 Manager Table: M_id, M_name, Contact_no, Address
3NF:
 Manager Table: M_id, R_name, Contact_no, Address
2. Serves Relationship
UNF:
 Attributes: Cus_Id, Cus_name, Contact_no, W_id, Wname
1NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Cashier Table: Ch_id, Ch_name, Cus_id
2NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Cashier Table: Ch_id, Ch_name, Cus_id
3NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Cashier Table: Ch_id, Ch_name, Cus_id

39
3. Prepares Relationship
UNF:
 Attributes: Chef_id, Chef_name, Order_no, No_items, Ord_time
1NF:
 Chef Table: Chef_id, Chef_name, Order_no
 Order Table: Order_no, No_items, Ord_time
2NF:
 Chef Table: Chef_id, Chef_name, Order_no
 Order Table: Order_no, No_items, Ord_time
3NF:
 Chef Table: Chef_id, Chef_name, Order_no
 Order Table: Order_no, No_items
 Order_Info Table: No_items, Ord_time
4. Takes Relationship
UNF:
Attributes: W_id, W_name, Order_no, No_items, Ord_time
1NF:
 Waiter Table: W_id, W_name, Order_no
 Order Table: Order_no, No_items, Ord_time
2NF:
 Waiter Table: W_id, W_name, Order_no
 Order Table: Order_no, No_items, Ord_time
3NF:
 Waiter Table: W_id, W_name, Order_no
 Order Table: Order_no, No_items
 Order_Info Table: No_items, Ord_time
5. Places Relationship
UNF:
Attributes: Cus_id, Cus_name, Contact_no, Order_no, No_items, Ord_time
1NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Order Table: Order_no, No_items, Ord_time

40
2NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Order Table: Order_no, No_items, Ord_time
3NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Order Table: Order_no, No_items
 Order_Info Table: No_items, Ord_time
6. Contains Relationship
UNF:
Attributes: Order_no, No_items, Ord_date, Food_no, Quantity, Price, Description
1NF:
 Order Table: Order_no, No_items, Ord_time
 Item Table: Item_no, Quantity, Price, Description, Order_no
2NF:
 Order Table: Order_no, No_items, Ord_time
 Item Table: Item_no, Quantity, Price, Description, Order_no
3NF:
 Order Table: Order_no, No_items, Ord_time
 Item Table: Item_no, Quantity, Price, Description, Order_no
 Item_Detail Table: Quantity, Price
7. Pays Relationship
UNF:
Attributes: Cus_id, Cus_name, Contact_no, B_no, Price, Ord_detail, Vat
1NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Bill Table: B_no, Price, Ord_detail, Vat, Cus_id
2NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Bill Table: B_no, Price, Ord_detail, Vat, Cus_id
3NF:
 Customer Table: Cus_id, Cus_name, Contact_no
 Bill Table: B_no, Price, Ord_detail, Cus_id
 Bill_Description Table: Price, Vat

41
4.3.4. Persistent Data Management

Data management is a crucial aspect of the restaurant management system, ensuring

that all records, orders, and inventory details are securely stored and easily retrievable.
Here’s how data is managed:
1. Order and Inventory Storage:
Each order placed in the system is stored on the server, along with essential details
such as order ID, customer name, items ordered, total cost, and time of order.
The system also maintains inventory records, tracking ingredient stock levels and
automatically updating quantities based on orders and restocks.
2. Metadata Management:
Metadata describes each order and inventory entry, allowing for efficient organization
and retrieval. It includes:
Order ID: A unique identifier for each order.
Customer Information: Details of the customer placing the order.
Order Time & Date: The timestamp when the order was placed.
Items Ordered: A list of menu items included in the order.
Inventory Details: Ingredient usage, stock levels, and supplier information.

4.3.5. Access Control and Security

Security is a top priority for the Restaurant Management System, as it handles

sensitive customer information, financial transactions, and operational data. Multiple
layers of security have been implemented to protect the system and its data:
 Role-Based Access Control (RBAC):
Each user is assigned specific permissions based on their role in the system. For
example:Managers can oversee orders, inventory, and employee schedules but cannot
modify system configurations.Kitchen Staff can access order details and inventory but
do not have permission to modify financial records.Cashiers can manage orders and
process payments but cannot access sensitive business data

42
4.3.6. Global control flow

The control flow of the Restaurant Management System is designed to be simple and
intuitive for users. When a user logs in, they are directed to their dashboard, which
provides quick access to their relevant tasks, notifications, and system features based
on their role.

1. Dashboard Functionality:
Managers can monitor inventory, track orders, and manage staff schedules.Kitchen
Staff receive and process incoming orders, updating the system when meals are
prepared.Cashiers can take new orders, process payments, and update order statuses.

2. System Processing:
Every action is processed by the application server, which communicates with the
database to retrieve or update relevant data.Users can quickly place new orders,
update inventory, generate reports, and manage customer interactions in real-time.The
system logs all activities, ensuring smooth operations and accurate record-keeping.

4.3.7. Boundary Condition

The Restaurant Management System is designed to handle unexpected situations,

known as boundary conditions. These include:

1. Order and Data Loss Prevention:

If an order record or inventory data is corrupted or lost, the system includes backup
and recovery mechanisms to restore the latest valid data, ensuring that no critical
information is permanently lost.

2. Unauthorized Access Prevention:

If an unauthorized user attempts to access the system without proper credentials,
access will be denied.Multiple failed login attempts trigger security measures, such as
temporary account lockouts or alerts to administrators, helping to prevent
unauthorized access

43
4.4. Subsystem services

Each subsystem in the Restaurant Management System is designed to handle specific

aspects of the restaurant’s operations. These subsystems work together to ensure
efficient, secure, and streamlined management of restaurant activities. Below are the
main subsystems and the services they provide:

 Authentication and Authorization Subsystem

 Services Provided:User Login and Registration: Securely manages user
authentication and registration processes.
 Role Assignment: Assigns roles (e.g., admin, manager, chef, waiter, cashier) to
define user permissions.
 Session Management: Issues session tokens for secure user interaction during
active sessions.
 Access Control: Ensures users can only access features and data according to
their assigned roles.

 Order Management Subsystem

 Services Provided:
 Order Placement: Allows waitstaff to place customer orders directly into the
system.
 Kitchen Order Processing: Sends orders to the kitchen for preparation and
updates status in real-time.
 Order Tracking: Enables tracking of order status (e.g., pending, in preparation,
ready, served).
 Payment Processing: Integrates with billing to generate invoices and process
payments.
 Interaction with Other Subsystems:Works with the Authentication and
Authorization Subsystem to ensure only authorized staff can manage orders.

 Inventory Management Subsystem

 Services Provided:
Stock Monitoring: Tracks ingredient usage and notifies when stock is low.
Supplier Management: Maintains supplier details and order histories.

44
Automated Restocking: Generates purchase orders for restocking when inventory
reaches a threshold.
Waste Management: Logs food waste to help optimize stock and reduce losses.
 Interaction with Other Subsystems:
Integrates with the Order Management Subsystem to update inventory based on order
preparation.Works with the Notification Subsystem to alert managers when stock is
low or supplies need replenishing.

 Notification Subsystem
 Services Provided:
User Alerts: Notifies staff about new orders, low inventory, or completed
payments.Dashboard Integration Displays notifications directly on users’ dashboards
for quick reference.Real-time Updates Sends instant alerts for urgent actions like
order readiness or stock shortages.
 Interaction with Other Subsystems:
Receives triggers from the Order Management Subsystem to notify kitchen staff of
new orders.Coordinates with the Inventory Management Subsystem to alert managers
about stock levels.Works with the Authentication and Authorization Subsystem to
ensure notifications are delivered only to relevant staff.

4.5. Data dictionary

The Data Dictionary defines the essential data elements used in the Restaurant
Management System (RMS), ensuring clarity and consistency across the system

User_ID Integer A unique identifier assigned to each staff member

(e.g., waiter, chef, manager).
Username String The login name used for user authentication in the
system
Password String Encrypted password for secure staff authentication
Role String Defines the user’s role (e.g., Manager, Waiter, Chef,
Cashier).
Order_ID Integer A unique identifier assigned to each customer
order.

45
Order_Date DateTime The date and time when the order was placed.
Order_Status String Status of the order (e.g., Pending, In Progress,
Served, Completed, Canceled).
Menu_Item_ID Integer Unique ID for each menu item available in the
restaurant.
Item_Name String Name of the food or beverage item.
Price Integer Price of the menu item.
Bill_ID Integer Unique identifier for each customer bill.
Customer_ID Integer Unique identifier assigned to each customer
(optional for walk-in customers).
Customer_Name String Name of the customer.
Contact_Number Integer String Customer’s contact number

Table 26:Data Dictionary

4.6. Glossary

 Authentication and Authorization: Verifies user identity and controls access

based on roles.
 Approval Status: The current state of a document (e.g., Pending, Approved).
 Client-Server Architecture: System where the user interface communicates with a
server for tasks like data storage.
 Metadata: Information about a document, like title, date, and author, used for
search and categorization.
 Encryption: Protects data by converting it into a secure, unreadable format.
 MySQL: A database used for storing and managing data.
 Notification Subsystem: Sends alerts to users about important actions or
deadlines.
 PHP: Server-side scripting language used for processing user requests.
 RMS: Resturant Management System, automating document handling.
 RBAC: Role-Based Access Control, limits access based on user roles.
 Web Interface: The system’s user-friendly front end accessed through a browser.

46
 Chapter Five: Implementation

5.1. Introduction

The implementation phase of our Restaurant Management System (RMS) focused on

turning the design into a working system that meets the Harla Cafe and Restaurant
needs. This chapter will discuss how we developed each part of the system, the tools
we used. Our goal during implementation was to ensure that the system was easy to
use, fast, and secure. The main focus was on translating the design into code and
making sure the system worked smoothly for document management, retrieval, and
storage.

5.2. Development Environment

We used several tools and technologies to build the system. The development
environment was set up to ensure smooth collaboration between team members and to
provide a structured approach to coding.
 Front-End Development: For the front-end, we used HTML, CSS, and
JavaScript. These tools helped us create a web-based interface that was simple,
user-friendly, and accessible on any device with a browser. HTML was used for
structuring the content, CSS for styling the pages, and JavaScript to add
interactivity (e.g., search functions, filtering documents).
 Back-End Development: On the back-end, we used PHP with the Laravel
framework as the server-side scripting language. PHP (with Laravel) was
responsible for handling user requests, such as searching for documents or
uploading files, and interacting with the database to retrieve or store information.
 Database: We used MySQL to store the documents and their metadata. The
database structure was designed to handle a large number of records efficiently
and to allow fast searches and retrieval of documents based on metadata such as
sender, recipient, and date.
 Development Tools: We used VS Code as our integrated development
environment (IDE), and XAMPP for testing and running the system locally.
XAMPP helped us simulate a live environment by providing Apache for the web
server, MySQL for the database, and PHP for server-side scripting.

47
5.3. Key Implementation Steps

The implementation process was divided into several key steps:

1. Setting Up the Development Environment: The first step was configuring our
local machines with the necessary tools. Each team member installed XAMPP,
which allowed us to test the system locally before deploying it on a live server.
2. Database Design and Setup: The MySQL database was set up to store the
documents and the related metadata. We designed the database tables to ensure
that every document was tagged with important information such as the date it
was received, who sent it, and who it was sent to. This made it easier to search
and filter documents later on.
3. Front-End Development: The user interface was created using HTML, CSS,
and JavaScript. We focused on building a simple and intuitive interface so that
users could easily upload, search, and retrieve documents without much training.
The interface also included a dashboard that displayed notifications for tasks like
document approvals.
4. Back-End Development: The PHP scripts using the Laravel framework were
written to handle the requests made by users through the front-end. For example,
when a user searched for a document, the PHP script with Laravel would query
the MySQL database and return the results to the front-end, where they would be
displayed.
5. Security Implementation: We implemented several security measures, including
role-based access control (RBAC). This ensured that only authorized users could
access sensitive documents. For example, administrators could view all records,
while regular staff members could only access the documents relevant to their
department.
6. Testing and Debugging: Once the system was developed, we conducted tests to
make sure everything worked as expected. This included testing the search
functionality, document upload, and role-based access. We also debugged any
issues that arose during testing.

48
5.4.Quality Assurance

Quality assurance (QA) is foundational in our project to develop a web-based

Restaurant management system, ensuring it meets high standards of functionality,
reliability, security, and user satisfaction.

Importance of Quality Assurance in Our Project

 Customer Satisfaction: QA ensures alignment with user expectations and
operational needs, enhancing customer satisfaction and usability.
 System Reliability: It verifies system stability under various conditions, reducing
failures and downtime.
 Security Measures: QA implements robust protocols to safeguard data and
prevent breaches.
 Cost Efficiency: Identifies issues early, minimizing rework costs and enhancing
project efficiency.

Principles Guiding Quality Assurance.

Our QA approach is guided by core principles:
 User-Centric Approach: Prioritizes user needs to meet functional and usability
requirements.
 Process Optimization: Establishes efficient processes for design, development,
testing, and maintenance.
 Continuous Improvement: Evaluates and refines QA processes to adapt to
project requirements.
 Risk Management: Proactively identifies risks and implements mitigation
strategies.

Methods and Techniques Employed

 Testing: Includes functional, performance, security, and usability testing.
 Reviews and Inspections: Ensures quality through peer reviews and inspections.
 Automation: Streamlines testing tasks and improves coverage.
 Metrics and Reporting: Monitors quality metrics and generates reports for
decision-making.

49
Role of Quality Assurance in Our Project
 Functionality: Ensuring accurate document storage, retrieval, and access
management.
 Performance Optimization: Maintaining system responsiveness and scalability.
 Security Assurance: Implementing data protection measures and compliance.
 User Experience: Enhancing interface usability and satisfaction.

50
Conclusion and Recommendation

Conclusion
This project successfully designed and implemented a web-based Restaurant
Management System to address the operational challenges faced by Harla Cafe and
Restaurant. By replacing manual processes with an automated solution built using
PHP, MySQL, and modern web technologies, the system streamlines order
management, inventory tracking, billing, and customer relationship management. The
three-tier architecture ensures scalability while role-based access control maintains
security across different user types (managers, staff, and customers).

Key achievements include reducing order processing time, minimizing human errors
in billing, and providing real-time business insights through reporting modules. While
currently limited to English language and single-branch operations, the system's
modular design allows for future enhancements like mobile app integration, multi-
language support, and multi-location functionality. This implementation demonstrates
how targeted digital transformation can significantly improve efficiency and customer
service in Ethiopia's growing hospitality sector while serving as a model for similar
small and medium-sized restaurants.

The project highlights the importance of user-centered design, agile development

methodologies, and adapting technology to local business contexts. For optimal long-
term benefits, regular system updates and comprehensive staff training programs are
recommended.

Recommendation

Restaurant is a good stepping stone in understanding the use of technology in an SME

restaurant and to better prepare for digital transformation in the future. One we
recommend for Harla cafe and restaurant has better adapted themselves in using this
restaurant management system, they can expand to a more advance system that not
only assists them in POS, but also for all areas of the restaurant. This will not only
help with the daily operations, which can hopefully increase the sales of the
restaurant,but also to improve the restaurant towards up scaling in the near future

51
 Appendices
Appendix . List of Questionnaires Interviews

No Question Answer
1 Business Ownership
2 Owner’s Name,Age
4 Owner’s Education background
5 Product selling
6 Product name
7 Why did you choose to become a restaurant manager?
8 What, according to you, is the most important responsibility
of a restaurant manager?
9 Do you think System might replace restaurant staff in the
future?
10 How do you collaborate with a chef who prefers working
alone?
11 How would you convince the head chef to remove or
include specific items on the menu?
12 What would you do if a customer had an allergic reaction?
13 What was the biggest challenge you encountered in your
previous role and how did you overcome it?
14 Do you go through any failure before establishing (business
name)?
15 Does digital transformation help with the sales?
16 Do you plan to upscale and expand your business?
17 If so, what is the problem of upscale and expanding?
18 Do you plan to make digital transformation as your overall
future plan? How?
19 Who are your competitors?
20 What is your Future plan?
21 What can you suggest for a better support to get your
business upscale? And perhaps minimize the challenges in
the future?
22 Can you describe a typical day at work?

Table 27: Appendix A

Confirmed by: ______________________

Name:____________________________
Phone number:_____________________

52
References
 Web-Based Restaurant Ordering Systems: A Case Study. Journal of Hospitality IT,
12(3), 45-62.(“ https://doi.org/10.1080/1528008X.2021.1929876 ”)
 IoT in Smart Restaurants: A Systematic Review. IEEE Access, 10, 112345-
112360.(“ https://doi.org/10.1109/ACCESS.2022.3145678 ”)
 Adoption of POS Systems in Addis Ababa Restaurants. 5(2), 33-50.(“
http://ejc.et/journals/vol5/iss2/4/ ”)
 National Restaurant Association (2023). Technology Trends in Food Service.(“
https://restaurant.org/research/tech-trends ”)
 Oracle MICROS (2024). POS System Implementation Guide. (“https://www.oracle.com/ind
ustries/food-beverage/ “)
 Square for Restaurants (2023). Inventory Management Best Practices. “https://squareup.com/us/en/r
estaurants/inventory “)
 Laravel Cashier (2024). Payment Processing Documentation. (“https://laravel.com/docs/11.
x/cashier ”)
 MySQL for Hospitality (2023). Database Schema Examples. (“ https://dev.mysql.com/tech-
resources/hospitality-solutions/ “)
 Mealey, L (2019). Why You Need a POS System in a Restaurant. The balance
small business. < https://www.thebalancesmb.com/why-you-need-a-pos-
system-2888877>
 WebstaurantStore (March 14, 2019). Front of House vs Back of House<
https://www.webstaurantstore.com/article/5/front-of-house-vs-
back-of-house.html >

53