Android Based Online Restaurant Management System 2

Wollo University
Kombolcha Institute of Technology
College of Informatics
Department of Computer Science
Project on:
Android Based Online Restaurant Management System
for Yegofe View Hotel
Prepared by:
NAME…………………………………………ID
1. Mohammed Bedru.…………………………………. WOUR/0744/11
2. Tsemre Wondwosen ………………………………… WOUR/5868/11
3. Selam Tegegn ………………………………………. WOUR/5866/11
Advisor: - Kibebu M (MSc)
KOMBOLCHA, ETHIOPIA
SEPTEMBER, 2022
ANDROID BASED ONLINE RESTAURANT MANAGEMENT SYSTEM |2022
APPROVAL SHEET
This is to certify that the senior project titled “Android Based Online Restaurant Management
System for Yegofe View Hotel” is prepared by: -
Name ID_No Sign
1. Mohammed Bedru WOUR/0744/11 __________
2.Tsemre Wondwosen WOUR/5868/11 __________
3. Selam Tegegn WOUR/5866/11 __________
Submitted to the Department of Computer Science in Wollo University for the partial
fulfilment of the requirement of the Degree of Bachelor Science in Computer Science. The
contents of this document in full, or in parts, have not been submitted to any other institute or
university for the award of any degree or diploma.
Advisor name Signature Date
1. Kibebu M. _____________ ____________
APPROVED BY: -
Examiners name Signature Date
1. ______________ _____________ ______________

2. ______________ _____________ ______________
i
Acknowledgment
First of all, we would like to thank Almighty GOD for the strength, he has given us
throughout our life and this project; nothing could happen without the help of GOD.
Secondly, we would like to express our gratitude to our advisor Mr. Kibebu Mela (MSc) for
his help, willingness, and commitment for giving his precious time to help us to accomplish
this work. We are also very grateful and would like to extend our sincere thanks to the
manager of Yegofe view hotel Mr. Esmael and all the staff members for giving us the
necessary information and documents about the organization.
ii
Abstract
This project is android based online restaurant management system that uses an internet
connection, a centralized database, an android application, and a website, which is specially
designed for customers to place their order without even waiting for the waiter. The
application is installed on the android device, which contains an interactive and up-to-date
menu with all available options in an easy-to-use manner. Customers can choose one or
more items to place an order which will land in the cart and they can view all the order
details in the cart before checking out. In the end, the customer gets order confirmation
details. Once the order is placed it is entered into the database and retrieved by the kitchen
staff. This allows Hotel Employees to quickly go through the orders as they are received and
process all orders efficiently and effectively with minimal delays and confusion. This
application greatly simplifies the ordering process for the customer and the Hotel.
iii
Content
s
Acknowledgment.....................................................................................................................................ii
Abstract...................................................................................................................................................iii
List of Tables..........................................................................................................................................vi
List of Figures........................................................................................................................................vii
Abbreviations.......................................................................................................................................viii
CHAPTER ONE: INTRODUCTION......................................................................................................1
1.1 Background of the Study...................................................................................................................1
1.2 Background of the Organization........................................................................................................1
1.3 Statement of the Problem...................................................................................................................2
1.4 Objectives of the Project....................................................................................................................2
1.4.1 General Objective.......................................................................................................................2
1.4.2 Specific Objective.......................................................................................................................2
1.5. Scope and limitation of the project...................................................................................................3
1.5.1. Scope of the project...................................................................................................................3
1.6. Significance of the Project................................................................................................................4
1.7 Methodology of the Project...............................................................................................................4
1.7.1 Data Collection Methodologies..................................................................................................4
1.7.2 System Analysis and Design Methodology................................................................................5
1.7.3 System Development Model.......................................................................................................5
1.7.4 System Development Tools........................................................................................................6
1.7.5 Testing Methodology..................................................................................................................7
1.8 Feasibility Study................................................................................................................................8
1.8.1 Technical Feasibility...................................................................................................................8
1.8.2 Operational Feasibility................................................................................................................8
1.8.3 Political Feasibility.....................................................................................................................8
1.8.4 Economic Feasibility..................................................................................................................8
1.8.4.1 Cost Benefit Analysis..........................................................................................................9
1.9 Budget of the Project.........................................................................................................................9
1.10 Team Composition.........................................................................................................................10
1.11 Work Plan of the Project................................................................................................................10
CHAPTER TWO...................................................................................................................................11
2. Description of the Existing System and Requirement Gathering......................................................11
2.1. Introduction of Existing System.....................................................................................................11
iv
2.2. User of Existing System.................................................................................................................12

2.3. Major Functions in The Existing System.......................................................................................12
2.4. Business Rules................................................................................................................................12
2.5. Report Generated in the Existing system........................................................................................12
2.6. Form and other documents in the existing system..........................................................................13
2.7. Bottlenecks of Existing System......................................................................................................14
2.7.1. Performance.............................................................................................................................14
2.7.2 Security and controls................................................................................................................14
2.7.3 Efficiency..................................................................................................................................14
2.8. Proposed solution for the new system............................................................................................15
2.9. Overview of the Proposed System..................................................................................................15
2.10. Requirements of the Proposed System.........................................................................................16
2.10.1. Functional requirement..........................................................................................................16
2.10.2. Non-functional requirements.................................................................................................17
2.11. Modeling the Existing Systems....................................................................................................18
2.11.1. Essential Use Case Modeling................................................................................................18
2.11.2 Domain modeling with Class Responsibility Collaboration (CRC).......................................18
Chapter 3: System Analysis...................................................................................................................21
3.1 Introduction......................................................................................................................................21
3.2 Modelling the Proposed System......................................................................................................21
3.2.1 Use Case Model........................................................................................................................21
3.2.1.1 Actor and Use Case Identification.....................................................................................21
3.2.1.2 Use Case Diagram.............................................................................................................22
3.2.2 Use case Description.................................................................................................................23
3.2.3 Sequence Diagram....................................................................................................................40
3.2.4 Activity Diagrams.....................................................................................................................48
3.2.5 Analysis class Diagram.............................................................................................................56
3.2.6 User Interface Prototyping........................................................................................................57
CHAPTER FOUR: System Design.......................................................................................................58
4.1 Introduction......................................................................................................................................58
4.2 Class type architecture.....................................................................................................................58
4.3 Class Modeling................................................................................................................................59
4.4 State Chart Modeling.......................................................................................................................61
4.5 Collaboration Modeling...................................................................................................................62
4.6 Component Modeling......................................................................................................................63
4.7 Deployment modeling......................................................................................................................64
4.8 Persistence modeling.......................................................................................................................65
4.9 User Interface design.......................................................................................................................67
v
CHAPTER FIVE...................................................................................................................................70
Implementation and Testing..................................................................................................................70
5.1 Introduction to Implementation and Testing...................................................................................70
5.2 Final Testing procedures of the System...........................................................................................70
5.3 Implementation sample Code Review.............................................................................................71
5.4 Hardware software acquisitions.......................................................................................................78
5.5 User manual preparation..................................................................................................................78
5.6 Installation.......................................................................................................................................78
CHAPTER SIX......................................................................................................................................79
CONCLUSION AND RECOMMENDATION.....................................................................................79
6.1 Conclusion.......................................................................................................................................79
6.2 Recommendation.............................................................................................................................79
References..............................................................................................................................................81
Appendix 1.............................................................................................................................................82
Appendix 2.............................................................................................................................................83
vi
List of Tables
Table 1. 1 Total Benefit of the project.....................................................................................................9
Table 1. 2 Net Benefit of the project.......................................................................................................9
Table 1. 3 Budget of the project..............................................................................................................9
Table 1. 4 Team Composition................................................................................................................10
Table 1. 5 Work plan of the project.......................................................................................................10
Table 2. 1 CRC for Menu Item..............................................................................................................19

Table 2. 2 CRC for Cart.........................................................................................................................19
Table 2. 3 CRC for Order Report..........................................................................................................19
Table 2. 4 CRC for Bill..........................................................................................................................19
Table 2. 5 CRC for Order......................................................................................................................20
Table 2. 6 CRC for a Alert.....................................................................................................................20
Table 3. 1 Log in - use case description................................................................................................24

Table 3. 2 Add Menu Item Use Case Description.................................................................................25
Table 3. 3 Create employee account Use Case Description................................................................25
Table 3. 4 Update Menu Item Use Case Description............................................................................26
Table 3. 5 Update Employee Detail Use Case Description...................................................................27
Table 3. 6 Delete Menu Item Use Case Description..............................................................................27
Table 3. 7 Delete Employee Detail Use Case Description....................................................................28
Table 3. 8 View Feedback Use Case Description..................................................................................29
Table 3. 9 Assign table number Use Case Description..........................................................................29
Table 3. 10 Logout Use case Description..............................................................................................30
Table 3. 11 Add Menu Item to cart Use Case Description....................................................................30
Table 3. 12 View Payment Detail Use Case Description......................................................................31
Table 3. 13 Write Remark Use Case Description..................................................................................31
Table 3. 14 Give Feedback Use Case Description.................................................................................32
Table 3. 15 Review cart Use Case Description.....................................................................................32
Table 3. 16 Remove item from cart Use Case Description...................................................................33
Table 3. 17 Place order Case Description..............................................................................................33
Table 3. 18 View menu Use Case Description......................................................................................34
Table 3. 19 add raw materials Use Case Description............................................................................34
Table 3. 20 Register daily usage Use Case Description........................................................................35
Table 3. 21 Accept Alert Use Case Description....................................................................................35
Table 3. 22 Call Waiter Use Case Description......................................................................................36
Table 3. 23 View detail of ordered item Use Case Description............................................................36
Table 3. 24 update order status Use Case Description..........................................................................37
Table 3. 25 Assign waiter when the item is ready to be delivered Use Case Description.....................37
Table 3. 26 View customer location......................................................................................................38
Table 3. 27 Recover password...............................................................................................................38
Table 3. 28 view order history...............................................................................................................39
vii
List of Figures
Figure 2. 1 Purchase report form...........................................................................................................13
Figure 2. 2 Essential use case diagram..................................................................................................18
Figure 3. 1 System use case diagram.....................................................................................................23

Figure 3. 2 login - sequence diagram.....................................................................................................39
Figure 3. 3 add menu item - sequence diagram.....................................................................................40
Figure 3. 4 Create employee account - sequence diagram....................................................................40
Figure 3. 5 update menu item - sequence diagram................................................................................41
Figure 3. 6 update employee account- sequence diagram.....................................................................42
Figure 3. 7 delete menu item- sequence diagram..................................................................................43
Figure 3. 8 delete employee account- sequence diagram......................................................................44
Figure 3. 9 add item to cart- sequence diagram.....................................................................................45
Figure 3. 10 Call waiter- sequence diagram..........................................................................................46
Figure 3. 11 Login - Activity Diagram..................................................................................................47
Figure 3. 12 Add menu item - Activity Diagram...................................................................................48
Figure 3. 13 Create Employee Account - Activity Diagram.................................................................49
Figure 3. 14 Delete menu item- Activity Diagram................................................................................50
Figure 3. 15 Add item to cart- Activity Diagram..................................................................................51
Figure 3. 16 view payment detail - Activity Diagram...........................................................................52
Figure 3. 17 remove item from cart - Activity Diagram........................................................................53
Figure 3. 18 Logout- Activity Diagram.................................................................................................54
Figure 3. 19 analysis level class diagram..............................................................................................55
Figure 3. 20 User interface prototyping.................................................................................................56
viii
Abbreviations
CRC……………………………………Class responsibility collaborator.
GUI……………………………………. Graphical User Interface.
HTML ………………………..………Hyper Text Markup Language.
MYSQL……………………………… Structured Query Language.
OOAD…………………………………. Object Oriented Analysis and Design
PHP…………………………………. Hypertext Preprocessor Scripting Language
UML……………………………………Unified Modeling Language.
UC………………………………………Use case.
ix
CHAPTER ONE: INTRODUCTION
1.1 Background of the Study

A restaurant is a commercial outfit that specializes in the preparation of quality food and
serving them to satisfy the customer’s demands. In the current marketplace, there is a great
value for food, restaurants, and their management. There is day by day increment in the
number of restaurants and food places that are emerging today. It can be considered as rapid
growth in the field of business and food restaurants and their management system.
Every restaurant or hotel, whether small, medium-sized, or large, will benefit greatly by
switching from manual processes to automated or software-based ones [1].
An online restaurant management system is a rapidly growing technology. The main aim of
our system is to provide online food ordering and table reservations with a speed of
operation, large storage capacity, large operating range, and less time-consuming. In recent
days Android is a popular technology that hit the market to exchange information through the
internet. The system is implied to control traffic flow of order, create proper billing, reduce
waiting time, and reduce human mistakes. Usually, the waiter is required to take an order,
make a reservation, to serve a meal. After finishing customer has to pay the bill at the
counter. Despite this operation being very easy, it increases the workload of waiters which is
noticeable as it degrades service quality. Nowadays by using advanced technology we can
improve service quality. At the current time, wireless devices such as mobile menu displays
have been taken by choicely to restore the old way of taking orders using pen and paper.
Therefore, an android-based restaurant management system has been developed due to the
growing popularity and ability of mobile devices and a variety of new systems or technology
are being launched every day.
1.2 Background of the Organization

Yegofe View Hotel is a well-established three-star hotel found at a convenient location in the
center of the city of Kombolcha. The name derives from “Yegofe Mountain”, the biggest and
known mountain in Kombolcha. It was established in 2010 E.C. Currently the hotel has 70
bedrooms which are four types: single, double, triple, and family with different prices. It has
two services: room and restaurant service. The ambiance of the place can refresh all the stress
DEPARTMENT OF COMPUTER SCIENCE 1

of every customer. They can enjoy the fresh air and feel relaxed. It can accommodate
customers from time to time, especially near places from Kombolcha City.
1.3 Statement of the Problem

Nowadays, many restaurants manage their business manually especially taking customer
orders. In a traditional booking system, a customer has to go to a restaurant or make a phone
call to get his meal reserved. Today, the restaurant waiter takes the customer’s order by a
manual system using paper. It takes more time to book the order and the waiter book the
order on paper so there is a probability of loss and duplication of customer information.
Usually, a waiter is required to take an order, make a reservation, record a customer order,
and then transmit it to kitchen staff for preparation. Despite this operation being easy, it
increases the workload of waiters which is noticeable as it degrades service quality.
Customers are not able to get a detailed description of each food, for placing any orders
customers have to know about each food item. When changes in price or item updates are
required for the menu, the costs for reprinting and environmental concerns associated with
reprinting need to be considered.
1.4 Objectives of the Project

1.4.1 General Objective
The general objective of this project is to develop android based online restaurant
management system for Yegofe View Hotel.
1.4.2 Specific Objective

Here are some specific objectives that would together help us achieve the overall goal of the
project as follows:
 To study about problems of the existing system
 To gather required information about the existing system.
 Perform requirement analysis to find out system functional and non-functional
requirements.
 To design the new system based on the identified requirements using object-oriented
models to understand the system and implementation easily.
 To implement the new system based on the new system design.
 To test the functionality of the proposed system.

1.5. Scope and limitation of the project

1.5.1. Scope of the project
In scope:
 Menu management
 View menu
 Add menu
 Update menu
 Delete menu
 Manage user account
 Create user account
 Update user account
 Delete user account
 Activate/Deactivate user account
 Manage food orders
 Order food using mobile phones
 View orders
 Approve/ reject orders
 View customer location
 Order cancellation
 Charge delivery fee based on customer’s distance
 Upload a screenshot of the payment
 Display order history
 Generate report
 View sales report
 View purchase report
 Sales management
 Register new items to be purchased
 View items
 Register daily usage
 Give comment
Out scope:

 The system does not include payroll

 It does not include online payment
 The system does not allow users and admins to have a chat rather than a comment by
a user.
1.6. Significance of the Project

The advantages of using this android based online restaurant management system are many
compared to the manual system.
Significance for the hotel
 A menu can easily change if there is any rise in price
 Reduce the order processing time
 Automate redundant work
 Orders are taken online so reducing worker’s effort
 Minimize paperwork
 It satisfies users of the system
 It makes the restaurant efficient and more profitable, as it follows an automated
system
 It increases performance of the restaurant
Significance for the customer
 No need to wait for the waiters to take the order
 They can see the menu with detailed descriptions
 Avoid wastage of customers’ time when they want to access service from the
restaurant
1.7 Methodology of the Project

Methodology means the way or method in which the project is used while conducting the
project. We will use the following methodologies.
1.7.1 Data Collection Methodologies

Data collection is one of the important tasks to analyze how activities are done in the existing
system and developed the new system. Data for developing this system was obtained from
different sources. These data sources were system users and taking the experience of other
countries through the internet.
Interview

An interview is a two-way conversation. It is a personal form of communication between two

people. We interviewed different employees to gather the required data for the project about
how the existing system works.
Observation
An act or instance of viewing or noting a fact or occurrence for some scientific or other
special purposes. Observation requires observing and seeking knowledge, often through
experiments. Used to gather additional data by observing the actual work being done. We
have seen the customers waiting much time to order food.
Document Analysis
Document analysis is a form of qualitative research in which documents are interpreted by
the researcher to give voice and meaning to an assessment topic [2]. We have collected
information by referring to documents and other reading materials about restaurant
management on the internet.
1.7.2 System Analysis and Design Methodology

We used an object-oriented analysis and design approach for modeling and designing the
modules of the proposed system. The main reason behind using OOAD is:
 Promotes better understanding of user requirements
 Leads to clear design by using use case, activity diagrams and sequence diagrams
 Allows to breakdown complicated systems into smaller, clearly defined, and more
manageable parts
 Easy maintenance
 Enables the standardization of objects which increases design understanding and
decreases the risk associated with project development
 It enables us to comprehensively model a system before we develop it
 It reduces the development time & cost
1.7.3 System Development Model

There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred to as
“Software Development Process Models". Each process model follows a Series of steps
unique to its type to ensure success in the process of software development [3]. The proposed
system follows the Iterative Model. we will use this model for the following reasons:

 This model starts from the simple implementation of a small set of software
requirements and iteratively enhances the evolving versions until the complete system
is applied and ready to be deployed
 It goes forward and backward
 Used to add a new feature to the system
 Team members can recover previous errors
 It is easier to manage the development process
Figure 1. 1 Iterative Model

1.7.4 System Development Tools
Software Tools Hardware Tools
Android Studio Personal computer
Visual studio code Flash Drive
MS word 2016 Printer
XAMPP server
Edraw Max
Mendeley Reference Manager
Programming Language
 Java: We have chosen java as our primary language for android development because
Android mainly uses java and we are familiar with it

 PHP: Hypertext Preprocessor is a widely used, general-purpose scripting language

that was originally designed for web development to produce dynamic web pages
 MYSQL:
 Because of its unique storage engine, architecture MYSQL performance is
very high
 Most of the time MYSQL is compatible with PHP programming language and
MYSQL portable
 We are familiar with MYSQL, so we select it to manage the database system
1.7.5 Testing Methodology

Unit Testing
Unit testing is the first level of testing and is often performed by the developers themselves. It
is the process of ensuring individual components of a piece of software at the code level are
functional and work as they were designed to. Developers in a test-driven environment will
typically write and run the tests before the software or feature is passed over to the test team.
Integration Testing
After each unit is thoroughly tested, it is integrated with other units to create modules or
components that are designed to perform specific tasks or activities. These are then tested as a
group through integration testing to ensure whole segments of an application behave as
expected (i.e., the interactions between units are seamless). These tests are often framed by
user scenarios, such as logging into an application or opening files. Integrated tests can be
conducted by either developers or independent testers and are usually comprised of a
combination of automated functional and manual tests.
System Testing
System testing is a method used to evaluate the completed and integrated system, as a whole,
to ensure it meets specified requirements. The functionality of the software is tested from end
to end and is typically conducted by a separate testing team than the development team
before the product is pushed into production.
Acceptance Testing
Acceptance testing is the process of the testing system before its delivery. A system is mainly
developed for an end user normally a customer of the organization. A system is said to be
accepted if and only if the user of the system is satisfied. In this perspective acceptance,
testing is widely used to prove that system performs as per the requirements. In acceptance,

testing the customers provides the input data to validate the system operation. It is also
known as functional testing, black box testing, release acceptance, application testing,
confidence testing, final testing, and validation testing.
1.8 Feasibility Study

A feasibility study is conducted to evaluate the feasibility of the project in various aspects.
For our project, we have done the feasibility study and our project is feasible in almost all
aspects. The following are brief descriptions of each aspect of the feasibility study.
1.8.1 Technical Feasibility

This feasibility evaluation determines whether the technology needed for the proposed
system to be developed is available or not.
 The system can be developed through tools and devices which are currently available
on the market (for example desktop computers, Edraw max, etc).
 The project can be working with current equipment, latest software technology &
available personnel
 The needed equipment and software may also be easily accessed and can successfully
satisfy the user requirement
1.8.2 Operational Feasibility

Operationally the system we have to develop is feasible. Mean that the proposed system will
solve the previously stated problems. It is reliable, maintainable, and suitable for the user. In
addition to that, it follows each step how the existing system is working and our technical
skills transform the existing system into android based and automated one.
1.8.3 Political Feasibility

In terms of political feasibility, the system we develop will not violate any laws, rules, or
regulations of the Hotel. Instead, it supports the strategies of the Hotel in creating better
market opportunities.
1.8.4 Economic Feasibility

The purpose of the economic feasibility assessment is to determine the positive economic
benefits to the organization that the proposed system would provide. It includes
quantification and identification of all the benefits expected. Concerns with the economic
justification that includes a cost-benefit analysis. Generally, the system does not require a

huge amount of money and energy to be developed. It gives a lot of benefits such as
advancing the services of the system and decreasing the workload of the users.
1.8.4.1 Cost Benefit Analysis
The cost-benefit analysis also known as benefit-cost analysis is a process by which an
organization can analyze a decision, system, or project. A cost-benefit analysis is a systematic
process that businesses use to analyze which decisions to make and which to forgo [4].
According to our determination, the project we are going to develop will provide the next
benefits:
Tangible Benefits: are benefits derived from the creation of a system that can be measured in
money and with consistency.
The team has identified the following: -
 Reduce resource requirements or unnecessary wastage of resources in the hotel like
paper, pen and decrease payment for advertisements gives for TV, Radio, etc
 Tracking Sales
 Increase the speed of activities during the ordering
 Enhanced Productivity
Table 1. 1 Total Benefit of the project
Benefit Cost
Reduction of stationery cost 5,000 per month
Reduction of space to store data 10,000
Total benefit 15,000
Table 1. 2 Net Benefit of the project

Total benefit Total cost Net Benefit
15,000 1,050 13,950
Intangible Benefits: are benefits derived from the creation of an information system that
cannot be easily measured in money and consistency.
The intangible benefits of the new system are:
 User Satisfaction
 Reduce the workload of employees
 Improve Customer Relationships

1.9 Budget of the Project

Table 1. 3 Budget of the project
Tools Item Quantity Estimated Unit Estimated Total

cost in birr Cost in Birr
Hardware Laptop 1 Free Free
Tools
Paper 1 Pocket 500 500
Flash 2 250 500
Notebook 1 50 50
Software Tools MS word Free 0 0
Edraw Max Free 0 0
Android studio Free 0 0
Visual studio Free 0 0
code
XAMPP Server Free 0 0
Total cost 1,050
1.10 Team Composition

Table 1. 4 Team Composition
No Id Number Name Responsibility
1 WOUR/0744/11 Mohammed Bedru In All Activities

2 WOUR/5868/11 Tsemre Wondwosen In All Activities
3 WOUR/5866/11 Selam Tegegn In All Activities
1.11 Work Plan of the Project

A project work plan is a visual list of tasks or activities placed in chronological order, which
lets project managers view the entirety of the project in one place. A project work plan
typically takes the form of a horizontal bar chart, where each task is given a name and a
corresponding start and end date.
Table 1. 5 Work plan of the project

CHAPTER TWO
2. Description of the Existing System and Requirement Gathering
2.1. Introduction of Existing System
This chapter focuses on the overview of the existing system and the functional and non-
functional requirements of the proposed systems. It tells how the current system performs its
activities within the organization.
The Existing manual system uses paperwork and direct human communication to manage the
hotel. Waiters use paper to write the order of customers. In this system, every time a
customer enters the hotel a waiter comes to his table and presents him with a menu card, with
the record of food items. The waiter then waits with a notepad and a pen to take down the
customer's order. The waiter then notes down the order of the customer in his/her notepad
and the record is stored on the paper. As with anything paper-based, it is so easy for things to
get damaged or paper to be lost due to fire or accidents. There is a wastage of time, money,
and paper. As traditional menu cards are paper-based, any changes that need to be made to
the menu card will lead to wastage. As it will require reprinting of all the menu cards. Also,
for small changes, it is not possible to print all the menu cards again and again. To access a
particular record from the stack of papers is not efficient.
In an existing system for giving any orders, a user should visit Hotels or Restaurants to know
about food items and then give orders and pay in advance or you need to select the menu and
place an order on call. In this method time and manual work is required. Maintaining critical
information in the files and manuals is full of risk and tedious processes.
From the customer’s point of view, this system is time-consuming. As one has to wait until
the waiter comes to take the order, one has to call the waiter several times till he/she notices
it, there can be misinterpretation while the waiter is writing your order on paper, and it might
be possible that you are served with a wrong dish.

Waiters always make the same mistake when it comes to taking their customers’ orders.
Miscommunication is the most common reason why this problem happens. Unsystematic
menu implementation in a traditional menu system (paper-based system) will make the
customers have a problem making up their minds to order what they want to eat in that hotel.
The paper-based menu also has a problem caused by a restriction of the space needed to show
the pictures and detail of all of the food.
2.2. User of Existing System

 Manager: Overlook the whole work of the system.
 cashier: Receive order requests by phone and inform kitchen staff to cook the food.
 Kitchen staff: Cook the food.
 Waiters: provide service for customers.
 Purchaser: purchase necessary materials for the hotel.
2.3. Major Functions in The Existing System

The main function of the current system:
 The waiter receives food order request and transmits it to the kitchen staff
 The kitchen staff process order
 The waiter receives the processed order from the kitchen staff
 The cashier generates a bill
 Different information is stored on paper
 Purchaser purchase items after approved by the manager
2.4. Business Rules

A business rule is a statement that defines or constrains some aspect of the business. It is
intended to assert business structure or to control or influence the behavior of the business.
The business rule regarding the customer are the following:
BR1: To make an order, the customer must pay for the food.
BR2: Customers should not change their location (of high distance) after ordering food.
BR3: All meals in a single order must be delivered to the same location.
BR4: The customer must be within the 10KM range to order foods.
BR5: Order price is calculated as the sum of each food item price times the quantity of that
food item ordered, plus applicable sales tax, plus delivery charge if the order is delivered
outside the free delivery zone.

BR6: Order cancellation is only allowed before the order processing is started by the kitchen
staff.
2.5. Report Generated in the Existing system

Different reports are generated in the existing system of Yegofe view hotel. Reports are
generated daily and weekly. This report helps the information of every workflow of the
restaurant, helps the administration to ask for additional information, and so on.

2.6. Form and other documents in the existing system
Figure 2. 1 Purchase report form

2.7. Bottlenecks of Existing System

The main problem of the existing system is the use of hand and paper-based system in which
errors occurred regularly. The kitchen staff is struggling to keep up with the food preparation
and making sure the foods are prepared in the correct order and retrieved by the appropriate
waitress.
2.7.1. Performance
The process of collecting customers’ orders is very tedious. This makes it impossible to
deliver goods on time. The customer has to wait until the waiter comes to take the order, one
has to call the waiter number of times till he/she notices it, there can be misinterpretation
while the waiter is writing your order on paper, and it might be possible that you are served
with a wrong dish.
Due to the existing system, the response time for performing every process is very slow,
documents are stored on the paper-based only, searching mechanism of files is manual. For
this instance, the performance of the existing system is very low.
2.7.2 Security and controls

Every record of the existing system is paper-based that stored on a shelf, so, it is difficult to
control and secure these manual records, since it doesn’t have any authentication and
authorization system. For instance, the necessary documents and files have been lost and
damaged due to the war.
2.7.3 Efficiency
Due to the manual operation, most of the activities are prone to wastage of resources like
papers, manpower, time, etc., to produce the corresponding outputs. This makes the current
system inefficient while utilizing resources. When changes in price or item updates are
required for the menu, the costs for reprinting and environmental concerns associated with
reprinting need to be considered. There should be a mechanism that reduces wastage of
resources and that makes the system to be efficient.

2.8. Proposed solution for the new system

After studying the existing system and identifying the limitations, we designed a new system
that can be provided and ensure the following features:
 Provide easy access to customer and employee information
 Satisfy customer’s needs and demands
 Ensure a fast and accurate ordering system
 Provide system simplicity, reliability, fast, user-friendly, and reliable work
 Provide very Secured data keeping (unauthorized users can’t access the system)
 Make a system easy to modify the existing data and employee information
2.9. Overview of the Proposed System

The proposed system will have an android-based menu with a user-friendly GUI. One can
make their order in a hotel easily without the assistance of a waiter. This android application
enables the end users to run the application, select the food from the menu item, and order
food in an android app. The customer usually knows of any dishes that are unavailable before
taking an order. The system must confirm the availability of dishes. Dishes to be prepared are
sent to the kitchen. The kitchen staff sees the dish orders on their screen, prepare them in an
appropriate sequence, and confirms preparation to the system when complete. When a waiter
sees the completion indications on his terminal, he collects the items and takes them to the
table. At the end of the meal, the cashier will have the system print a bill with payment detail.
This system will bring efficiency to the whole establishment by removing the human error
factor because when the customer makes the order the system will indicate the table is
‘occupied’ and the interface will show what they ordered throughout the dining experience
while allowing the customers to give feedback on the food they ordered and when the
customer has paid their bills the table will be ‘closed’ indicating the customer is done using
the hotel service and the program resets back to the food menu.
The proposed system provides the following functionalities: -
 Display food description and nutrition facts about the food.
 Dishes to be prepared are sent to the kitchen.
 The kitchen staff sees the dish orders on their screen, prepare them in an appropriate
sequence, and confirms preparation to the system when complete.
 The user is given a Username and Password to be a member of the hotel.

2.10. Requirements of the Proposed System

2.10.1. Functional requirement
Functional requirements are the description of the facility or feature required. Functional
requirements deal with what the system should do or provide for users. They include a
description of the required functions, outlines of associated reports or online queries, and
details of data to be held in the system [5].
The functional requirement of our system’s actor includes the following: -
FR1: Login – The system shall allow the users to login.
FR2: Manage Account – The system should allow the administrator to create
/update/delete/view employee accounts.
FR3: Manage Menu – The system should allow the Manager to add /update/delete/view
menu.
FR4: Assign table numbers for waiters – The system should allow the manager to assign table
numbers for the waiters
FR5: View comments – The system should allow the manager to view the given comments.
FR6: View report – The system should allow the manager to view daily, weekly, monthly and
yearly reports.
FR7: View menu – The system should allow the users to view the menu.
FR8: Manage cart – The system should allow the customer to view the cart, remove menu
items from cart and confirm cart.
FR9: Place order – The system should allow the customer to place orders using their phone.
FR10: View orders – The system should allow the customer and employees to view orders
with their details.
FR11: Add remark – The system should allow the customer to add remarks for every item
he/she orders.
FR12: Call waiters – The system should allow the customer to call waiters for assistance on
the application.
FR13: Give comment – The system should allow the customer to give comments.
FR14: View order history – The system should allow the customer to view history of orders
he/she made before.
FR15: Accept alert – The system should allow the waiter accept alerts when called from
customers.

FR16: Assign courier – The system should allow the cashier to assign courier for delivery
orders after they have been processed by kitchen staff.
FR17: Approve/Reject order – The system should allow the cashier and waiters approve and
reject order requests.
FR18: View customer location– The system should allow the courier to view customer
location to deliver the order.
FR19: Make phone call – The system should allow the courier to make a phone call to the
customer when delivering the order.
FR20: Register raw materials – The system should allow the purchaser register raw materials
needed to be purchased.
FR21: View remaining items – The system should allow the purchaser to view the remaining
quantity of items.
FR22: Register daily usage – The system should allow the purchaser register daily usage of
raw materials.
FR23: Account management – The system should allow the users to manage their personal
account.
FR24: Password recovery – The system should allow password recovery by email to the user
when password is lost.
FR25: Logout– The system should allow the users to logout from the system.
2.10.2. Non-functional requirements

Non-Functional Requirements are those requirements that have nothing to do with the
functionality of the system but they determine the performance of the whole system. Some of
the non-functional requirements for the proposed system are: -
Usability: The system provides a help and support menu in all interfaces for the user to
interact with the system.
Accuracy: the proposed system will be better due to the reduction of error. All operations can
be done correctly and it ensures that whatever information is coming from the database is
accurate.
Reliability: The reliability of the proposed system will be better due to the proper storage of
information when users access the application.
Availability: All data in the system will be available all the time.
Efficiency: The system will ensure allocation and use of services being requested for the
users by using minimum memory storage, cost, time, and human power.

Security: We will use MD5 hashing technique to ensure password security

Performance: The system will work at a high-performance rate when executing users’ orders
and responding within a short time.
Error Handling: When a user interacts with the system errors may occur. To control this
kind of inaccuracy the application will generate different user-friendly messages. To do this,
most of the system execution buttons will be controlled according to the sequence that the
user is expected to follow, or this can be done by generating different system responses to the
input of the user.
User Interface: The system we are going to develop will have a user-friendly Graphical User
Interface (GUI) which allows users to interact with the system easily.
2.11. Modeling the Existing Systems

2.11.1. Essential Use Case Modeling
An essential use case model often referred to as a business use case model or abstract use
case model, models technology independent view of behavioral requirements. It is the
fundamental aspect of user-centered design.

Figure 2. 2 Essential use case diagram

2.11.2 Domain modeling with Class Responsibility Collaboration (CRC)
CRC is a collection of standard index cards that have been divided into three sections.
 A class: represents a collection of similar objects. The name of the class appears on
the top of the card.
 A responsibility is something that a class knows or does. Responsibilities are shown
on the left-hand column of a CRC card.
 A collaborator is another class that a class interacts with to fulfill its responsibilities.
A class will have a responsibility to fulfill, but will not have enough information to do
it. When this happens, it has to collaborate with other classes to get the job done. The
collaborators of a class are shown in the right-hand column of a CRC card.
Table 2. 1 CRC for Menu Item

Menu Item
Id Customer
name manager
description waiter
manageMenu() kitchen staff
updateStatus() cart
viewMenu()
addToCart()
Table 2. 2 CRC for Cart

Cart
cart_number Customer
getTotalPrice() Waiter
manageCart()
Table 2. 3 CRC for Order Report

Order Report
Order_number Manager
date cashier
viewDailyReport() order
viewWeeklyReport ()

viewMonthlyReport ()
viewYearlyReport ()
Table 2. 4 CRC for Bill

Bill
bill_number cashier
date waiter
computeTotalPrice() customer
view()
print()
pay()
Table 2. 5 CRC for Order

Order
order_number customer
order_date waiter
order_status cashier
placeOrder()
view()
updateStatus()
Table 2. 6 CRC for a Alert

Alert
Id customer
caller waiter
message
date
viewAlert()

Chapter 3: System Analysis

3.1 Introduction
This chapter focuses on developing the requirement and analysis models for the new system
using the UML use case model, sequence diagram, activity diagram, and class diagram, and
interface prototyping is also included.
3.2 Modelling the Proposed System

3.2.1 Use Case Model
Use cases describe the functional behavior of the system as seen by the user. It is a sequence
of action that provides a measurable value to an actor. Another way to look at it is that a use
case describes a way in which a real-world interacts with the system.
An essential use case is sometimes called a business, the case is a simplified, abstract,
generalized use case that captures the intention of the user in a technology and
implementation independent manner.
❖ In the proposed system a use case describes a sequence of action that provides a
measurable value to an actor and is drawn as a horizontal ellipse.
❖ An actor is a person in the proposed system that plays a role in one or more
interactions with the system.
3.2.1.1 Actor and Use Case Identification

In this project, we have eight actors each has its use case:
Administrator: - controls the whole system and manages the account.
Customer: - view menu, view details of a menu item, add an item to the cart, review their
cart, remove the item from the cart, login, password recover, view payment detail, place
order, view order detail, and give feedback.
Manager: the manager manages the whole activity which includes managing the menu,
viewing a report, assigning a table, and viewing feedback.
Waiter: accept alert, update order status.
Courier: view customer location for delivery, call to customer.
Kitchen staff: View order, update order status, and view order details.
Cashier: Accept orders, view orders, view order details, print bills, and assign waiter to
deliver food outside the hotel.

Purchaser: Register materials to be purchased, view remaining items and enter daily usage.
3.2.1.2 Use Case Diagram

A UML use case diagram shows the relationships among actors and uses cases within a
system. A use case diagram is a graphic representation of the interactions among the elements
of a system [6].
The UML notation for use has the following three elements.
 An oval represents a use case,
 A stick figure represents an actor,
 An arrow between an actor and a use case represents that the actor initiates and/or
participates in the process.

Figure 3. 1 System use case diagram

3.2.2 Use case Description
Much of the use-case model is, textual, with the text captured in the use-case specifications
that are associated with each use-case model element. These specifications describe the flow
of events of the use case.

Use case number UC-01

Use case Name Log in
Participating Admin, Manager, Waiter, Kitchen staff, Cashier, purchaser, and
actors Customer
Description This use case describes how each stakeholder login into the System.
Precondition To be registered either by the admin or by themselves
Postcondition If the use case was successful, the actor is now logged into the system.
Basic course of Actor action System response
action 1. The user starts the system 3. System displays a login form
2. The user clicks the login link 6. The system verifies the password
4. The user enters username and username
and password 7. If the username and password are
5. The user clicks the login valid the system displays a success
button message
8. use case ends
Alternative 6.1 The system displays an error message and redirects to the login
course of action page.
Table 3. 1 Login - use case description
Use-Case Number UC-02

Use-Case Name Add Menu Item
Actor Manager
Description This use case allows the manager to add a new Menu item detail into
the menu
Precondition login
Post Condition New menu item added
action 1. The manager first logs in to the 4. The system displays add
system. menu item form.
2. The manager clicks “menu” from 6. The system verifies that the
the home page. basic fields have been filled
3. The manager clicks on the “add else 6.1.

menu item” button 7. The system inserts the

5. The manager enters full newly added data into the
information about the menu item to database.
be added and clicks the ‘add’ button. 8. The system notifies that
registration is successful
9. use case ends.
An alternative 6.1 the system indicates that the fields have not been filled correctly.
course of action and the system goes back to step 4
Table 3. 2 Add Menu Item Use Case Description
Use-Case UC-03
Number
Use-Case Name Create employee account
Actor Administrator
Description This use case allows the Administrator to create a new employee
account
Precondition login
Post Condition New employee registered
action 1. The Administrator first logs in to the 4. The system displays create
system. employee detail form.
2. The Administrator clicks on the 6. The system verifies that the
“Manage Employee” button basic fields have been filled
3. The Administrator clicks on the else 6.1.
“create employee account” button 7. The system inserts the

5. The Administrator enters full newly added data into the
information about the employee to be database
registered and clicks the ‘create’
8. The system notifies that
button.
9. use case ends.
An alternative 6.1 the system indicates that the fields have not been filled correctly and
course of action the system goes back to step 4
Table 3. 3 Create employee account Use Case Description


Use-Case Name Update Menu Item
Actor Manager
Description This use case allows the Manager to update the existing menu item
detail
Precondition The manager must add a menu item
Post Condition Existing menu item detail updated
action 1. The Manager first logs in to the 4. The system allows the
system. manager to search menu
2. The Manager clicks on the items by their name.
“Menu” button 6. The system verifies the
3. The Manager clicks on the menu item name
“update menu item” button.
7. The system displays the
5. The manager enters the menu
detail of the searched menu
item name to be updated.
item. else 7.1
9. The Manager modifies menu
8. The system allows
item detail and submits them.
Manager to edit basic menu
item information.
10. The system inserts the
modified data into the
database
11. the use case ends.
An alternative 7.1 the system notifies the manager that he entered an invalid menu
course of action item name. and the system goes back to step 4
Table 3. 4 Update Menu Item Use Case Description

Use-Case Name Update Employee account
Actor Administrator
Description This use case allows the Administrator to update the existing
employee account
Precondition The administrator must register employees first to update

Post Condition Existing employee account updated

action 1. The Administrator first logs in to 4. The system allows the
the system... Administrator to search
2. The Administrator clicks on employees by his/her
“Manage employee account” from username.
the navigation bar.
6. The system verifies the
3. The Administrator clicks on the
employee's username
“update employee account” button.
7. The system displays the
5. The Administrator enters the
detailed information of the
employee username to be updated
searched employee. else 7.1
9. The Administrator modifies the 8. The system allows the
employee account and submits it. Administrator to edit basic
employee information.
10. The system inserts the
modified data into the
database
Alternative course 7.1 the system notifies the Administrator that he enters an invalid
of action employee username and the system goes back to step 4
Table 3. 5 Update Employee Detail Use Case Description

Use-Case Name Delete Menu Item
Actor Manager
Description This use case allows the Manager to remove the existing menu item
detail.
Precondition There must be added menu item to be removed.
Post Condition Menu item removed
action 1. The Manager first logs in to the 4. The system allows the
system. manager to search menu
2. The Manager clicks on the items by their name.

“menu” button from the navigation 6. The system verifies the

bar. menu item name
3. The Manager clicks on the 7. The system displays the
“delete menu item” button. detail of the searched menu
5. The manager enters the menu item. else 7.1
item name to be deleted 8. The system allow Manager
9. The Manager clicks on the to delete menu item
‘delete’ button 10. The system removes the
menu item detail from the
database
Alternative course 7.1 the system notifies the manager that he entered an invalid menu
of action item name. and the system goes back to step 4
Table 3. 6 Delete Menu Item Use Case Description

Use-Case Name Delete Employee account
Actor Administrator
Description This use case allows the Administrator to remove the existing
employee account.
Precondition There must be a registered employee account to be removed.
Post Condition Employee account removed
action 1. The Administrator first logs 4. The system allows the
in to the system. Administrator to search employee
2. The Administrator clicks on accounts by his/her username
“Manage employee” from the 6. The system verifies the
navigation bar. employee's username
3. The Administrator clicks on 7. The system displays the detail
the “delete employee account” of the searched employee. else
button. 7.1
5. The Administrator enters the 8. The system allows the
employee username to be Administrator to delete employee
deleted.

9. The Administrator clicks on accounts.

the ‘delete’ button. 10. The system removes the
employee detail from the database
Alternative course 7.1 the system notify the manager that he entered an invalid
of action employee name/ID. and the system goes back to step 4
Table 3. 7 Delete Employee Detail Use Case Description
Use-case Number UC-08

Use-Case Name View Feedback
Actor Manager
Description This use case allows the manager to view feedback that is sent from
the customer
Precondition First feedback must be sent from the customer
Post-condition If the use case was successful, the Manager can view the feedback.
action 1. The Manager logs in to the 3. The system displays a list of
system unseen feedback.
2. The Manager click on ‘view 5. The system displays the detail
feedback” from the navigation of that particular feedback
bar 6. The system adds that particular
4. The manager clicks on the feedback into seen feedback
‘detail’ button for particular database 7. use case ends
feedback
Table 3. 8 View Feedback Use Case Description

Use-Case Name Assign Table Number
Actor Manager
Description This use case allows the manager to assign table number for each
waiter
Precondition The water must be present
Post-condition If the use case was successful, the Manager can assign a table

number for each waiter.

action 1. The manager first logs in to the 3. The system search for that
system. particular employee and if
2. The Manager search for an found displays employee info.
employee to be assigned from the else 3.1
assigned table no <<UI>> 6. The system adds the
4. The Manager writes the table assigned table number of the
number for the selected employee. employee into the database
5. The manager clicks on the 7. use case ends
‘assign’ button
Alternative course 3.1 No such employee was found. Go back to step 1
of action
Table 3. 9 Assign table number Use Case Description

Use-Case Name Log out
Actor Administrator, Manager, Waiter, Kitchen staff, purchaser, Customer,
and Cashier
Description These use case the listed actors to log out from the system at a time
of accomplishing their work.
Precondition Login
Post Condition The System saves the data into the session or the database and then
logout from the system.
action 1. The user wants to log out from 3. The system removes the
the system. session and redirects to the
2. The user clicks the log-out login page.
button 4. use case ends
Table 3. 10 Logout Use case Description

Use-Case Name Add Menu Item to cart
Actor Customer

Description This use case allows the customer to add /her desired menu item into
the cart
Precondition No precondition
Post-condition If the use case was successful, the customer can add a list of menu
items to his /her cart.
action 1. The Customer searches for the 2. If found the system displays
desired item from the menu item the searched item info. else 2.1
list 5. The system adds that
3. The Customer can view detailed particular menu item into the
info about the item including the cart
item description. 6. The system display item
4. The customer clicks on the ‘cart was added successfully.
icon’ for a particular menu item 7. use case ends
Alternative course 2.1 the searched menu item is not found. Go back to step 1
of action
Table 3. 11 Add Menu Item to cart Use Case Description

Use-Case Name View Payment Detail
Actor Customer
Description This use case allows the customer to view the total payment detail
that he is going to pay.
Precondition First, the customer must add an item to the cart
Post-condition If the use case was successful, the customer can view his/her total
payment detail.
action 1. The Customer first clicks on the 2. The system display menu
‘cart icon’ items which are added to the
3. The Customer views his/her total cart else 2.1
payment detail 4. use case ends
Alternative course 2.1 No item added to cart. Go back to step 1
of action
Table 3. 12 View Payment Detail Use Case Description


Use-Case Name Write Remark
Actor Customer
Description This use case allows the customer to write remark (comment) for
every item he has ordered
Precondition The customer has to navigate into the detail of a particular menu
item
Post-condition If the use case was successful, the customer can add his remark into
the database, which is later viewed by the kitchen staff
action 1. The Customer navigate to detail 3. The system display remark
of a particular item <<UI>>
2. The Customer clicks on the 5. The system adds that
‘remark’ button. remark into the database
4. The customer writes his/her 6. use case ends
remark and submits
Table 3. 13 Write Remark Use Case Description

Use-Case Name Give Feedback
Actor Customer
Description This use case allows the customer to write feedback (comment) for
the manager
Precondition The customer must be registered and logged in
Post-condition If the use case was successful, the customer can add his/her feedback
into the database, which is later viewed by the manager.
action 1. The Customer clicks on 2. The system displays feedback
‘feedback’ button from theforms.
navigation bar 4. The system notifies that
3. The Customer writes his feedback sent to the manager
feedback and submits it. successful else 4.1.
7. use case ends

Alternative course 4.1 the system indicates that the fields have not been filled correctly.
of action and the system goes back to step 2
Table 3. 14 Give Feedback Use Case Description

Use-Case Name Review cart
Actor Customer
Description This use case allows the customer to review their cart
Precondition First, the customer has to add an item to the cart
Post-condition If the use case was successful, the customer can view all item which
is added to their cart
3. The Customer view all of cart else 2.1
his/her items which is added to the 4. use case ends
cart
Alternative course 2.1 no item added to cart
of action
Table 3. 15 Review cart Use Case Description

Use-Case Name Remove item from cart
Actor Customer
Description This use case allows the customer to remove the item from their cart
Post-condition If the use case was successful, the customer can remove items that
are added to their cart
3. The Customer selects and cart else 2.1
removes items from his/her cart 4. use case ends
of action

Table 3. 16 Remove item from cart Use Case Description

Use-Case Name Place an order
Actor Customer
Description This use case allows the customer to confirm their cart item to be
sent to the Kitchen staff
Post-condition If the use case was successful, the customer can send (order) the cart
item to the cashier
3. The Customer clicks on the cart else 2.1
‘order’ button 4. The system adds all the
cart items to the order table.
5. use case ends
of action
Table 3. 17 Place order Case Description

Use-Case Name View Menu
Actor Manager, Customer
Description This use case allows managers and customers to view the menu
Precondition None
Post-condition If the use case was successful, the Manager and customer can view
the menu.
action 1. The actors log in to the system 3. The system displays a
2. The actors click on the ‘menu” menu.
from the navigation bar 5. The system displays the
4. The actors click on the ‘detail’ detail of that particular item
button for a particular item. 6. use case ends
Table 3. 18 View menu Use Case Description


Use-Case Name Add raw materials
Actor purchaser
Description This use case allows the purchaser to add raw material details into
the system
Precondition login
Post Condition Raw materials added
action 1. The purchaser first logs in to the 3. The system displays add
system. raw material form.
2. The purchaser clicks “Add raw 5. The system verifies that the
material” from the home page. basic fields have been filled
4. The purchaser enters full else 5.1.
information about the material to be 6. The system inserts the
added and clicks the ‘add’ button. newly added data into the
database.
8. use case ends
Alternative course 5.1 the system indicates that the fields have not been filled correctly.
of action and the system goes back to step 4
Table 3. 19 add raw materials Use Case Description

Use-Case Name Register daily usage
Actor purchaser
Description This use case allows the purchaser to register daily usage of items into
the system
Precondition login
Post Condition The remaining quantity of items calculated
action 1. The purchaser first logs in 3. The system displays a list of
to the system. available items with the remaining
2. The purchaser clicks “daily

usage” from the home page. quantity

3. The purchaser clicks a 4. The system display input form
particular item from the home 6. The system verifies that the basic
page. fields have been filled else 6.1.
5. The purchaser enters daily 7. The system subtracts the quantity
usage and clicks the ‘add’ from the database
button. 8. The system notifies the
9. use case ends
Alternative course 6.1 the system indicates that the fields have not been filled correctly
of action and then go back to step 5.
Table 3. 20 Register daily usage Use Case Description

Use-Case Name Accept Alert
Actor Waiter
Description This use case allows the waiter to get alert when he/she is called.
Precondition First, waiter has to be called.
Post-condition If the use case was successful, the waiter can accept an alert
action 1. The waiter first needs to login into 3. The system provides
the system notification for the waiter
2. The waiter clicks on ‘view when he/she is called by
notification’ from the navigation bar. one of the above actors.
4. The waiter clicks on ‘detail’ 5. The system displays the
button for a particular alert detail of that particular alert
6. The system adds that
particular alert into a seen
alert database
7. use case ends.
Table 3. 21 Accept Alert Use Case Description

Use-Case Name Call Waiter
Actor Customer

Description This use case allows all the customers to call the waiter for any
assistance
Precondition No precondition
Post-condition If the use case was successful, all the actors will call the waiter
action 1. The customer first clicks on the ‘call 3. The system notifies the
waiter’ button which is found in the waiter from whom he/she is
navigation bar. called
2. The customer enters the table 4. use case ends.
number which he/she sat and clicks
submit
Table 3. 22 Call Waiter Use Case Description

Use-Case Name View Detail of the ordered item
Actor Customer, cashier, kitchen staff
Description This use case allows the above actors to view the ordered menu item
from the customer
Precondition A customer has to order menu items first
Post-condition If the use case was successful, the actors can view the detail of the
ordered item
action 1. The actors first need to log in. 3. The system display list
2. The actors click “orders” from the of ordered items
navigation view 5. The system display
4. The actors click on the particular detail of the order.
order 6. use case ends
Table 3. 23 View detail of ordered item Use Case Description

Use-Case Name Update Order Status
Actor Kitchen staff, cashier, waiter

Description This use case allows the above actors to update the order status
Precondition An item must be ordered by the customer.
Post-condition If the use case was successful, the above actors can update the status
of the order
action 1. The actors view list ordered menu 3. The system provides
item detail notifications for the
2. The actors select a particular customers while their order
customers order and update the state of status is updated.
that order as preparing or delivering 4. use case ends
accordingly
Table 3. 24 update order status Use Case Description

Use-Case Name Assign waiter
Actor Cashier
Description This use case allows the cashier to assign a waiter after the ordered
item is ready to be delivered out of the hotel.
Precondition An item must be ordered by the customer
Post-condition If the use case was successful, the cashier can assign a waiter when
the food is ready to be delivered
action 1. The cashier clicks on the ‘details’ 2. The system displays the
button specific order available waiter
3. The cashier clicks on the ‘assign 4. The system alert the
waiter’ button waiter with the detail of the
order
5. use case ends
Table 3. 25 Assign waiter when the item is ready to be delivered Use Case Description

Use-Case Name View customer location
Actor Waiter
Description This use case allows the waiter to view the customer's location

Precondition The item has to be ready to deliver

Post-condition If the use case was successful, the waiter can see the customer's
location.
action 1. The waiter first needs to log in to the 2. The system show orders
system. 5. The system display
3. The waiter clicks the ‘orders’ button details of the order
4. The waiter click on the ‘details’ of a 7. the system shows the
particular order location
6. The waiter clicks the “view 8. use case ends
location” button
Table 3. 26 View customer location

Use-Case Name Recover password
Actor Customer
Description This use case allows the Customer to recover the password
Precondition Customers must be registered
Post-condition If the use case was successful, the customer can get his old password
action 1. The customer click forgot password 2. The system display input
button form
3. The customer enters the email 5. The system verifies the
4. The customer clicks the ‘send email’ email is filled correctly else
button 5.1
password sent to the email
7. use case ends
Alternative course 5.1 the system indicates that the fields have not been filled correctly
of action and then goes back to step 3.
Table 3. 27 Recover password

Use-Case Name View order history

Actor Customer
Description This use case allows the customer to review their order history
Precondition First, the customer has to order
Post-condition If the use case was successful, the customer can view all his/her
orders.
action 1. The Customer first clicks on the 2. The system displays the
‘order history’ orders of the user else 2.1
3. The Customer view all of his/her 4. use case ends
orders which are previously ordered
Alternative course 2.1 no orders placed
of action
Table 3. 28 view order history
3.2.3 Sequence Diagram

Sequence diagrams show the interaction between participating objects in a given use case.
They are helpful to identify the missing objects that are not identified in the analysis object
model. To see the interaction between objects, the following describes the sequence diagram
of some of the identified use cases. Sequence diagrams graphically document the use case by
showing the classes, the messages, & the timing of the messages.

Figure 3. 2 login - sequence diagram
Figure 3. 3 add menu item - sequence diagram

Figure 3. 4 Create employee account - sequence diagram

Figure 3. 5 update menu item - sequence diagram

Figure 3. 6 update employee account- sequence diagram

Figure 3. 7 delete menu item- sequence diagram

Figure 3. 8 add item to cart- sequence diagram

Figure 3. 9 Call waiter- sequence diagram

3.2.4 Activity Diagrams

An activity diagram is a flowchart to represent the flow from one activity to another activity.
The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be sequential,
branched, or concurrent. Activity diagrams deal with all types of flow control by using
different elements such as fork, and join.
Figure 3. 10 Login - Activity Diagram

Figure 3. 11 Add menu item - Activity Diagram

Figure 3. 12 Create Employee Account - Activity Diagram

Figure 3. 13 Delete menu item- Activity Diagram

Figure 3. 14 Add item to the cart- Activity Diagram

Figure 3. 15 view payment detail - Activity Diagram

Figure 3. 16 remove item from the cart - Activity Diagram

Figure 3. 17 Logout- Activity Diagram

3.2.5 Analysis class Diagram

Class diagrams are one of the most useful types of diagrams in UML to map out the
structure of a particular system by modeling its classes, attributes, operations, and
relationships between objects [7].
Figure 3. 18 analysis level class diagram

3.2.6 User Interface Prototyping

A user-interface flow diagram is used to model the interactions that users have with our
software, as defined in a single use case. They enable us to gain a high-level overview of the
user interface for our application. Prototyping is well suited to develop and communicate a
vision of the future system among the members of the development team [8].
Figure 3. 19 User interface prototyping

CHAPTER FOUR: System Design

4.1 Introduction
System Design is the process of defining the architecture, components, Modules, Interfaces,
Deployment, and data for a system to satisfy the specified requirements. In the case of our
project the team members used object-oriented analysis and design methods. This object-
oriented method is the most widely used methods for systems design and analysis. The UML
has become the standard language in object-oriented analysis and design.
In this chapter we will deal with different design structures of the proposed system that
indicate how the system is designed, data is retrieved from the database, client and server are
interacted with the system and how deploying and decomposing is structured. The main idea
of this system design document is to describe the system design activities to be carried out
during the design phase of the System. It contains simultaneous sections the former section of
the document depicts the design to be considered in the implementation phase of the project
that is the primary design goal. The second section of the document describes the proposed
system which is the system to be developed. In this section there are a lot of structural issues
to be talked about. It describes the subsystems that will be combined to make the whole
system. It depicts the architecture of the database and the applications. It explains the
persistent data management, design of the system and how access is going to be controlled
among the different users of the system towards the operations. At the end of the chapter
sample interface design will be described.
4.2 Class type architecture

System architecture is the means of designing the system based on class or layers. Layering is
the concept of organizing the system software design into layers/collections of classes or
components that fulfill a common purpose, such as implementing the user interface or the
business logic of the system.

Figure 4. 1 Class type Architecture
Table 4. 1 Class type Architecture

Layers Descriptions
Interface (User Interface) layer The interface layer is the layer in which the user relates with
the system.
Process (application and controller) This layer consists of system interface and user interface (UI)
Layer classes that provide people access to our system.
Business (Domain) Layer This layer implements and link the user data within the
business objects, which means it validate the required data
with the existing data for its correctness.
Data (Persistence) Layer Persistence layers summarize the capability to store and delete
data and it is the class layer in which all data about the user
and the file are stored and accessed.
System Layer This layer includes communicate all of the remaining four
layers.
4.3 Class Modeling

In the diagram, classes are represented with boxes that contain three compartments:
1. Classes: The top compartment shows the class's name.

2. Attributes: The attribute section of a class (the middle compartment) lists each of the
class's attributes on a separate line. The attribute section is optional, but when used it

contains each attribute of the class displayed in a list format. The line uses the
following format.
3. Operations: The class's operations are documented in the third (lowest) compartment
of the class diagram's rectangle, which again is optional. Like the attributes, the
operations of a class are displayed in a list format, with each operation on its own
line.
4. Associations: An association relation is established when two classes are connected
to each other in any way. When you model a system, certain objects will be related to
each other, and these relationships themselves need to be modelled for clarity.
Figure 4. 2 Class diagram

4.4 State Chart Modeling

State chart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered.
So, the most important purpose of State chart diagram is to model life time of an object from
creation to termination.
Figure 4. 3 State chart diagram for login
Figure 4. 4 State chart diagram for add menu item

Figure 4. 5 State chart diagram for approve order
4.5 Collaboration Modeling

Collaboration occurs between objects when one object asks another for information or to do
something. Objects collaborate with one another by sending message to each other. A
message is either a request to do something or a request for information. A collaboration
diagram looks like a flowchart that represents the roles, functionality and behavior of
individual objects as well as the overall operation of the system in real time. Objects are
shown as rectangles with naming labels inside. These labels are preceded by colons and may
be underlined.
Figure 4. 6 Collaboration diagram for login

Figure 4. 7 Collaboration diagram for add menu item
4.6 Component Modeling

Component modeling shows which component or objects will be accessed by user. In these
modeling components of the system will be showing that there is relation among components.

Figure 4. 8 Component diagram
4.7 Deployment modeling

Deployment modeling used to show the hardware of the system, the software that is installed
in the hardware and also the middleware that is used to connect the disparate machines to one
and other. It also shows how the software and the hardware components work together.

Figure 4. 9 Deployment diagram
4.8 Persistence modeling

Persistence modeling is used to communicate the design of the database, usually the data base
to both the users and the developers. It is also used to describe the persistence data aspect of
the system. The following diagram indicates the persistence diagram of the system.

Figure 4. 10 Persistence diagram

4.9 User Interface design




CHAPTER FIVE
Implementation and Testing
5.1 Introduction to Implementation and Testing

The implementation phase is the critical phase in which it transforms the design and analysis
of the system in to tangible system by writing the code to the system to be developed and
make is operational and applicable by testing debugging the functionalities that are done.
This phase involves the construction of the actual result. During this phase the project
become visible to outsiders, to whom it may appear that the project has just began. This
makes the implementation stage more essential step to develop the required system. So, it is
the most Vital and necessary stage in archiving successful system and in giving the users that
the new system will work and be effective by testing the system that is already implemented.
The main objective of this phase is generally is to deploy and enable operation of the new
information system in the production environment.
During implementation and operation, physical design specification must be turned into
working computer code, and then the code is tested until most of the errors have been
detected and corrected. The user sites are prepared for new system and user must come totally
on the new system rather than the existing. There are some managerial activities in this,
coding and testing.
5.2 Final Testing procedures of the System

It is the final step of testing in which the entire system as a whole with all forms, code, and
modules are tested. In this procedure we have tested all the functionalities of the System. All
errors in the forms, functions, modules have been tested. Finally, System testing ensures that
the entire integrated software system meets the desired requirements. It tests a configuration
to ensure known and predictable results. To test the whole system, the team follows the
following procedures.
 Unit testing: -Every module of the System is separately tested. I.e., the team tests
every module by applying some selection mechanism. Through this mechanism every
module gets tested. If an error occurs correction will be taken without affecting
another module.

 Integrated Testing: -In this testing part, all the modules will be combined together
and tested it for its fitness with each other and with the systems functionality. If error
occurs in combining them, the module with problem will be identified and
recombined.
 User Interface Testing: - the team has conducted this testing procedure to evaluate
the GUI elements like field forms drop down box, input type length, radio button are
work properly and suitable for the users. As a result, all of these components are
working properly.
 Usability Testing: -The team has conducted this testing procedure to evaluate the
extent to which a user can learn to operate, prepare inputs for, and interpret outputs of
a system or component and the system’s user friendless.
5.3 Implementation sample Code Review

The following code shows the registration of user account.
XML code:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".Register"
android:orientation="vertical"
android:gravity="center">
<TextView
android:layout_height="40dp"
android:gravity="center"
android:layout_marginTop="10dp"
android:textColor="#000"
android:textSize="29sp"

android:text=" Register"/>
<com.google.android.material.textfield.TextInputLayout
android:layout_height="wrap_content"
android:layout_marginRight="20dp"
android:layout_marginLeft="20dp"
>
<EditText
android:id="@+id/etfullname"
android:hint="Fullname"
android:inputType="textPersonName"
/>
</com.google.android.material.textfield.TextInputLayout>
>
<EditText
android:id="@+id/etphone"
android:hint="Phone Number"
android:inputType="phone"

/>
>
<EditText
android:id="@+id/etemail"
android:hint="Email"
android:inputType="textEmailAddress"
/>
app:passwordToggleEnabled="true"
>
<EditText
android:id="@+id/etpassword"

android:hint="Enter password"
android:inputType="textPersonName"
/>
<Button
android:id="@+id/btnregister"
android:text="Register"
android:layout_marginRight="20dp"/>
<TextView
android:layout_height="40dp"
android:id="@+id/tvlogin"
android:gravity="center"
android:textColor="#000"
android:text="Already Registered? Login here"/>
</LinearLayout>
Java Code:
package com.example.restaurant_customer;
import androidx.appcompat.app.AppCompatActivity;
import android.content.Intent;
import android.os.Bundle;
import android.util.Patterns;

import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;
import android.widget.Toast;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import retrofit2.Call;
import retrofit2.Callback;
import retrofit2.Response;
import retrofit2.Retrofit;
import retrofit2.converter.gson.GsonConverterFactory;
public class Register extends AppCompatActivity {
private EditText etfullname, etphone, etemail, etpassword;
private Button btnregister;
private TextView tvlogin;
private PreferenceHelper preferenceHelper;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_register);
preferenceHelper=new PreferenceHelper(this);
etfullname = findViewById(R.id.etfullname);
etphone = findViewById(R.id.etphone);
etemail = findViewById(R.id.etemail);
etpassword = findViewById(R.id.etpassword);
btnregister= findViewById(R.id.btnregister);
tvlogin= findViewById(R.id.tvlogin);

tvlogin.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Intent intent = new Intent(Register.this,Login.class);
startActivity(intent);
Register.this.finish();
});
btnregister.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
registerMe();
});
public boolean isEmailValid(String email){
return Patterns.EMAIL_ADDRESS.matcher(email).matches();
private void registerMe() {
final String fullname = etfullname.getText().toString().trim();
final String phone = etphone.getText().toString().trim();
final String email = etemail.getText().toString().trim();
final String password = etpassword.getText().toString().trim();
if(!isEmailValid(email)){
etemail.setError("Please Enter valid Email");
return;
Gson gson=new GsonBuilder().setLenient().create();
Retrofit retrofit = new Retrofit.Builder()

.baseUrl(MyApi.BASE_URL)
.addConverterFactory(GsonConverterFactory.create(gson))
.build();
MyApi api = retrofit.create(MyApi.class);
Call<DetailsPojo> call = api.registerUser(fullname,phone,email,password);
call.enqueue(new Callback<DetailsPojo>() {
@Override
public void onResponse(Call<DetailsPojo> call, Response<DetailsPojo> response)

{
DetailsPojo pojo = response.body();
if (pojo.getStatus().equals("true")) {
preferenceHelper.putIsLogin(true);
preferenceHelper.putFullname(pojo.getFullname());
preferenceHelper.putEmail(pojo.getEmail());
preferenceHelper.putProfile(pojo.getProfile());
Toast.makeText(Register.this, "Registered Successfully!",

Toast.LENGTH_SHORT).show();
Intent intent = new Intent(Register.this, MainActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK |
Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Register.this.finish();
}else{
Toast.makeText(Register.this, pojo.getMessage(),
Toast.LENGTH_SHORT).show();
@Override
public void onFailure(Call<DetailsPojo> call, Throwable t) {
Toast.makeText(getApplicationContext(),t.toString(),Toast.LENGTH_LONG).show();

});
5.4 Hardware software acquisitions

Hardware: -
Android smart phone: to launch the android part
Computers: for the website part
Printer: To print documents
Server: To host the system
Software: -
PHP XAMPP
Edraw Max
Microsoft office 2016
5.5 User manual preparation

Since the system is easy and user friendly, everything important for the users will be
explained and implemented while giving short training when the system is deployed. There is
no need of preparing full user manual because it is only deployed (hosted) on a single
machine that is server. So, anyone who can access the internet can also access the system
easily within the given permission or role.
5.6 Installation
Installation of our proposed system at minimum requires a computer to run the web-based
program and android smartphone which is available everywhere. In addition to that server is
needed to host the project.

CHAPTER SIX
CONCLUSION AND RECOMMENDATION
6.1 Conclusion
In this project, we proposed Android based Online Restaurant Management System.
This project is an attempt to revolutionize the current working environment in the food
industry. When customers are provided with new technology which is not only path
breaking but also eye catching, it is inherent that the sales are projected to go up. The
traditional menu card system has been suffering from outdated ideas for long and
lacked graphical capabilities. The project not only brings a revolution in this aspect but
provides much more. The customer module is designed to catch customer attention and
a sense of luxury at finger tips. The main point is the amount of time saved by our
project. Since customer’s are the king, so we must take at most care that customers are
not subjected to boredom. The different modules of the project like the cashier module,
the kitchen staff module or the assistance button in the smart phone are all aimed at
saving the valuable time since we know that time is precious in today’s environment.
It can be concluded that, this system is all about sharing information, personalizing
experiences and speeding processes. based on the application: Orders are made easily;
Information needed in making order to customer is provided by the system. Receiving
orders and modifying its data is possible through the application and it also helps
manager in controlling all menu item.
6.2 Recommendation
The system that we are trying to develop may not completely work online for each
individual tasks. Because some activities of the Hotel are not integrated in the system. This
is mainly due to limited development capacity and time.
Therefore, we suggest the following features need to be incorporated in any further revision
and extension attempt.

 system can be further developed by incorporating a speech driven module

whereby the customers can speak out what they wish to order from the menu and
place the order respectively.
 Enhance User Interface by adding more user interactive features.
 Payment Options: Add different payment options such as PayPal, Cash, Gift
Cards etc.
 The system can be compatible with IOS system.

References
[1] P. Geary, “Preparation: The Creative World of the Restaurants,” 2013, pp. 27–55. doi:
10.1386/9781789383430_1.
[2] G. Bowen, “Document Analysis as a Qualitative Research Method,” Qualitative Research Journal,
vol. 9, pp. 27–40, Aug. 2009, doi: 10.3316/QRJ0902027.
[3] S. Radack, “The System Development Life Cycle (SDLC),” 2009, Accessed: Jun. 16, 2022. [Online].
Available: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=902622
[4] H. Adam, “Cost-Benefit Analysis (CBA) Definition,” 2021.
https://www.investopedia.com/terms/c/cost-benefitanalysis.asp (accessed Jun. 19, 2022).
[5] M. Matthew, “What is a Functional Requirement in Software Engineering? Specification, Types,
Examples,” 2022. https://www.guru99.com/functional-requirement-specification-example.html
(accessed Jun. 16, 2022).
[6] J. Frantiska, “Use Case Diagrams,” 2018, pp. 1–8. doi: 10.1007/978-3-319-67440-7_1.
[7] R. Ciesla, “UML Class Diagrams,” 2021, pp. 145–165. doi: 10.1007/978-1-4842-7286-2_9.
[8] D. Bäumer, W. Bischofberger, H. Lichter, and H. Züllighoven, User Interface Prototyping -
Concepts, Tools, and Experience. 1996. doi: 10.1109/ICSE.1996.493447.

Appendix 1
Interview Questions
1. What seems like your record-keeping system?

2. Who is responsible for generating reports?
3. How and when reports are generated?
4. In what format does the daily income report to the manager?
5. How the manager communicates with employees and individual users?
6. What are the missions, vision, and values of this hotel?
7. How do you create awareness among the general public?
8. What are the problems of the current system?

Appendix 2
Image shows food menus

Android Based Online Restaurant Management System 2

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Android Based Online Restaurant Management System 2

Uploaded by

Copyright:

Available Formats

Wollo University

Kombolcha Institute of Technology

Department of Computer Science

Android Based Online Restaurant Management System

for Yegofe View Hotel

Advisor: - Kibebu M (MSc)

Name ID_No Sign

1. Mohammed Bedru WOUR/0744/11 __________

2.Tsemre Wondwosen WOUR/5868/11 __________

3. Selam Tegegn WOUR/5866/11 __________

Advisor name Signature Date

1. Kibebu M. _____________ ____________

Examiners name Signature Date

1. ______________ _____________ ______________

2.2. User of Existing System.................................................................................................................12

Table 2. 1 CRC for Menu Item..............................................................................................................19

Table 3. 1 Log in - use case description................................................................................................24

Figure 3. 1 System use case diagram.....................................................................................................23

GUI……………………………………. Graphical User Interface.

HTML ………………………..………Hyper Text Markup Language.

MYSQL……………………………… Structured Query Language.

OOAD…………………………………. Object Oriented Analysis and Design

PHP…………………………………. Hypertext Preprocessor Scripting Language

UML……………………………………Unified Modeling Language.

CHAPTER ONE: INTRODUCTION

1.1 Background of the Study

1.2 Background of the Organization

DEPARTMENT OF COMPUTER SCIENCE 1

1.3 Statement of the Problem

1.4 Objectives of the Project

1.4.2 Specific Objective

DEPARTMENT OF COMPUTER SCIENCE 2

1.5. Scope and limitation of the project

DEPARTMENT OF COMPUTER SCIENCE 3

 The system does not include payroll

1.6. Significance of the Project

1.7 Methodology of the Project

1.7.1 Data Collection Methodologies

DEPARTMENT OF COMPUTER SCIENCE 4

An interview is a two-way conversation. It is a personal form of communication between two

1.7.2 System Analysis and Design Methodology

1.7.3 System Development Model

DEPARTMENT OF COMPUTER SCIENCE 5

Figure 1. 1 Iterative Model

DEPARTMENT OF COMPUTER SCIENCE 6

 PHP: Hypertext Preprocessor is a widely used, general-purpose scripting language

1.7.5 Testing Methodology

DEPARTMENT OF COMPUTER SCIENCE 7

1.8 Feasibility Study

1.8.1 Technical Feasibility

1.8.2 Operational Feasibility

1.8.3 Political Feasibility

1.8.4 Economic Feasibility

DEPARTMENT OF COMPUTER SCIENCE 8

Table 1. 2 Net Benefit of the project

DEPARTMENT OF COMPUTER SCIENCE 9

1.9 Budget of the Project

Tools Item Quantity Estimated Unit Estimated Total

1.10 Team Composition

1 WOUR/0744/11 Mohammed Bedru In All Activities

1.11 Work Plan of the Project

DEPARTMENT OF COMPUTER SCIENCE 10

1. Kibebu M. _

1. ________ _ ________