Software Requiremsnts Specification

Restaurant POS System (RPOSS)

Table Of Contents

1. Intorduction
   • Purpose
   • Scope
   • Definitions, acronyms, and abbreviation
   • References
   • Overview
2. Overall Description
   • Product Perspective
   • Product Functions
   • User Characteristics
   • Operating Environment
   • Constraints
   • Assumptions and Dependencies
3. External Interface Requirements
   • User Interface
     • Restaurant Customers
     • Restaurant Staff
     • Restaurant Owner
   • Hardware Interfaces
   • Software Interfaces
   • Communication Interfaces
4. System Features
   • Restaurant Customers
     • Restaraurant Built-in Home Page
       • Navigation Bar
       • Welcom Section
       • About Us Section
       • Menu Section
       • Our Location Section
       • Contact Us Section
     • Menu Built-in Page
       • Menu Items Section
       • Checkout Section 1
     • Form Built-in Page
       • Form Section
       • Checkout Section 2
     • Verifying Phone Number
     • We Received Your Order Built-in Page
   • Restaurant Staff
     • Progressive Panel
       • Navigation Bar
       • Hello Section
       • Menu Bar
         • All Orders View
         • Pending Orders View
         • In Progress Orders View
         • Finished Orders View
         • Missed Orders View
   • Restaurant Owner
     • Owner Panel
       • Navigation Bar
       • Hello Section
       • Menu Bar
         • Restaurant Option
           • Base Information
           • Openning Hours
           • Social Media
         • Menu Options
           • Menu Setup
         • Order Hampers
           • Ordering Methods
           • Orders Timing
         • Employees Registration
           • Add a New Employee
         • System Interfaces
           • Online Ordering
5. Other Nonfunctional Requirements

• Performance Requirements
• Safety Requirements
• Software Quality Attributes

6. Other Requirements

• Twilio
• SMTPlib

7. Release Plan

Intorduction

Purpose

The purpose of this documentation is to give a detailed description of the requirements and features for the "Restaurant POS System" (RPOSS) .it will illustrate the purpose and complete declaration for the development of the system. it will also explain system constraints, interfaces and interaction with other external devices/systems. this document is primarly intended to be a reference for developing the first version of the system for the development team.

This document is going to serve as the stepping stone for the upcoming versions of this system.

Scope

The Restaurant POS System (RPOSS) is an application designed for restaurants' owners, not only to imrpove the customer's experience, but also to ease the workload on the restaurant staff by providing the online-ordering functionalities to the restaurant website.

The RPOSS application is hosted on a cloud hosting service which means the system does not need any infrastructure downloaded on the restaurant premises. For all different users of the system need to be able to use it is a web browser, meaning this application works on any device.

Definitions, acronyms, and abbreviation

References

• IEEE Software Engineering Standards Committee, "IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications", Octoper 20. 1998.
• Software RequirementsSpecification-Amazing Lunch Indicator

Overall Description

This section will give an overview of the whole system. The system will be explained in its context to show what the different parts of this applicaiton are and how do these parts interact with each another and how do they interact with some external devices. this section will also provide the basic functionality of this application. it will also describe what type of stakholders that will use the application and what functionality is available for each type. at last, the constraints and assumptions for the application will be presented.

Product Perspective

The RPOSS project is a self contained product which runs on any web browser for all the different users of the application. while the restaurant web application is the main focus of the system, there is also a server-side component and an API integeration that will be responsible for adding and modifying on the database and responsible for SMS verification services. A thermal printer hardware is also attached to the system for printing receipts for the customers.

the restaurant web application is further divided into three panels: owner panel which will allow him/her to define basic information and different options about the restaurant. the second panel is the staff progressive panel, this panel is responsible for showing the customers orders, it gives the staff members the ability to accept and reject pending orders.the third panel is the Restaurant built-in home page, basically, this is the main web page for the restaurant which shows up to customers. it will hold the information architecture of the restaurant that the owner specified in his/her panel, plus the online ordering functionality. Unlike the restaurant customers, both the restaurant owner and staff need special credaentials in order for them to be able to access their web panels.

This system is designed with a built-in restaurant web pages, In case the restaurant owner has his/her website and all they need is the online ordering functionality that RPOSS provides, The system can provide them with an "order online" button which they can add to their website. This button will lead the customer directly to the built-in restaurant menu page where restaurant customers get to check menu items for pick-up and delivery orders.

Since this is a data-centric product it needs somewhere to store data. for that, a database will be used. all of the web application parts will communicate with the database, however in slightly different ways. restaurant home page and its sub-pages will add data to the database, while owner web panel and staff progressive web panel will use the database for creating, reading, updating and deleting data. all of the database communication will go over the internet.

This system will be involved with the Twilio API, which will be used for its SMS two-factor(2FA) authentication services for confirming customers' identities.

Product Functions

The following table offers a brief outline of the main features and functionalities of the RPOSS. The features are split into three major user classes: Restaurant owner, Restaurant staff and restaurant customers.

User Characteristics

The application is intended for use by three user classes: restaurant customers, restaurant owner and restaurant staff. Each of these three types of users has different use of the system so each of them has their own requirements.

1. Restaurant owner, who wants his/her restaurant to be part of the RPOSS. through his/her web panel. there they will manage basic information and different options about their restaurant, for example a description of the restaurant, contact information and their menu.

2. Restaurant staff, they will interact with the progressive web panel. there they will get to manage all placed orders by customers.

3. Restaurant customer, could be any kind of person who wants to order some food online and get delivered. customers will interact mainly with the restaurant built-in home page and the menu built-in page.

Operating Environment

The restaurant application will run on any web browser on any device accessing the internet.

The web application of this system is highly interacted with the RPOSS server, a vertual dedicated server hosted by DigitalOcean.com. The server operates on a Windows platform with 1GB of RAM and 25GB of allocated storage space(those values can be resized up or down at any time). The RPOSS database will be stored on the server using MySQL and will be interfaced with the SQL-Alchemy Flask extension.

Constraints

The RPOSS is developed in Python, it uses Python ESC/POS library for accessing thermal printers that are handled by ESC/POS commands. So the system is constrained by the type of the thermal printer linked to it. since there are multiple printer vendors and drivers, the system will most likely not be able to recognize all different types of them.

the internet connection is also a constraint for two reasons: one, the entire web-portal with its different panels, can only be accessed through internet using a web browser. two, this application sends and fetches data from the database over the internet, it is crucial that there is an internet connection for the application to function.

Assumptions and Dependencies

One assumption about the product is that it will always be accessed through a web browser, an internet connection is a must in order for all users of the system to connect to the web application and the database. for example, the restaurant staff can not access the progressive panel and change orders status if there is no internet connection.

Another assumption is that the thermal printer connected to the system is compatible with the ESC/POS command set. if it has different command set, the system needs to be specifically adjust to the currently existing printer type.

Another assumbtion is that the restaurant has one branch only. this version of the system does not support multiple branches.

This system is highly depedent on the Twilio API service. a Twilio account must be created manually for the restaurant in order for the web application to be able to validate customers' identities.

This system also depends on the Python SMTPlip for sending email messages from the server to the restaurant customers.

External Interface Requirements

1. User Interface

As mentioned before, there are three types of users that interact with the system: restaurant customers, restaurant owner and restaurant staff. Each of them has their own interface to the system.

1.1. Restaurant Customers

a customer will first see the restaurant home page. the restaurant home page holds most of the informations that the owner defined in his/her panel. those informations will help the customer to know more about the restaurant. for example, menu description, contact information, restaurant location, etc.

In the restaurant built-in home page, there must be a button that leads to the restaurant built-in menu page. customers will get to place orders there by adding menu items for checkout.

After choosing menu items, the customer has to fill in a generic form, this form includes: full name, phone number, E-mail address, whether the order is a Pick-up or Delivery. If the order method is Delivery, customer must provide his/her address location.

Next, customers will be asked to verify their phone number with the code the system sent them to complete placing the order.

when phone number is verified, then, within a period of 5 minutes, a confirmation email message is sent to the customer to aknowledge them that the order is confirmed. if the order was rejected or was not confirmed within a period of 5 minutes by the restaurant staff, a rejection message will be sent to the customer email. the confirmation email message will state: order id, order details, customer's details, and when will the order be ready.

see Figure

1.2. Restaurant Staff

The restaurant staff interact with the system through the Progressive Panel web page. Before that, a restaurant employee must log in to the system using credentials that the owner provide them in the www.restaurantname.com/RPOSS/login.

The progressive panel web page holds five different views of the orders: -Pending orders view: this view will show all orders made by customers waiting for an approval of the restaurant staff. -In Progress orders view: this view will hold accepted orders. this view is especially designed for the restaurant cooks, so that it will show each orders menu items and their expected preparing time clearly. pressing the finished button on an order aknowledges that the order is done. -Finished orders view: will show all orders that are finished/delivered successfully. -Missed orders view: this view will hold all rejected/missed orders. -All orders view: in this view, the staff will get to see al orders from pending to missed. this view is sorted by time.

Finally, the restaurant employee can exit the system using the log out link in the progressive panel page. see Figure

1.3. Restaurant Owner

Same as restaurant staff, the restaurant owner will go through the log in page to get into the system using a predefined credentials.

Once the owner is logged in to the system they can get access to the following options: -Restaurant Information / The owner can add basic information about the restaurant, opennig hours and social media accounts. -Restaurant Menu / This section is where the owner will add his/her menu items. -Ordering Hampers / This section gives the owner the ability to control what kind of ordering methods does the restaurant offer to the customers. This section also asks for estimations on times by which a specific order will be done. -Employees Registration / The owner is responsible for making the employees accountsin which they will use to access the RPOSS. -System Interfaces / In case the owner has his/her own website and all they are intrested in is the online ordering functionalities. They can get to this section and take the online ordering button and link it to their website. see Figure

2.Hardware Interfaces

The RPOSS web application can and will run on any device with a web browser installed on it.

For all Users to be able to access the restaurant website, an internet connection is needed. So a network device such as a modem is required.

The approached thermal printer must support the ESC/POS command set. Restaurant owner and staff must take into consideration that the approached printer must be compatible with the device used to get to the restaurant website. for example: some printers can run over bluetooth others do not, some can be attached to a specific operating systems and others don't.

3.Software Interfaces

The RPOSS depends on some libraries for its functions. These tools are already pre-included with the application.

In addition to that, an email service application such as outlook.com, gmail.com, etc. is required in order for the restaurant staff menmbers to communicate with the customers messages being sent from the contact use built-in section.

4.Communication Interfaces

The communication between the different parts of the system is important since they depend on each another. Some of these communications are habdled by the underelying operations systems, others have to be set manually by the developer along with the restaurant owner.

System Features

In this section, RPOSS features and functions will be listed and described for better understanding and to help developers with the implementation process.

1. Restaurant Customers

1.1. Restaraurant Built-in Home Page

1.1.1. Navigation Bar

1.1.2. Welcom Section

1.1.3. About Us Section

1.1.4. Menu Section

1.1.5. Our Location Section

1.1.6. Contact Us Section

1.2. Menu Built-in Page

1.2.1. Menu Items Section

1.2.2. Checkout Section 1

1.3. Form Built-in Page

1.3.1. Form Section

1.3.2. Checkout Section 2

1.4. Verifying Phone Number

1.5. We Received Your Order

2. Restaurant Staff

2.1. Log In Page

2.2. Progressive Panel

2.2.1. Navigation Bar

2.2.2. Hello Section

2.2.3. Menu Bar

2.2.3.1. All Orders View

2.2.3.2. Pending Orders View

2.2.3.3. In Progress Orders View

2.2.3.4. Finished Orders View

2.2.3.5. Missed Orders View

3. Restaurant Owner

3.1. Owner Panel

3.1.1. Navigation Bar

3.1.2. Hello Section

3.1.3. Menu Bar

3.1.3.1. Restaurant Option

3.1.3.1.1. Base Information

3.1.3.1.2. Openning Hours

3.1.3.1.3. Social Media

3.1.3.2. Menu Options

3.1.3.2.1. Menu Setup

3.1.3.3. Order Hampers

3.1.3.3.1. Ordering Methods

3.1.3.3.2. Orders Timing

3.1.3.4. Employees Registration

3.1.3.4.1. Add a New Employee

3.1.3.5. System Interfaces

3.1.3.5.1. Online Ordering

Other Nonfunctional Requirements

1. Performance Requirements

The RPOSS is not a resi=ource consumer and will run on almost every device with a web browser installed on it. its functions and features are not computationally intensive. The only real requirements are: web browser, thermal printer and an internet connection.

2. Safety Requirements

To eliminate data loss posibility, the remote is backed-up by the DigitalOcean cloud service.

3. Software Quality Attributes

The application provides a quite friendly user interface with its operations accessible from the application's different web panels. an average or casual user should not define any problem using the application to perform its main functions.

Other Requirements

1. Twilio

The system has to sign an upgraded twilio account in order to use the following: -Two-factor(2FA) authentication services: for verifying customers' identities. -Alphanumeric ID: for sending SMS messages using a personalized sender name.

2. SMTPlib

For the system to be able to send and receive confirmation messages to the customers, there must be an email assigned for accomplishing these requirements.

Release Plan

since this app is mostly RESTfull API architectural styled, here is the implementation plan that i followed:

• Mock-ups.
• Routing.
• Templates & forms.
• CRUD functionalities.
• API endpoints.
• Styling and message flashing

Uncompleted Features

the following features were not implementes due to the lack of materials:

• FR18 - printing receipts & confirming customers about their order via E-mail.
• twilio Alphanumeric ID.