Software Requirements

Specification
for

<Project>
Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for <Project> Page 2

Table of Contents
Table of Contents Error! Bookmark not defined.
Revision History 2
1. Introduction Error! Bookmark not defined.
1.1 Purpose Error! Bookmark not defined.
1.2 Document Conventions Error! Bookmark not defined.
1.3 Intended Audience and Reading Suggestions Error! Bookmark not defined.
1.4 Product Scope Error! Bookmark not defined.
1.5 References Error! Bookmark not defined.
2. Overall Description Error! Bookmark not defined.
2.1 Product Perspective Error! Bookmark not defined.
2.2 Product Functions Error! Bookmark not defined.
2.3 User Classes and Characteristics Error! Bookmark not defined.
2.4 Operating Environment Error! Bookmark not defined.
2.5 Design and Implementation Constraints Error! Bookmark not defined.
2.6 User Documentation Error! Bookmark not defined.
2.7 Assumptions and Dependencies Error! Bookmark not defined.
3. Specific Requirements Error! Bookmark not defined.
3.1 External Interface Requirements 5
3.2 Functional Requirements 9
4. Other Nonfunctional Requirements Error! Bookmark not defined.
4.1 Performance Requirements 9
4.2 Safety Requirements Error! Bookmark not defined.
4.3 Security Requirements Error! Bookmark not defined.
4.4 Software Quality Attributes Error! Bookmark not defined.
4.5 Business Rules Error! Bookmark not defined.
5. Other Requirements Error! Bookmark not defined.
Appendix A: Glossary Error! Bookmark not defined.
Appendix B: Analysis Models Error! Bookmark not defined.
Appendix C: To Be Determined List Error! Bookmark not defined.

Revision History
Name Date Reason For Changes Version
Software Requirements Specification for <Project>
Page 3

1. Introduction
1.1 Purpose
<Identify the product whose software requirements are specified in this document,
including the revision or release number. Describe the scope of the product that is
covered by this SRS, particularly if this SRS describes only part of the system or a single
subsystem.>

1.2 Document Conventions

<Describe any standards or typographical conventions that were followed when writing
this SRS, such as fonts or highlighting that have special significance. For example, state
whether priorities for higher-level requirements are assumed to be inherited by detailed
requirements, or whether every requirement statement is to have its own priority.>

1.3 Intended Audience and Reading Suggestions

<Describe the different types of reader that the document is intended for, such as
developers, project managers, marketing staff, users, testers, and documentation
writers. Describe what the rest of this SRS contains and how it is organized. Suggest a
sequence for reading the document, beginning with the overview sections and
proceeding through the sections that are most pertinent to each reader type.>

1.4 Product Scope

<Provide a short description of the software being specified and its purpose, including
relevant benefits, objectives, and goals. Relate the software to corporate goals or
business strategies. If a separate vision and scope document is available, refer to it
rather than duplicating its contents here.>

1.5 References
<List any other documents or Web addresses to which this SRS refers. These may
include user interface style guides, contracts, standards, system requirements
specifications, use case documents, or a vision and scope document. Provide enough
information so that the reader could access a copy of each reference, including title,
author, version number, date, and source or location.>
Software Requirements Specification for <Project>
Page 4

2. Overall Description
2.1 Product Perspective
<Describe the context and origin of the product being specified in this SRS. For
example, state whether this product is a follow-on member of a product family, a
replacement for certain existing systems, or a new, self-contained product. If the SRS
defines a component of a larger system, relate the requirements of the larger system to
the functionality of this software and identify interfaces between the two. A simple
diagram that shows the major components of the overall system, subsystem
interconnections, and external interfaces can be helpful.>

2.2 Product Functions

<Summarize the major functions the product must perform or must let the user perform.
Details will be provided in Section 3, so only a high level summary (such as a bullet list)
is needed here. Organize the functions to make them understandable to any reader of
the SRS. A picture of the major groups of related requirements and how they relate,
such as a top level data flow diagram or object class diagram, is often effective.>

2.3 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes
may be differentiated based on frequency of use, subset of product functions used,
technical expertise, security or privilege levels, educational level, or experience.
Describe the pertinent characteristics of each user class. Certain requirements may
pertain only to certain user classes. Distinguish the most important user classes for this
product from those who are less important to satisfy.>

2.4 Operating Environment

<Describe the environment in which the software will operate, including the hardware
platform, operating system and versions, and any other software components or
applications with which it must peacefully coexist.>

2.5 Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers.
These might include: corporate or regulatory policies; hardware limitations (timing
requirements, memory requirements); interfaces to other applications; specific
technologies, tools, and databases to be used; parallel operations; language
requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customer’s organization will be responsible
for maintaining the delivered software).>
Software Requirements Specification for <Project>
Page 5

2.6 User Documentation

<List the user documentation components (such as user manuals, on-line help, and
tutorials) that will be delivered along with the software. Identify any known user
documentation delivery formats or standards.>

2.7 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the
requirements stated in the SRS. These could include third-party or commercial
components that you plan to use, issues around the development or operating
environment, or constraints. The project could be affected if these assumptions are
incorrect, are not shared, or change. Also identify any dependencies the project has on
external factors, such as software components that you intend to reuse from another
project, unless they are already documented elsewhere (for example, in the vision and
scope document or the project plan).>

3. Specific Requirements
3.1 External Interface Requirements
This section gives a detail description of the key actors, input and output of the
system. It also provides a detail description of user, hardware, software and
communication interface of the system.

3.1.1 User Interfaces

The system shall have a graphical user interface. There are 6 key actors and 6 of them
shall have different interface. Restaurant’s logo shall be appeared on every screen and
there will be no keyboard shortcuts because every action can be performed using touch
on Ipad’s screen.

For User interface Menu there is a scroll bar with the help of which user can scroll
through every dish.
Software Requirements Specification for <Project>
Page 6

Menu Page
Tablet on every table will have this page displayed every time a new customer arrives or
when user clicks the menu button. User will tap select if he/she wants to select
something from the menu and it will be displayed on the fixed bottom footer. if user want
to deselect something he will again tap selected button to deselect item from the menu.
If user is done with order and wants to proceed he/she will have to click on confirm order
button.
Software Requirements Specification for <Project>
Page 7

Login Page
A main Login Page will appear which will differentiate each user through its email and
password and will take each actor to its respective main page.

Error Page
Software Requirements Specification for <Project>
Page 8

Order List Page

Software Requirements Specification for <Project>
Page 9

3.1.2 Hardware Interfaces

Since AROMS is an android application and does not require any designated hardware
there is no need to have a hardware interface. Application is installed on the tablets that
are provided by the restaurants on every table and to the key actors.

3.1.3 Software Interfaces

AROMS shall communicate with database system to store and fetch data such as order,
menu, and periodic data to generate reports.
Operating System: We have chosen Android operating system for its best support and
user-friendliness.
Database: To save the order records, Customer records we have chosen SQL+
database.
Programming Language: To implement the project we have chosen Java language for
its more interactive support.
IDE: NetBeans version 8.2 will be used to implement the project

3.1.4 Communications Interfaces

It supports wireless communication using 3G, 4G, Edge and Wireless network.
Communication function allow Internet protocol version 6 and will follow HTTPS. It will
use FTP for communicating with local server.

3.2 Functional Requirements

4. Other Nonfunctional Requirements

4.1 Performance Requirements

4.2 Safety Requirements

In the event that there is broad harm to a wide segment of the database because of
catastrophic failure, for example, a disk crash, the recuperation strategy restore a past
duplicate of the database that was upheld to archive (commonly tape) and recreates a
progressively current state by reapplying or re-trying the activities of submitted
transactions from the backed up log, up to the time of crash/failure.

4.3 Security Requirements

Workspace of the user should only be accessed through user own credentials
and any other user should not be able to access to the user private data. These
credentials of the user include his email and password. Communication
Software Requirements Specification for <Project>
Page 10

between the system and database shall use an encryption and decryption
mechanism especially when communication actor’s private data so only intended
user can view and modify his/her information. Also each user shall be restricted
in term of its right. This means that responsibilities of each actor shall only be
handled by him. System should be able to detect potential fraudulent
transactions by examining the transaction.

4.4 Software Quality Attributes

AVAILABILITY: Order should be available at a calculated time and customer

should not have to wait much for their order and receipt. This is verifiable as
estimated preparation time and actual order preparation time can be matched
to see of this requirement is met or not.

CORRECTNESS: AROMS should maintain information about order and

customer and customer should only get what he ordered.

MAINTAINABILITY: The administrator, Kitchen manger and Inventory

manager should maintain information about order, inventory and customer
credit information.

USABILITY: The order System in AROMS should satisfy at least 150

customers needs. This involves order preparation, order serving and payment
etc.

4.5 Business Rules

5. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include
database requirements, internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that are pertinent to the
project.>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or
the entire organization, and just include terms specific to a single project in each SRS.>
Software Requirements Specification for <Project>
Page 11

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class
diagrams, state-transition diagrams, or entity-relationship diagrams.>

Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the
SRS so they can be tracked to closure.>