DR.

AMBEDKAR INSTITUTE OF TECHNOLOGY

Near Jnana Bharati Campus, Bengaluru-560 056

(An Autonomous Institution, Aided by Government of Karnataka)

Software Engineering (CS51)

Assignment-1

TOPIC
IEEE standard Software Requirements Specification (SRS)

Submitted by, Submitted To,

Sourabh R Prof. Mamatha S K,

skmamatha@gmail.com
1DA17CS167
D1 Section
Ph : +91 7411728489
sourabhraobharadwaj@gmail.co
m
 Department of Computer science & Engineering
2019-2020

PREFACE
Software requirements specification (SRS) was introduced as a software process. It is
modeled after business requirements specification (CONOPS), also known as
a stakeholder requirements specification (StRS). It describes the different needs of the
business and the stakeholders. It is a documentation process of the software which helps
the user to know about the software designed and its specification. It includes user
requirements for a system as well as detailed specifications of the system requirements.
Institute of Electrical and Electronics Engineers (IEEE) model defines software
requirement specification SRS, as a document which defines describes each of the
essential requirements of the software and the external interfaces. Each requirement is
defined in such a way that its achievement can be objectively verified by a prescribed
method, for example, inspection, demonstration, analysis or test.
The requirements document is devised in a manner that is easier to write, review, and
maintain. It is organized into independent sections and each section is organized into
modules or units. Note that the level of detail to be included in the SRS depends on the type
of the system to be developed and the process model chosen for its development. For
example, if a system is to be developed by an external contractor, then critical system
specifications need to be precise and detailed. Similarly, when flexibility is required in the
requirements and where an in-house development takes place, requirements documents
can be less detailed.
Here we have described about the unified reservation system according to the IEEE
model. Unified reservation system defines the various process of reservation system for
example railway reservation system, airline reservation system, and marine reservation
system etc. In this model we have described about the airline reservation system. How the
services operated, online services provided by the system, ticket reservation, number,
airline name, airline tracking system, price variation in ticket, airline staff members details
etc…

SOFTWARE REQUIREMENT SPECIFICATION

A software requirements specification (SRS) is a description of a software system to be
developed. It is modeled after business requirements, 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. Use cases are also known as functional requirements. We can write SRS for
any system.

Features of a software requirements specification (SRS)

 Defines requirements for a software product, program or set of programs
 Usually 1 document for every program
 Does not decide on the architecture

Example:Flight management system, Railway management system,Unified Reservation

System.
The Software Requirements Specification (SRS) is a communication tool between users and software designers.
The specific goals of the SRS are as follows:

 Facilitating reviews
 Describing the scope of work
 Providing a reference to software designers.
 Providing a framework for testing primary and secondary use cases.
 Including features to customer requirements.
 Providing a platform for ongoing refinement.

IEEE STANDARDS FOR SRS:

The Institute of Electrical and Electronics Engineers publishes several dozen software
engineering standards, including IEEE Std 830-1998, "IEEE Recommended Practice for
Software Requirements Specifications." Standard 830, last revised in 1998, has since
been replaced by Standard ISO/IEC/IEEE 29148:2011, with an update in 2018.

Like many IEEE standards for software engineering, Standard 830 includes guidance and
recommended approaches for specifying software requirements. It's not a complete
tutorial on requirements development, but it does contain some useful information. The
bulk of the text is a detailed suggested template for organizing the different kinds of
requirements information for a software product -- an SRS.

The heart of the SRS consists of descriptions of both functional and nonfunctional
requirements. The IEEE standard provides several suggestions of how to organize
functional requirements: by mode, user class, object, feature, stimulus, functional
hierarchy or combinations of these criteria. There is no single organizational approach
that's best; use whatever makes sense for your project.

1. INTRODUCTION
1.1 Purpose of requirements documents
 1.2 Scope of the product
1.3 Definitions, acronyms, abbreviations
1.4 References
1.5 Overview of the remainder of document
2. OVERALL DESCRIPTION
2.1 Product perspectives
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and Dependencies

3. REQUIREMENTS SPECIFICATION
3.1 Functional Requirements
3.2 Non-functional Requirements
3.3 Specific Requirement
3.4 System Requirements
3.5 External Interface Requirements
4. APPENDICES
5. INDEX
This is an IEEE standard SRS document of “Unified Reservation System”
1. INTRODUCTION: -
This include six subunits. It provides overview of SRS of Unified reservation system.
1.1 PURPOSE: -
The purpose of this source is to describe the unified reservation system which provides
the timing details, reservation, billing and cancellation on various types of reservation
namely,
• Confirm Reservation for confirm Seat.
• Reservation against Cancellation.
• Waiting list Reservation.
• Online Reservation.
 • Cancel Reservation.

1.2 SCOPE: -
 The Unified Reservation System is a web-based application that allows people to
reserve tickets for that particular system.
 The scope of this may also include a person’s login to the system, change the
password after logging, should be able to create a new login for accessing
reservation facility and cancellation.
 Hope to provide a comfortable user experience along with the best pricing available.
 Improvised and Optimized Services

1.3 DEFINITIONS, ABBREVIATIONS: -

 SRS – software requirement specification.
 PRS - passenger reservation system.
 Customer- A registered individual who has an account and uses the application for
reservation purposes.
 Administrator- The creator or the individual who manages the application and gets
the information from the user.
 USER ID- A unique id given to every customer.
 Password- A secret code given by the customer for the protection of his/her
account.
 Clerk- who works under the Administrator.

1.4 REFERRENCES: -
 Pressman, Roger (2010). Software Engineering: A Practitioner's Approach
 Ian Sommerville. Software Engineering.
 WIKIPEDIA
 Applicable IEEE Standards are published in “IEEE standards collections”
 www.scribd.com
 www.tutorialspoint.com

2.OVERALL DESCRIPTION: -
This software includes reserving and cancelling seats for the customers. It contains
information about customer, tickets, reservation fees, concessions, cancelled tickets etc.
It contains,
a. Product perspectives
b. Product functions
c. User characteristics
 d. General constraints
e. Assumptions and dependencies
2.1 PRODUCT PERSPECTIVE: -
Before automation the system suffered from the following drawbacks
 The data, which is stored in paper only, may be lost, stolen or destroyed due to
natural calamities.
 It was difficult to update, delete, add or view the data.
 Since number of customers has increased so, it became difficult.

Hence the reservation system proposed with the following

 The machine performs all the calculations.
 Reduction in the lot of paperwork.
 It became easy to update, delete, add or view the data and cancellation of tickets
too.
 System provides for User ID validation; hence unauthorized access is prevented.

2.2 PRODUCT FUNCTIONS: -

 Search - This function allows the booking agent to search according to their
requirement.
 Selection - This allows a particular option to be selected from displayed list to
book tickets.
 Review - If the seats are available, then the software prompts for booking.
 Payment - The payment process can be through credit/debit card. It includes
credit card type, number, CVC number, expiration date, Name on the card.
 Cancellation - The system allows the customer to cancel an existing
reservation.

2.3 USER CHARACTERISTICS: -

 Educational level - at least user of the system should be comfortable with
English language.
 Technical expertise – user should be comfortable using general purpose
applications on computer system.

2.4 GENERAL CONSTRAINTS: -

 These are the conditions for reservations.
 The system will run under Windows98 and higher platforms of OS.

2.5 ASSUMPTIONS AND DEPENDENCIES: -

  Software needs booking agent to have complete knowledge of reservation
system.
 Each user will have valid user name and password to access the system.
 Software is dependent on access to Internet.

3.REQUIREMENT SPECIFICATION: -

3.1 FUNCTIONAL REQUIREMENTS: -

Some of the Functional Requirements are:

Reliability: - The factors needed to establish the software expected reliability are:-
 The user inputs should be valid and within the given range.
 Normal termination of the program.

Availability: - The factors guarantee the software’s availability includes proper

termination and correct input details. Also the resources used for the project
development are Microsoft Certified which speaks of its high quality standards.
Security: - It must be ensured that access will be provided to the authorized
persons through user ID and password. Network security will be provided by the
use of firewalls. Checks can be performed at regular intervals to ensure data
integrity.
Maintainability: - The software will be developed by implementing the concept of
modularity which in turn reduces the complexity involved in maintaining it. The
administrator should have a sound technical knowledge about maintaining the
software and further enhancements will be undertaken by the developer.

 Every online booking needs to be associated with an account.

 One account cannot be associated with multiple users.
 Search results should enable users to find the most recent and relevant
booking options.
 System should enable users to book / pay for their tickets only in a timeboxed
manner after tickets being added to the cart.
 System should only allow users to move to payment only when mandatory
fields such as date, time, location has been mentioned.
 System should consider time zone synchronization when accepting bookings
from different time zones.
  Booking confirmation should be sent to user to the specified contact details.

3.2 NON-FUNCTIONAL REQUIREMENTS: -.

Some of the Attributes of Non functional requirements are:

1. SAFETY REQUIREMENTS

If there is extensive damage to a wide portion of the database due to catastrophic

failure, such as a disk crash, the recovery method restores a past copy of the
database that was backed up to archival storage (typically tape) and reconstructs
a more current state by reapplying or redoing the operations of committed
transactions from the backed up log, up to the time of failure.
2. SECURITY REQUIREMENTS

Security systems need database storage just like many other applications.
However, the special requirements of the security market mean that vendors must
choose their database partner carefully.
3. SOFTWARE QUALITY ATTRIBUTES

 AVAILABILITY: The flight should be available on the specified date and specified
time as many customers are doing advance reservations.
 CORRECTNESS: The flight should reach start from correct start terminal and
should reach the correct destination.
 MAINTAINABILITY: The administrators and flight in chargers should maintain
correct schedules of flights.
 USABILITY: The flight schedules should satisfy a maximum number of customer’s
needs.
 Search results should populate within acceptable time limits.
 User should be helped appropriately to fill in the mandatory fields, in case of
invalid input
 Use of captcha and encryption to avoid bots from booking tickets.

3.3 SPECIFIC REQUIREMENTS: -

 Requirement Specification a complete description of the behavior of a system to be

developed and may include a set of use cases that describe interactions the users
will have with the software.
  In addition, it also contains nonfunctional requirements.

3.4 SYSTEM REQUIREMENTS: -

 The requirement definition is concerned with the analysis of the existing system with
the aim of determining and structuring the requirement of the proposed system.
 It is achieved with the aid of user requirement.

3.7 INTERFACE REQUIREMENTS

1. User Interfaces: - The interface must be easy to understand. The user interface
includes

Mobile screen Platform: The introductory screen will be the first to be displayed which
will allow the users to choose either of the two options, viewing flight detail or booking
a ticket.
Windows Platform: When the user chooses some other option, then the information
pertaining to that choice will be displayed in a new window which ensures multiple
windows to be visible on the screen and the users can switch between them.
DATA FORMAT: The data entered by the users will be alphanumeric.
2. Hardware Interfaces: - The system must basically support certain input and output
devices. Their descriptions are as follows.
Name of Item Description of Purpose Source of Input/Description of output Key board
to accept data from user like pin code, personal details, flight details Source of Input
Printer to print the bookings mode E.g.: Destination chosen with date and timings
Destination of Output.
3. Software Interfaces: -The user of the application need not use the software
interface since the software portion is only used by the developers.
4. Communication interface: -The user might want to communicate with the service
operator to know about some of the information about the software. So for those kinds
of purposes the user and the developer might need a communication interface for
easy work.
DOMAIN REQIREMENT

This is the requirement the user as well as the developer both need because it helps
to improve the software with the help of the user means taking some advice from the
user. When a user sitting uses the application developed by the developer it might not
work properly every time due to many factors such as internet problem banking
problem or the software server problem. In those cases the user might need to report
the problem to the developer of the software so that they can use the software very
 efficiently and effectively. These things are required for both the user as well as the
software developer.

3.6 EXTERNAL INTERFACE REQUIREMENTS: -

3.5 Used Tools and Platforms: -

3.5.1 Software specification

Front-end tool – HTML and CSS

 User friendly
 Low cost solution
 GUI features

Back-end tool – MY SQL WORKBENCH

 Portability
 Quality
 Security

PLATFORM

 Windows platform like: Windows 8, XP &

Windows 10
 LINUX
 MAC OS

3.5.2 Hardware Specification

 Intel Pentium and Celeron class processor
 Processor speed-1.2Ghz or above
 RAM-2GB
 HDD-500 GB
 Monitor-14” SVGA
 Printer-Laser Printer

4. APPENDICES: -
Glossary
 This part involves acronyms and abbreviations used.
 SRS: Software Requirement Specification
 SQL: Structured Query Language
 DESC: Description
 UML: Unified Modeling Language

ANALYSIS MODELS
Includes any analysis models such as data flow diagrams, class diagrams, state-
transition diagram or entity relationship diagrams.
5.INDEX: -
1. INTRODUCTION
1.1 Purpose of requirements documents
1.2 Scope of the product
1.3 Definitions, acronyms, abbreviations
1.4 References
2. OVERALL DESCRIPTION
2.1 Product perspectives
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and Dependencies
3. REQUIREMENTS SPECIFICATION
3.1 Functional Requirements
3.2 Non-functional Requirements
3.3 Specific Requirement
3.4 System Requirements
3.5 External Interface Requirements
4. APPENDICES