Table of Contents

Table of Contents

Table of Contents……………………………………………………………………. ii

Revision History……………………………………………………………………… ii

1. Introduction………………………………………………………………………. 1

1.1 Purpose………………………………………………………………………….. 1

1.2 Document Conventions………………………………………………………. 1

1.3 Intended Audience and Reading Suggestions………………………….. 1

1.4 Project Scope…………………………………………………………………… 2

1.5 References………………………………………………………………………. 2

2. Overall Description……………………………………………………………. 2

2.1 Product Perspective…………………………………………………………… 2

2.2 Product Features……………………………………………………………….. 3

2.3 User Classes and Characteristics………………………………………….. 3

2.4 Operating Environment………………………………………………………. 3

2.5 Design and Implementation Constraints…………………………………. 3

2.6 User Documentation………………………………………………………….. 4

2.7 Assumptions and Dependencies…………………………………………… 4

3. System Features…………………………………………………………………. 4

3.1 System Feature 1………………………………………………………………. 4

3.2 System Feature 2 (and so on)………………………………………………. 5

4. External Interface Requirements………………………………………… 5

4.1 User Interfaces…………………………………………………………………. 5

4.2 Hardware Interfaces………………………………………………………….. 5

4.3 Software Interfaces……………………………………………………………. 6

4.4 Communications Interfaces…………………………………………………. 6

5. Other Nonfunctional Requirements……………………………………. 6

5.1 Performance Requirements…………………………………………………. 6

5.2 Safety Requirements………………………………………………………….. 7

5.3 Security Requirements……………………………………………………….. 7

5.4 Software Quality Attributes…………………………………………………. 7

6. Other Requirements…………………………………………………………… 8

Appendix A: Glossary……………………………………………………………… 8

Appendix B: Analysis Models………………………………………………….. 9

Revision History

Name

Date

Reason For Changes

Version

Introduction
Purpose
This SRS describes the software functional and nonfunctional requirements for release 1.0 of the Online Ordering System (OOS). This document is intended to be used by the members of the project team that will implement and verify the correct functioning of the system. Unless otherwise noted, all requirements specified here are high priority and committed for release 1.0

.

Document Conventions
The scheduling system shall use the following conventions: 11pt font-size, the font used throughout will be Arial, Times, Times New Roman, and Courier New. These may change depending on user settings

Intended Audience and Reading Suggestions The primary audience of this SRS document will be the development team employed to implement the specified Restaurant food ordering system. The audience comprises the project’s stakeholders: restaurateurs and associated staff. This SRS should convey and confirm the required functionality to this audience group and represent a contractual agreement between the involved parties.
< The primary audience of this SRS document will be the development team employed to implement the specified Restaurant food ordering system. It will not only provide an extensive capacity for project planning and progress assessment but it will further assist with stakeholder interactions. The secondary document audience comprises the stakeholders of the project, that is, restaurateurs and associated staff. To this audience group, this SRS should convey and confirm the required functionality and represent a contractual agreement between the involved parties. Project Scope In formal dining environments, some physical static menu utilizes to convey the available food and beverage choices to customers. Said menus are generally paper based. Moreover, hence impose restrictions on the textual real estate available and a restaurateur's ability to update them. The related concepts encompassed the general scope of the Restaurant food ordering System. It is to the replacement of paper-based menus using an electronic format. References Overall Description Product Perspective The software described in this SRS is the software for a complete Restaurant food ordering system. The system merges various hardware and software elements and other interfaces with external systems. It relies on several external interfaces for persistence and unhandled tasks, as well as physically interfacing with humans. Product Features The Restaurant food ordering system interfaces with an existing payment system, including a cash register and software accessible credit system, in order to quickly and easily handle customer billing. The payment system should be operable such that it can return information to the RFOS system as to whether payment was successful or failed The food ordering system interfaces with an existing payment system, including a cash register and software-accessible credit system, to handle customer billing quickly and efficiently. The payment system should be operable such that it can return information to the ROF system as to whether the payment was successful or failed User Classes and Characteristics < There are three separate user interfaces used by the RFOS software, each related to an interfaced physical hardware device . These three user interfaces are the Surface Computer UI, Tablet UI and Display UI. There are three separate user interfaces used by the RFOS software, each related to an interface physical hardware device. These three user interfaces are the Surface Computer UI, Tablet UI, and Display UI. Operating Environment The Surface Computer UI is the interface used by restaurant customers. This interface uses the surface computer paradigm - users interact with the system by dragging 'objects' around on the screen touch-sensitive display. The Tablet UI is designed to run on a wireless-enabled touch-screen tablet PC that wait people use to accommodate customer needs. The Display UI provides kitchen staff with simple functionality related to ordered items. The Surface Computer UI is the interface used by restaurant customers. This interface uses the surface computer paradigm - users interact with the system by dragging 'objects' around on the flatscreen touch-sensitive display. The Tablet UI is designed to run on a small, wireless-enabled touch-screen tablet PC, to be used by waiters to accommodate customer needs. The Display UI provides kitchen staff with simple functionality related to ordered items. Design and Implementation Constraints The RFOS can be written in an object-oriented language with strong GUI links and a simple, accessible network API. The primary candidate toolchains are Java/Swing, C++/Qt, and python/Qt. The system design should not introduce scalability issues concerning the number of surface computers, tablets, or displays connected at any one time The system must be reliable enough to crash and glitch-free, indefinitely, User Documentation The end-users of the RFOS fall into three primary categories, unskilled, partly skilled, and highly skilled. Assumptions and Dependencies The SRS assumes that none of the constituent system components will be embedded applications. The tablet PCs of sufficient processing capability and battery life will utilize. System Features Functional requirements are listed first, according to their relationship to the overall system, customers, servers, chefs, and supervisors System Feature 1 < Don't really say "System Feature 1." State the feature name in just a few words.>

3.1.1 Description and Priority

3.1.2 Stimulus/Response Sequences

3.1.3 Functional Requirements

REQ-1:

REQ-2:

System Feature 2 (and so on)
External Interface Requirements
User Interfaces
Users can manipulate objects such as items of food, dietary requirements, tips, and menus on the surface of their table. Such objects can be moved into static objects such as meals and payments to perform various functions. In addition to this object manipulation paradigm, a limited system menu is necessary. Users will summon their restaurant menu, combined with a system/commandment, using an easy touch gesture, a double tap on the touch surface, and dismiss it with a similar gesture or by tapping a close button GUI element.

Hardware Interfaces
These devices are surface computers, wireless tablets, and touch displays. All three devices must be physically robust and immune to liquid damage and stains. The devices(with the possible exception of displays) must also have pleasing industrial design aesthetics, as they are to be used in place of regular restaurant tables and notepads and will be in direct contact with customers

These devices are the surface computers, the wireless tablets and the touch displays. All

three devices must be physically robust and immune to liquid damage and stains. The devices

(with the possible exception of displays) must also have good industrial design aesthetics, as they

are to be used in place of normal restaurant tables and notepads and will be in direct contact with

customers

Software Interfaces
The RFOS will interface with a Database Management System (DBMS) that stores the information necessary for the RMOS to operate. The DBMS must be able to provide, on request and with low latency, data concerning the restaurant’s menu, employees (and their passwords), available dietary requirements

Communications Interfaces
The RFOS will interface with a Local Area Network (LAN) to maintain communication with all its devices. It should use a reliable-type IP protocol such as TCP/IP or reliable-UDP/IP for maximum compatibility and stability. All devices it will interface with should contain standard ethernet compatible, software-accessible LAN cards to maintain communication between the server and the surface computers, tablets, displays, and the external payment system

Other Nonfunctional Requirements
This subsection presents the identified nonfunctional requirements for the subject RFOS. The subcategories of nonfunctional requirements given are performance, safety, security requirements

Performance Requirements
The server shall be capable of supporting an arbitrary number of surface computers, tablets, and displays; that is, it shall provide no limit on how many devices are in the system. The server shall be capable of supporting an arbitrary number of active customer payments; that is, no payments shall be lost under any circumstances

Safety Requirements
The system shall log every state and state change of every surface computer, tablet, and display to recover from system failure.
The system shall be able to always display a menu to facilitate manual order taking should the need arise.
The system shall utilize periodic 30-second keep-alive messages between tablets and the server to monitor tablet operational status

The system shall be able to display a menu at all times to facilitate manual order taking
should the need arise.
The system shall utilise periodic 30-second keep-alive messages between tablets and the
server to monitor tablet operational status
Security Requirements
A waiter password used for tablet login must have a bit-strength of at least 64 bits.

A server password used for tablet login must be changed every three months.

An attendant that attempts to log into a second tablet while already logged into

Software Quality Attributes
The software shall be capable of supporting an arbitrary number of surface computers, tablets, and displays; that is, it shall provide no limit on how many devices are in the system. It shall7

be capable of supporting an arbitrary number of active meals/orders, that is, no meals/orders shall be lost under any circumstances

Other Requirements
The prioritization of the software quality attributes assumed as under: Accurate and hence reliable, secured, and fast speed.

Appendix A: Glossary

First, I identified the activities and tasks in the project. In my proposed

Project:

Analysis, designing, testing, implementation.

Analysis activity has the following tasks:

Preliminary investigation
Need identification
Feasibility study
Design activity has the following tasks:
Appendix B: Analysis Models

Modules

Modules:

A) User login module:

In this face, existing user gives the username and password and can access the

other details and if he is current user then first, he would have to register himself by

option Registration module.

B) Registration module:

This module gives a registration form to the user for the Registration. After a

unique username and password he would be registered by which he would be login.

c) About us:

This module covers the information of the website owner and the purpose of the

Appendix C: Issues List

This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting res