Chapter 2

Software Requirements Specification

A software requirements specification (SRS)is a description of a software system to be

developed. It is modeled after business requirements specification, also known as a stakeholder
requirements specification. The software requirements specification lays out functional and non-
functional requirements, and it may include a set of use cases that describe user interactions that
the software must provide to the user for perfect interaction.
Software requirements specification establishes the basis for an agreement between customers
and contractors or suppliers on how the software product should function (in a market-driven
project, these roles may be played by the marketing and development divisions). Software
requirements specification is a rigorous assessment of requirements before the more specific
system design stages, and its goal is to reduce later redesign. It should also provide a realistic
basis for estimating product costs, risks, and schedules. Used appropriately, software
requirements specifications can help prevent software project failure.
The software requirements specification document lists sufficient and necessary requirements for
the project development. To derive the requirements, the developer needs to have clear and
thorough understanding of the products under development. This is achieved through detailed
and continuous communications with the project team and customer throughout the software
development process. A good SRS defines the how Software System will interact with all
internal modules, hardware, communication with other programs and human user interactions
with wide range of real-life scenarios. Using the Software requirements specification (SRS)
document on QA lead, managers create test plan. It is very important that testers must be cleared
with every detail specified in this document in order to avoid faults in test cases and its expected
results.

2.1 Requirements

2.1.1 Functional Requirements

  Purpose: -
To order an online food.

 Input: -
The required data for online food ordering system of a new user in the database
(Like Name, address, mobile number, mail id etc.)

a. Food Order
Customer can order food with the app but it needs specific wifi connection.

b. Take Order

The chef will take the order and if it is available to make then he will confirm the order
and start to prepare food.
c. Payment

The cashier will receive the payme nt if the customer is a member he or she will
get discount.
d. Available Good

The Chef will add what goods are available and the admin can see that data.

e. Required Goods
The chef will add what goods are required.

f. Customer Information
The customer will be get registered and be the member of special customer.

 Output: -
A success message will be displayed on the screen and at the same time a
confirmation message send to his registered mobile number.
 2.1.2 Non-Functional Requirements

Non-functional requirements are requirements that are not directly concerned with the
specific functions delivered by the system. They may relate to emergent system
properties such as reliability, response time and store occupancy. They may specify
system performance, security, availability, and other emergent properties.

2.1.3 Safety And Security Requirements

a. Backup, recovery & data continuity should ensure adequate back up of data as may be
required by their operations. Online Food Ordering software should also have, well
documented and tested business continuity plans that address all aspects of the software.
b. Both data and software should be backed up periodically.
c. An off-site back up is necessary for recovery from major failures /disasters to ensure data
continuity.
d. Account ID and Password protection.
e. The system will use secured pos system.
f. The whole system is secured only admin can access all data.

2.2 Software Quality Attributes

2.2.1 Reliability

Measure if product is reliable enough to sustain in any condition. Should give

consistently correct results. Product reliability is measured in terms of working of project
under different working environment and different conditions.

2.2.2 Maintainability
 Different versions of the product should be easy to maintain. For development, it’s
should be easy to add code to existing system, should be easy to upgrade for new features
and new technologies time to time. Maintenance should be cost effective and easy.
System be easy to maintain and correcting defects or making a change in the software.

2.2.3 Usability

This can be measured in terms of ease of use. Application should be user friendly. Should
be easy to learn. Navigation should be simple
.
2.2.4 Portability

This can be measured in terms of Costing issues related to porting, Technical issues
related to porting; Behavioral issues related to porting.

2.2.5 Correctness

Application should be correct in terms of its functionality, calculations used internally

and the navigation should be correct. This means application should adhere to functional
requirements

2.2.6 Efficiency

To Major system quality attribute. Measured in terms of time required to complete any
task given to the system. For example, system should utilize processor capacity, disk
space and memory efficiently. If system is using all the available resources then user will
get degraded performance failing the system for efficiency. If system is not efficient then
it cannot be used in real time applications.

2.2.7 Flexibility
 Should be flexible enough to modify. Adaptable to other products with which it needs
interaction. Should be easy to interface with other standard 3rd party components.

2.2.8 Memorability

For the ordering system, because the system is very logical, so for users, they only need
to follow the basic ordering logic, they can easily remember how to use this system next
time. This principle emphasizes whether a user can remember the application's steps after
multiple uses.

2.2.9 Learnability
The principle of learnability refers to that when a user first uses this application, the user
can obviously obtain the method of using this application or provide a clear guideline for
the user within the application to lead the user to familiarize with and completely use this
system to finish what he or she wants to do. It is the most significant principle for the
users who are not familiar with this application.

2.3 Specific Requirements

2.3.1 External Interface Requirements

There are many types of interfaces as such supported by this software system
namely; User Interface, Software Interface and Hardware Interface.

2.3.2 User Interfaces

The user interface will be implemented using any android smartphone app
browser. This interface will be user friendly. So that every kind of customer can
place the food order easily. Customers can also give feedback through it easily
with some demo comment or if they are keen to write their review by own they can
 do it.

2.3.3 Hardware Interfaces

There shall be logical address of the system in IPv6 format.

2.3.4 Software Interfaces

The system shall communicate with the Configurator to identify all the available
components to configure the product.

The system shall communicate with the content manager to get the product
specifications.

2.3.5 Communications Interfaces

Communication function required the Internet protocol version 6 and it will

follow HTTPS. It will use FTP for whole system with local server. And email
communication to device to device of the system.

2.3 Use Case diagram

2.3.1 Use Case View
The use cases for each of the actors are described in this section.

2. 3.2 Customer Use Case

Use case: Order Food

Description

The Customer can order food and see their payment receipt and pay.

2.3.3 Admin Use Case

 Use case:Maintain System

Description
The Admin has full access to the system. He maintains the whole system to ensure
better and secure service and solves any error appeared in the system.