Palestine Techinical University (PTU) : Software Engineering Requirements Document

Palestine Techinical University (PTU)
Faculty of Engineering and Technology

Department of Computer Systems Engineering
Software Engineering Requirements Document

Online Food Ordering & Delivery Management System
Submitted By:
Student's Name Student's ID
Fares Hatem T. Abuali 201810408

Huthaifa Jamal H. Salman 201810018
Asseel Khalid H. Al-Ali 201810232
Abdullah Awad M. Al-Wawi 201810775
Ahmad Othman A. Marei 201811346
Submitted On: April 20, 2021
Assignment #2: This document was submitted in partial fulfilment of

the requirement for the "Software Engineering" course, during the
academic year 2020-2021 (2nd Semester).
Table of Contents
CHAPTER 1 INTRODUCTION …………………………………………………………………………………………………………… 1
1.1 Project Overview & Background....................................................................................... 1
1.2 Project Domain ................................................................................................................ 1
1.3 Project Objectives ............................................................................................................ 1
1.4 Project Scope ................................................................................................................... 2
1.5 Chapter Summary ………………………………………………………………………………………………….…… 2
CHAPTER 2 REQUIREMENTS GATHERING APPROACH ……………………………………………………………………. 3
CHAPTER 3 USER REQUIREMENTS DEFINITION ………..……………………………………………………………………. 3
3.1 Functional User Requirements ……………………………………………………………………………………. 3
3.1 Non-Functional User Requirements ……………………………………………………………………………. 4
CHAPTER 4 SYSTEM ARCHITECTURE ……………………….………………………………………………………………….…. 6
4.1 What is Outside the System’s Borders ………………………………………………………………………… 6
4.2 Context Diagram …………………………………………………………………………………………………………. 7
CHAPTER 5 SYSTEM REQUIREMENTS SPECIFICATION ……………………………………………………………………. 7
5.1 FUNCTIONAL SYSTEM REQUIREMENTS ………………………………………………………………………. 7
5.2 NON-FUNCTIONAL SYSTEM-REQUIREMENTS ………………………………………….………………… 11
CHAPTER 6 SYSTEM MODELS ………………….……………….………………………………………………………………….. 12
6.1 Use-case Diagrams …………………….…………………………………………………….……………………….. 12
6.2 Class Diagram .…………………….…………………………………………………….……………………………… 14
6.3 Activity Diagrams …………………….…………………………………………………….……………………….… 15
6.4 Sequence Diagram …….…………….…………………………………………………….……………………….… 18
CHAPTER 7 SYSTEM EVOLUTION …………………….…………………………………………………………………………… 23
CHAPTER 8 PLAN FOR REST OF WORK …………………………………….…………………………………………………… 24
CHAPTER 9 CONCLUSION ……………………………………………………………………………………….……………………. 24
REFERENCES ………………………………………………………………………………………………………………………………… 25
FOOD ORDERING AND DELIVERY MANAGEMENT SYSTEM
CHAPTER 1: INTRODUCTION
1.1 Project Overview & Background:

In today’s age of fast food and take-out, many restaurants have chosen to focus on quick
preparation and speedy delivery of orders rather than offering a rich dining experience. Until
very recently, all these delivery orders were placed over the phone calls, but there are many
disadvantages to this system, including:
• The inconvenience of the customer needing to have a physical copy of the menu.
• Lack of a visual confirmation that the order was placed correctly.
• The necessity for the restaurant to have an employee answering the phone and taking orders.
Hence, the need to create an intelligent and innovative system that helps facilitate the
communication between restaurants and their customers is becoming more and more necessary.
1.2 Problem Domain:
The challenges encountered by the existing traditional ordering system serve as a major
drawback to the realization of efficiency and customer satisfaction. The experience of ordering
in most fast-food restaurants is not pleasant for the customers:
• Customers will have to make long queues before placing their orders especially during peak
hours.
• Then the ordering staff will record customer orders manually.
• Having placed their order, the customer must then wait near the counter until their order is
ready for collection.
• Manual work hinders the efficiency and reduces data accuracy during order placement
process.
1.3 Project Objectives:
Our project is aimed at developing a complete online ordering system for use in the food service
industry which will allow the restaurants to quickly and easily manage an online menu which
customer can browse and use to place orders with just a few clicks.
How We Propose to Address the Diagnosed Problems:
• Create an archive for restaurants:

We are aiming to provide a treatment for the previous stated problems by helping customers
order what they want from any restaurant they desire. This can be achieved by making a
dedicated database for restaurants to store as many restaurants in Palestinian cities as possible.
1
CHAPTER 1 INTRODUCTION
And another database for users to store their data and make it easy to link each user with their
specific order.
• Save time:
By providing a delivery service, customers are able to state their order by using few clicks of
mouse and few search keywords thus saving their valuable time. This will increase customer
satisfaction by speeding up food delivery.
• Security of data:
Data are well protected for personal use.
• Minimized manual data entry:
Automation ensures data accuracy during order placement process. To sum up, what we
propose is an online ordering system, which is a technique of ordering foods online applicable
in any food delivery industry. The main advantage of our system is that it greatly simplifies the
ordering process for both the customer and the restaurant.
At the end of the project, it will improve the restaurants productivity, efficiency, and as well as
accurateness. Because of this system, it will minimize all the manual work by replacing the
traditional order system into a computer system. It will eliminate the manual work such as
workers physically deliver food order ticket into the kitchen, manually replace the price tag of
the food, and manually calculate billing price.
1.4 Project Scope:
The system will be a web-based platform will be developed to let the user view the menu card
information of the restaurant and then place an order via the system.
the system will be able to let each restaurant’s staff to update and make changes to their food
and beverage menu information. Next, it also allows staffs to generate report that they wish to
generate, such as monthly sales report. The most important function is to allow staffs to make
billing statement for consumer to make their payment after they order.
1.5 Chapter Summary:
This chapter has discussed the difficulties issues that come together with the traditional
approach for restaurant food ordering system. In addition, we have mentioned the stakeholders,
or the people who are facing a problem in the current situation and how they will benefit from
the proposed treatment that we will offer.
Lastly, the project objective and project scope have been listed and discussed. The overall
structure of the proposed system has been justified and project contribution is stated. Next,
will be further discussing about the concept of existing restaurant management system.
2
CHAPTER 1 INTRODUCTION
CHAPTER 2: REQUIREMENTS GATHERING APPROACH
At the beginning, we were lost and confused about how food ordering and food delivery
management systems work! So we went to the internet and visited some locally popular food
ordering websites here in Palestine, to state for example: http://www.pal-eat.com/ or this:
https://www.doordash.com/en-US
We have gathered some ideas and then started the phase of requirements discovery. The main
approach which we followed in gathering user and system requirements was surfing the web.
Also we have consulted our instructor, Dr. Nael Salman to give us some advice in how to
discover requirements.
In addition, I should mention that we have held an interview with some senior software
engineers that gave us guidelines on how to gather requirements.
CHAPTER 3: USER REQUIREMENTS DEFINITION
The system will be designed to be user friendly. The user friendly and interactive interfaces
design helps to achieve this by enabling customers to easily browse through the menus, place
orders with just a few clicks, and also allows restaurant employees to quickly go through the
orders as they are placed and produce the necessary items with minimal delay and confusion.
The system will be simple to use.
3.1 Functional User Requirements:

Functional requirements define the capabilities and functions that a system must be able to
perform successfully. The functional requirements of this online ordering system include:
I. ADMIN:
Managing users: the admin shall have a full access on the users database:
• Add user.
• Delete user.
• Edit a user record.
• View user info.
Managing restaurants: the admin shall have a full access on the restaurants
database:
• Add a restaurant.
• Delete a restaurant.
• Edit a restaurant record.
• View all restaurants info.
• View a specific restaurant info.
3
CHAPTER 2 REQUIREMENTS GATHERING | CHAPTER 3 USER REQUIREMENTS DEFINITION
II. CUSTOMER:
 [No need to have an account]: The system shall enable the customer to:
• Browse the restaurants. Each restaurant should show its name, its owner’s
name, and its location.
• When the customer clicks on a specific restaurant, show the restaurant’s

menu which contains all available dishes and products along with their
prices and ingredients.
 [Need for an account]: The system shall enable the customer to:
• Register to the system (create their own account)
• Login to the system after creating the account.
• Place an order.
• Specify whether they want the order to be delivered or picked up by the
customer themself.
• The system shall prompt customer to confirm the ordered meal.
• The system shall provide visual confirmation of the order placement
III. MANAGER (Restaurant’s ADMIN):

Each restaurant’s manager shall be able to:
• Create the restaurant’s menu.
• Create new food items and add them to the restaurant’s menu.
• Edit or update the details of any food item, such as: dish name, price,
ingredients,…
• Delete any food item they want.
• Generate sales reports for their restaurant (weekly, monthly, yearly
reports).
IV. KITCHEN STAFF (Restaurant’s Chefs):

Each chef shall be able to:
• View pending orders (orders that need to be prepared)
• Update orders’ status
• Verify the order to let them know that the order is ready to be taken or
delivered.
3.2 Non-Functional User-Requirements:
Operational Requirements
• The system should operate properly in most web browsers.
• The system should prompt the manager (each restaurant’s admin) to make a
backup at the end of the workday.
4
CHAPTER 3 USER REQUIREMENTS DEFINITION
Performance Requirements
• The system should let user place an order in a short period of time.
(less than one minute delay of loading)
• All tables in the database should be normalized at least up to 3rd normal form. So
Fetching data from database shall not exceed 5 to 10 seconds in worst case.
Security Requirements
• The system shall validate the username and password in order to login
and make changes to the system.
• The system shall request the current password of the user in order to let
them change to a new password.
• Passwords should be encrypted.
Usability Requirement
• The system should have a simple and easy-to-learn graphic user interfaces.
• A new customer should be able to use most of the system’s functionalities in

less than half an hour of training.
5
CHAPTER 3 USER REQUIREMENTS DEFINITION
CHAPTER 4: SYSTEM ARCHITECTURE
This chapter will present a high-level overview of the anticipated system architecture, showing
the distribution of functions across system modules. Architectural components that are reused
should be highlighted.
Figure 1: General Overview of our System’s Architecture
4.1 What is Outside the System’s Borders:

System boundaries are established to define what is inside and what is outside the system:
Handling Payment Methods:

We are trying to keep our system simple, so we will not get involved in payment system in
details, as it requires to integrate our system with an external system that is responsible for
handling payments and payment methods (such as Visa card).
6
CHAPTER 4 SYSTEM ARCHITECTURE
4.2 Context Diagram:

This is another brief structure which depicts the environment in which a software system
exists and helps in communicating about what lies outside the system boundary.
Figure 2: Context Diagram of our System’s Architecture
CHAPTER 5: SYSTEM REQUIREMENTS SPECIFICATION:

Now I will try to describe some functional and nonfunctional requirements that were stated
in chapter 3, but in more detail.
5.1 FUNCTIONAL SYSTEM REQUIREMENTS:

The system has a home screen, through which any user who has created an account can log
into the system using their username and password.
7
CHAPTER 5 SYSTEM REQUIREMENTS SPECIFICATION
Table 1: <<Functional System Requirement>> User Login
User Login
Brief Description The log in use case allows the user to login in the system.
Actor(s) A user, could be:
• An admin.
• A restaurant’s manager.
• A kitchen staff (a chef).
• A customer.
Note: I think that there will be a different login form for each type
of users mentioned above, because each type will be stored in its
own database
Flow of Events At Homepage ➔ Login Form;
1. The system prompts the user for his/her username and

password.
2. The user enters his/her username and password.
3. The system validates the entered information, ensures
that the entered data actually exist in the users
database.
4. The user is Logged in.
5. The use case ends.
Pre-conditions Having an account before.
Security Secure connection to the database
Post-conditions
Success The user entered data that is stored in the user account
8
Table 2: <<Functional System Requirement>> Restaurant’s Manager

Creating the Restaurant’s Menu by the Restaurant’s Manager/owner
Brief Description Allows the restaurant’s manager to create their restaurant’s menu, then
insert dishes to it.
Actor(s) The restaurant’s manager/ owner (each new added restaurant will be assigned
to a manager who will be responsible for this restaurant)
Flow of Events After the manager has logged in successfully, now they can go to
the nav bar at the top ➔ Create Restaurant’s Menu
1. The restaurant’s manager can create one menu only for their
restaurant.
2. After creating the menu, the manager can add dishes/ food items, by
specifying the dish’s name/title, price, ingredients, dish description, and
the dish size (small – medium – large)
3. Then will click ‘save dish’ and the dish will be inserted into the menu
database, with a related foreign key: ‘restaurantID’ to indicate that these
food items are related to this specific restaurant.
The manager can edit any food item in the menu whenever they want.
For example, they can change the dish name, the price (increase or
make a discount), edit the ingredients, or edit the description of the dish.
The manager can delete any food item in the menu whenever they want.
For example, if the restaurant is no more serving this dish, or if they want
to temporarily disable this dish from the menu.
The manager can then generate (weekly, monthly, yearly) reports

showing them the details such as:
• how many orders have been made by customers.
• total profit.
Pre-conditions Having the restaurants manager logged successfully to their account
Security Secure connection to the database.
Only the restaurant’s manager/owner can access the restaurant’s menu and
make such changes (insert, update, or delete)
Other people such as the customers, can only view and browse the menu, but
do not have the rights to insert, update, or delete any item.
Post-conditions The restaurant’s manager is recommended to make a backup of their menu
after each change.
Success The restaurant’s manager has created their restaurant’s menu, and
added food items to it.
9
Table 3: <<Functional System Requirement>> Customer Functions
CUSTOMER
Brief Description Let the customer view and browse the menu of any restaurant they desire,
then give them the opportunity to place an order and choose how they want to
receive it.
Actor(s) The customer (user who wants to place an order)
Flow of Events Customer as a guest:

1. Any guest customer can browse the restaurants. Each restaurant should
show its name, its owner’s name, and its location.
2. When the customer clicks on a specific restaurant, show the restaurant’s

menu which contains all available dishes and products along with their prices
and ingredients.
Customer after login:
1. After the customer has created an account and logged in successfully, now
a button “add this order to cart” will be enabled next to each food item in the
menu.
2. Now the customer will view the menu of any restaurant they want.
They can click on the button “add this order to cart” to make an order of any
food item they desire.
3. Customer can order more than one food item of course, so when the
customer has finished ordering, they shall click on “submit order” button.
4. All selected dish/food item will then be added to the orders database, with
the customer’s ID and other related info that indicates that this dish is ordered
by this specific customer.
5. The customer’s role now is over. The customer now must wait for the chefs
that will receive his/her order, prepare the order, then verify it.
6. Once the chefs change the status of the order from “pending” into “ready”,
the customer can see the status of his/her order as “ready”, and shall prepare
him/herself to go and pick the order, or wait for the deliverer.
Pre-conditions Browsing as a guest requires no conditions.
Placing an order requires the customer to login successfully.
10
Security Secure connection to the database.
Once the customer has placed an order, an email notification will be sent
directly to their email address.
If the order was not made by the customer! He/she can report the order and
this will stop the order and will prompt the customer to change their password.
Post-conditions After the customer receives the order. He/she will be asked to give a rating for
the service.
Success The customer has received their order exactly as desired.
5.2 NON-FUNCTIONAL SYSTEM-REQUIREMENTS:

In systems engineering a non-functional requirement specifies how the system should behave
and they specify constraints upon the systems behavior. One could also think of nonfunctional
requirements as quality attributes of a system.
1. Security:
• The system has a login and sign-up pages.
• To register, the user need to enter email and password which must be at least 7
characters, and must include at least: 1 lowercase letter, 1 uppercase letter, numbers,
and one of the following characters(#, $, *, !)
• The system will protect this information by using Identity in Asp.net that is made by
.net which have
• Also the user cannot complete the registration without entering a code that the system
send to him via email.
2. Ease of use:
• The system should have a simple and easy-to-learn graphic user

interfaces.
• A new customer should be able to use most of the system’s

functionalities in less than half an hour of training.
• Provides help frame such as error messages while entering invalid data.
3. Availability:
• each restaurant can specify their working days and hours, and then their
restaurant’s menu on our system will be available for customers to make orders
during these hours.
11
CHAPTER 6: SYSTEM MODELS:

• 6.1: Use-case Diagrams:
Figure 3: Admin’s Use-case Diagram
Figure 4: Customer’s Use-case Diagram
12
CHAPTER 6 SYSTEM MODELS
Figure 5: Meal Deliverer’s Use-case Diagram
Figure 6: Kitchen Staff Use-case Diagram
13
Figure 7: Restaurant’s manager use case diagram
• 6.2: Class Diagram:
Figure 8: Food Ordering & Delivery System’s Class Diagram
14
• 6.3: Activity Diagram
Figure 9: General Activity Diagram of a Customer while Ordering Food Item from a Menu
for The First Time.
15
Figure 10: Activity Model Showing the Flow of Events between a Customer (user) and a
Courier (meal deliverer)
16
Figure 11: Activity Diagram shows the Flow of Events that a Restaurant’s Manager should
Follow to Create their Restaurant’s Menu and Add Food Items.
17
• 6.4: Sequence Diagram
Figure 12: Admin login Sequence Diagram
18
Figure 13: Restaurant’s Manager Views Info about their Chefs
19
Figure 14: Comprehensive Sequence Diagram Showing almost all Relationships between
Customer and System’s objects.
20
Figure 15: Customer while Ordering (Process of Placing an Order)
21
Figure 16: Sequence Diagram for the Kitchen when Receiving the Order
22
Figure 17: Meal Deliverer Receiving the Order
CHAPTER 7: SYSTEM EVOLUTION:

SYSTEM LIMITATION:
Integrating our system with a payment system such as Visa Card is still not available, due to
our lack of knowledge in API. So for now, we will implement the system assuming that the
customer will pay in cash only.
SYSTEM ENHANCEMENT:
We shall provide the ability for each registered customer to rate a restaurant only after ordering
from it.
In future, we are looking forward to developing a mobile application for our food ordering
system using android platform.
23
CHAPTER 7 SYSTEM EVOLUTION
The mobile application system can implement a feature which is real time notification from the
mobile phone application to the service desk. This feature enables customer to request customer
service through using the mobile application.
The mobile application may implement some mini games to entertain customers while they are
waiting for the food to be served.
CHAPTER 8: PLAN FOR REST OF WORK:

based on the new information we have already learned; we have refined our initial plan which
we delivered in the project proposal. Our plan did not change, so we are still fit to the original
plan.
AUTHOR NAME] 20
CHAPTER 9: CONCLUSION:
The work on this project was very useful. At the beginning, we had some difficulty in coming
up with the idea of the project, and then in gathering the user and system requirements.
I think our project is not as simple as it looks. It requires much work to be tackled. We all
consider ourselves as juniors or beginners in the web development field. We are not very
experienced with web technologies. This will be the first big project we will face. So we are
planning to work cooperatively and benefit of each other.
24
CHAPTER 8 PLAN FOR REST OF WORK | CHAPTER 9 CONCLUSION
REFERENCES:
• Food Ordering System Using Mobile Phone By LEONG WAI HONG, Faculty of Information and
Communication Technology (Perak Campus), Jan 2016:
http://eprints.utar.edu.my/1943/1/IA-2016-1203135-1.pdf
• Project proposal in Online Ordering System by KAPCHNAGA ROGERS WAFULA,

Kabarak Ubiversity, School of Science Engineering & Technology, Department of
Mathematics and Computing Sciences:
https://www.coursehero.com/file/16277265/ONLINE-ORDERING-SYSTEM-
PROJECT-PROPOSAL/
• Architecture and Design Principles for Online Food Delivery System, written by:
Sandesh Deshmane, on: Aug 12 2020:
https://sandesh-deshmane.medium.com/architecture-and-design-principles-for-online-
food-delivery-system-33bfda73785d
• Designing a food ordering Mobile App — a UX case study, written by: Andrey
Herasymenko, on: Dec 20, 2018:
https://uxdesign.cc/ui-ux-case-study-feedme-mobile-app-for-ordering-food-
ef0e7f8c82ba
• What is Sequence Diagram?:

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-
sequence-diagram/
• LucidChart & Draw.io Tools for Drawing UML Diagrams.
25

Palestine Techinical University (PTU) : Software Engineering Requirements Document

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Read this document in other languages

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Palestine Techinical University (PTU) : Software Engineering Requirements Document

Uploaded by

Copyright:

Available Formats

Palestine Techinical University (PTU)

Faculty of Engineering and Technology

Software Engineering Requirements Document

Student's Name Student's ID

Fares Hatem T. Abuali 201810408

Submitted On: April 20, 2021

Assignment #2: This document was submitted in partial fulfilment of

CHAPTER 1 INTRODUCTION …………………………………………………………………………………………………………… 1

1.1 Project Overview & Background....................................................................................... 1

1.2 Project Domain ................................................................................................................ 1

1.3 Project Objectives ............................................................................................................ 1

1.4 Project Scope ................................................................................................................... 2

1.5 Chapter Summary ………………………………………………………………………………………………….…… 2

CHAPTER 2 REQUIREMENTS GATHERING APPROACH ……………………………………………………………………. 3

CHAPTER 3 USER REQUIREMENTS DEFINITION ………..……………………………………………………………………. 3

3.1 Functional User Requirements ……………………………………………………………………………………. 3

3.1 Non-Functional User Requirements ……………………………………………………………………………. 4

CHAPTER 4 SYSTEM ARCHITECTURE ……………………….………………………………………………………………….…. 6

4.1 What is Outside the System’s Borders ………………………………………………………………………… 6

4.2 Context Diagram …………………………………………………………………………………………………………. 7

CHAPTER 5 SYSTEM REQUIREMENTS SPECIFICATION ……………………………………………………………………. 7

5.1 FUNCTIONAL SYSTEM REQUIREMENTS ………………………………………………………………………. 7

5.2 NON-FUNCTIONAL SYSTEM-REQUIREMENTS ………………………………………….………………… 11

CHAPTER 6 SYSTEM MODELS ………………….……………….………………………………………………………………….. 12

6.1 Use-case Diagrams …………………….…………………………………………………….……………………….. 12

6.2 Class Diagram .…………………….…………………………………………………….……………………………… 14

6.3 Activity Diagrams …………………….…………………………………………………….……………………….… 15

6.4 Sequence Diagram …….…………….…………………………………………………….……………………….… 18

CHAPTER 7 SYSTEM EVOLUTION …………………….…………………………………………………………………………… 23

CHAPTER 8 PLAN FOR REST OF WORK …………………………………….…………………………………………………… 24

CHAPTER 9 CONCLUSION ……………………………………………………………………………………….……………………. 24

1.1 Project Overview & Background:

1.2 Problem Domain:

1.3 Project Objectives:

How We Propose to Address the Diagnosed Problems:

• Create an archive for restaurants:

1.4 Project Scope:

1.5 Chapter Summary:

CHAPTER 2: REQUIREMENTS GATHERING APPROACH

CHAPTER 3: USER REQUIREMENTS DEFINITION

3.1 Functional User Requirements:

• When the customer clicks on a specific restaurant, show the restaurant’s

III. MANAGER (Restaurant’s ADMIN):

IV. KITCHEN STAFF (Restaurant’s Chefs):

3.2 Non-Functional User-Requirements:

• The system should operate properly in most web browsers.

• Passwords should be encrypted.

• A new customer should be able to use most of the system’s functionalities in

CHAPTER 4: SYSTEM ARCHITECTURE

Figure 1: General Overview of our System’s Architecture

4.1 What is Outside the System’s Borders:

Handling Payment Methods:

4.2 Context Diagram:

Figure 2: Context Diagram of our System’s Architecture

CHAPTER 5: SYSTEM REQUIREMENTS SPECIFICATION:

5.1 FUNCTIONAL SYSTEM REQUIREMENTS:

Table 1: <<Functional System Requirement>> User Login

Actor(s) A user, could be:

1. The system prompts the user for his/her username and

Table 2: <<Functional System Requirement>> Restaurant’s Manager

The manager can then generate (weekly, monthly, yearly) reports