Experiment 3

Aim: Write the Software Requirement Specification (SRS) document of Railway

Reservation System.

Theory: Software Requirement Specification (SRS) document usually contains a

software vendor’s understanding of a customer’s software requirements. This document
ensures that the software vendor and the customer are in agreement as to the features
required in the software system being built. SRS is created after the initial requirement
elicitation phase in which Software vendor interacts with the customer to understand
the software needs. Usually, SRS documentation is prepared by a business analyst who
has some technical background. An SRS is written in precise, clear and plain language
so that it can be reviewed by a business analyst or customer representative with minimal
technical expertise. However, it also contains analytical models (use case diagrams,
entity relationship diagrams, data dictionary etc.) which can be used for the detailed
design and the development of the software system. SRS is one of the most critical
pieces of software development since it acts as the bridge between the software
developers and business analysts. An incomplete or incorrect SRS can have disastrous
effects on a software project. In this article I explain the major sections of a typical
Software Requirement Specification document. I also provide a generic SRS template
which can be customized for your project needs.

What are the contents of an effective SRS document?

There is no single precise template for writing good Software Requirement
Specifications. The contents of an SRS document depend on the software product being
developed and also on the expertise of the people doing the requirement elicitation.
Different business/technology domains in a company usually have their own
customized version of SRS template. Still a good Software Requirement Specification
(SRS) usually contains project scope section, functional requirements, requirement
analysis models, external interface requirements and non-functional requirements.

Outcome:

1
 Table of Contents

1. Introduction 3
1.1. Purpose 3
1.2. Scope 3
1.3. Definition, Acronym, Abbreviation 4
1.4. References 4
1.5. Overview 4
2. Overall Description 5
2.1. Product Perspective 5
2.2. Product Functions 6
2.3. Operating Environment 6
2.4. Design And implementation Constraints 7
2.5. User Characteristics 7
2.6. Assumptions and Dependencies 7
3. Specific Requirements 8
3.1. External Interface Requirements 8
3.1.1. User Interfaces 8-13
3.1.2. Hardware Interfaces 13
3.1.3. Software Interfaces 13
3.1.4. Communication Interfaces 13
3.2. Functional Requirements 14-22
4. System Features 23-24
5. Other Non-Functional Requirements 24
5.1. Performance Requirements 24
5.2. Safety Requirements 24
5.3. Security Requirements 24
5.4. Software Quality Attributes 24
Appendix A: Glossary 25

2
1. INTRODUCTION
A Web-Based Railway Reservation System is to be developed. The system is going to be
distributed in nature. It will store the information about train name, train schedules, availability.
The administrator will be able to make any changes related to the train information like change
in train name, number etc. The system will be able to reserve seats in a train for a passenger.
First the system will check for availability of the seats in a particular train on a specified date
of journey and if it is available the customer can reserve seats. The passenger will be given a
unique PNR no. The system will be able to cancel a reservation. The system will delete the
entries in the system. The passenger can check their reservation status online by entering their
PNR no. The system will display his current status like confirmed, RAC or waiting list. They
are also able to see information related to the train schedules.

1.1. Purpose
The purpose of this document is to present a detailed description of the Railway Reservation
System. It will explain the purpose and features of the software, the interfaces, configuration
and workflow of the software, what the software will do and the constraints under which it
must operate. This document is intended for users of the software and also potential developers
to understand the software before its usage. The document is subject to change as the project
progresses. The given version of the document is the initial one. Further changes of the project
will be recorded to the document.

1.2. SCOPE
• The product is titled Railway Reservation System.
• The product will perform the following tasks –
o The software, being developed, can be used by the customers
▪ to search trains on the basis of boarding and destination station.
▪ to book seats in selected train.
▪ to make payment against their reservations.
▪ to cancel reserved tickets.
o Allows admin to manage users, trains, reservations, payments, cancellations in
the system.

1.3. Definition, Acronym, Abbreviation

This should define all technical terms and abbreviations used in the document

• NTES – National Train Enquiry System

• IVRS – Interactive Voice Response system

• RRS – Railway Reservation system

• DFD – Data Flow Diagram

• SRS – Software Requirements Specification

3
1.4. References

▪ Object-Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra, PHI

Learning Pvt. Ltd., 2012.
▪ https://www.youtube.com/watch?v=4fYy4l3sSKU&ab_channel=SoftwareEngineerin
g
▪ https://en.wikipedia.org/wiki/Ticketing_and_Reservation_System
▪ https://www.slideshare.net/shashankkarnati/railway-management-system-database-
mini-project

1.5. Overview

• The SRS contains an analysis of the requirements necessary to help easily design the
system.

• The overall description provides interface requirements for the Railway Reservation
System, product perspective, hardware interfaces, software interfaces, communication
interface, memory constraints, product functions, user characteristics, and other
constraints.

• Succeeding pages illustrate the characteristics of typical naïve users accessing the
system along with legal and functional constraints enforced that affect the Railway
Reservation System in any fashion.

2. OVERALL DESCRIPTION
This document contains the problem statement that the current system is facing which is
hampering the growth opportunities of the company. It further contains a list of the stakeholders
and users of the proposed solution. It also illustrates the needs and wants of the stakeholders
that were identified in the brainstorming exercise as part of the requirements workshop. It
further lists and briefly describes the major features and a brief description of each of the
proposed system.

2.1. Product Perspective

Before the automation, the system suffered from the following drawbacks:

• The previous system was highly manual involving a lot of paper work and calculation
and therefore may be erroneous. This has led to inconsistency and inaccuracy in the
maintenance of data.

• The data, which is stored on the paper only, may be lost, stolen or destroyed due to
natural calamity like fire and water.

4
 • The previous system was sluggish and consumes a lot of time causing inconvenience
to customers and the railways staff.

• Due to manual nature, it is difficult to update, delete, add or view the data.

• Since the number of passengers have drastically increased therefore maintaining and
retrieving detailed record of passenger is extremely difficult.

• Railways has many offices around the world, an absence of a link between these offices
lead to lack of coordination and communication.

Hence the railways reservation system is proposed with the following:

• The computerization of the reservation system will reduce a lot of paperwork and hence
the load on the railway administrative staff.

• The machine performs all calculations. Hence chances of error are nil.

• The passenger, reservation, cancellation list can easily be retrieved and any required
addition, deletion or updating can be performed.

• The system provides for user-ID validation, hence unauthorized access is prevented.

2.2. Product Functions

1. A system that is to be implemented will run on the web server.

2. The system will be easy to use such that customers with familiarity of computers can
use the system.
3. The system shall be able to generate Login Id and password to the system operator.
4. There are 2 types of members in the Railway Reservation System: Customer and
Administrator.
5. The administrator shall be able to maintain all the details of trains available on the
system.
6. The system shall be able to allow customers to reserve tickets according to their need.
7. The system should give the customer the option to cancel the reserved tickets within
the stipulated time.
8. A customer as a guest user can only check the available trains, skim through them but
cannot reserve them until logged in.
9. The system shall be able to fetch the details of all the trains.
10. The system administrator shall be able to update the overall content of the software,
look through the customer profiles, trains, reservations, payments, cancellations in the
system.

5
2.3. Operating Environment

2.3.1 Hardware Requirement:

• Any general-purpose CPU will work for this software but it must be after 2nd generation
to run a web server.
• A computer system with at least 1 GB of RAM will be required for the smooth function
of this application.
• Mobile or desktop for end-users to reserve tickets.

2.3.2 Software Requirement:

The RRS is designed to be accessed through most of the versions windows operating systems,
Linux or Unix operating system such as:

• Windows 2000
• Windows XP
• Windows Vista
• Windows 7
• Windows 8
• Windows 10
• Any Linux distribution - Ubuntu, Fedora, Kali Linux
• Unix operating system.

2.4. Design and Implementation Constraints

The Railway Reservation System is developed in PHP language. We are using MySQL for the
database. We are using CSS framework bootstrap for its rich user-friendly interface and
JavaScript library jQuery for Dynamic Content Delivery.

2.5. User Characteristics

• Education Level - User of the system should be atleast comfortable with English
language.
• Technical Expertise - User should be comfortable using general purpose applications
on the computer system.

2.6. Assumption and Dependencies

• Customers will be having a valid user name and password to access the software.
• The software needs customers to have complete knowledge of railways reservation
system.
• Software is dependent on access to internet.
• Further, it is assumed that the project is robust and scalable which will increase the
scope of the project rapidly in the future.

6
3. SPECIFIC REQUIREMENTS

3.1 External Interface Requirements

3.1.1 User Interfaces

3.1.1.1 Home Page

3.1.1.2 Sign Up Page

7
3.1.1.3 Login Page

3.1.1.4 User Profile

8
3.1.1.5 Search Train

3.1.1.6 Reserve Ticket

9
3.1.1.7 Add Passenger

3.1.1.8 Booked Ticket Status

10
3.1.1.9 Booked Tickets History

3.1.1.10 Change Password

11
3.1.1.11 Edit Profile

3.1.2. Hardware Interfaces

The minimum hardware requirements of Railway Reservation System are a 1 Gigahertz CPU
and 1 Gigabytes of RAM. The system must interface with the standard output device,
keyboard and mouse to interact with this software.

3.1.3. Software Interfaces

RRS is a desktop application and designed to be accessed by most of the versions of windows
operating systems.

3.1.4. Communication Interfaces

RRS might require an internet connection to install new updates.

12
3.2. Functional Requirements
3.2.1 Login Use Case Description:
1.1) Introduction: This use case describes how a user logs into the Railway Reservation
Management system

1.2) Actors: (i) Customer

(ii) Administrator

1.3) Pre-Condition: None

1.4) Post Condition: If the use case is successful, the actor is logged into the system. If not,
the system state is unchanged.

1.5) Basic Flow: This use case starts when the actor wishes to login to the Reservation
Management system.

i. System requests the actor to enter his/her UserId and password.

ii. The actor enters his/her UserId & password.
iii. System validates UserId & password, and if finds correct allow the actor to logs into
the system.

1.6) Alternate Flows: If in the basic flow, the actor enters an invalid UserId or password, the
system displays an error message. The actor can choose to either return to the beginning
of the basic flow or cancel the login, at that point, the use case ends.

1.7) Special Requirements: None

1.8) Associated use case: None

3.2.2. View Train Detail Use Case Description:

2.1) Introduction: This use case allows the customer to view the train details which include the
timings and the seat availability along with the other details.

2.2) Actors: Customer

2.3) Pre-Condition: Customer must be logged on to the system before this use case starts.
2.4) Post Condition: None

2.5) Basic Flow: This use case starts when the customer wants to view the trains according to the
journey planned by the customer
(i) System requests that the customer enters the boarding station and destination station along
with the date of journey or enter train number.
ii) System validates the boarding station, destination station and the date of journey or train
number and if finds correct it displays all the list of the trains that fulfil criteria.

13
2.6) Alternate Flows: If in the basic flow, the actor enters an invalid set of details then the error
message is displayed. The customer can choose to either return to the beginning of the basic flow
or cancel the process, at that point, the use case ends.
2.7) Special Requirements: None
2.8) Associated use case: Login, View by train number, View by boarding station and destination

3.2.3. Book Tickets Use Case Description:

3.1) Introduction: This use case describes how a user books the tickets for a particular train.

3.2) Actors: Customer

3.3) Pre-Condition: The user must be logged onto the system before this use case starts
3.4) Post Condition: If the use case is successful, the actor is directed to the make payment use
case. If not, the system state is unchanged.
3.5) Basic Flow: This use case starts when the actor wishes to book tickets for a particular train
(i) System requests that the customer enters the boarding station and destination station along
with the date of journey
ii) System validates the boarding station, destination station and the date of journey, and if finds
correct it displays all the list of the trains that fulfil criteria.
iii) Then the user can select to book trains from the list with its train coach category.
(iv) System requests the user to enter the details of passenger
(v) The actor enters the details of the passenger.
(vi) System validates the details of the passenger and if they are correct then the user is shown
the amount to be paid and is directed to the make payment use case.

3.6) Alternate Flows: If in the basic flow, the actor enters an invalid set of details then the error
message is displayed. The customer can choose to either return to the beginning of the basic flow
or cancel the process, at that point, the use case ends.

3.7) Special Requirements: None

3.8) Associated use case: Login, Make Payment

3.2.4. Make Payment Use Case Description:

4.1) Introduction: This use case describes how a user pays the total amount after selecting some
tickets for the trains

4.2) Actors: (i) Customer

4.3) Pre-Condition:
(i)The user must be logged onto the system before this use case starts.
(ii) The customer must have selected the tickets and entered the details of passenger in the
book tickets use-case.

14
4.4) Post Condition: If the use case is successful, the actor is directed to the payment gateway. If
not, the system state is unchanged.
4.5) Basic Flow: This use case starts when the actor wishes to pay the amount for the selected
tickets.
(i) System redirects the customer to payment gateway (Ex- SBI MOPS)
(ii) The actor selects the mode of payment.
(iii) System validates mode of payment, and if finds that it is correct then payment will be done
accordingly.
4.6) Alternate Flows: If in the basic flow, the actor enters an invalid mode of payment, the system
displays an error message. The actor can choose to either return to the beginning of the basic flow
or cancel the login, at that point, the use case ends.

4.7) Special Requirements: None

4.8) Associated use case: Login, Booking

3.2.5. View Reservation Status Use Case Description:

5.1) Introduction: This use case describes how a user can check the current reservation status for
the tickets booked by the user

5.2) Actors: (i) Customer

5.3) Pre-Condition:
(i) The user must be logged onto the system before this use case starts
(ii) The user must have at least one booked ticket
5.4) Post Condition: None

5.5) Basic Flow: This use case starts when the actor wishes to check the current reservation status
for the booked tickets
(i) System displays all the booked tickets by the user which have the dates which are upcoming
and requests the user to select the booked ticket to check the reservation status
(ii) The actor selects the booked ticket
(iii) System validates the booked ticket and displays the current status of reservation whether it
is confirmed, RAC or in WL.

5.6) Alternate Flows: If the reservation status of the ticket is not confirmed then the user has the
option to return to the basic flow or to move to the cancel ticket use case.

5.7) Special Requirements: None

5.8) Associated use case: Login

15
3.2.6. Cancel Tickets Use Case Description:

6.1) Introduction: This use case describes how a user cancels the booked tickets

6.2) Actors: (i) Customer

6.3) Pre-Condition
i. The user must be logged onto the system before this use case starts
ii. The user must have at least one booked ticket before the start of this use case
6.4) Post Condition: If the use case is successful, the booking state of the ticket changes from
booked to cancelled and the refund amount use case will be initiated.

6.5) Basic Flow: This use case starts when the actor wishes to cancel the booked ticket
i. System displays the booked tickets by the user and request the user to select the ticket
which has to be cancelled.
ii. The actor selects the booked tickets.
iii. System validates book ticket details, and if finds correct then requests for the confirmation
from the user.
iv. If the user confirms the cancellation and the ticket will be cancelled and will be marked in
database as an empty seat.
v. Then Refund Amount use case will be initiated by the Payment Gateway.

6.6) Alternate Flows: If in the basic flow, the actor refuses the confirmation then the system
returns to the same cancellation page. The actor can choose to either confirm again or cancel
the process, at that point, the use case ends.

6.7) Special Requirements: None

6.8) Associated use case: Refund Amount, Login

3.2.7. Generate and Print Reports Use Case Description:

7.1) Introduction: This use case describes how a user can print reports like train reservation
chart, train reports etc.

7.2) Actors: (i) Administrator

7.3) Pre-Condition: The user must be logged onto the system before this use case starts.

16
7.4) Post Condition: If the use case is successful, printer will execute the print command.
7.5) Basic Flow: This use case starts when the actor wishes to generate & print reservation or
train reports

i. The actor can search trains with any of the train number, train name or boarding station.
ii. System validates the train number/train name/boarding station, and if finds correct it
displays all the list of the trains that fulfil criteria.
iii. Then the actor can select the train to print reports related to it.
iv. The actor can customize the report he wants to generate like daily train reservation charts,
monthly reports related to its scheduling, staff allotted etc.
v. Then actor will give print command, then a preview will be displayed and it requests for a
confirmation from the actor.
vi. If the actor confirms then printer prints the report.
7.6) Alternate Flows: If in the basic flow, the actor refuses the confirmation then the system
returns to the previous page. The actor can choose to either submit again or cancel the
process, at that point, the use case ends.
7.7) Special Requirements: None

7.8) Associated use case: Login

3.2.8. Manage All Users Use Case Description:

8.1) Introduction: This use case describes how an admin can manage details of another user.

8.2) Actors: (i) Administrator

8.3) Pre-Condition: The user must be logged onto the system before this use case starts.

8.4) Post Condition: If the use case is successful, the changes will be reflected to the system
database.
8.5) Basic Flow: This use case starts when the actor wishes to see and manage user details.

i. The actor can search users with the help of their UserId.
ii. The actor can check authenticity of the user and can change his details and modify it
if necessary.
iii. Then a preview will be displayed and it requests for a confirmation from the actor.
iv. If the actor confirms then the changes will be done in the database.
8.6) Alternate Flows: If in the basic flow, the actor refuses the confirmation then the system
returns to previous page to edit details. The actor can choose to either submit again or
cancel the process, at that point, the use case ends.

8.7) Special Requirements: None

8.8) Associated use case: Login

17
3.2.9. Manage Train Details Use Case Description:
9.1) Introduction: This use case describes how a user can manage (add/delete/modify) train
detail in system database.
9.2) Actors: (i) Administrator
9.3) Pre-Conditions: The user must be logged onto the system before this use case starts.

9.4) Post Condition: If the use case is successful, the changes will be reflected to the system
database.
9.5) Basic Flow: This use case starts when the actor wishes to edit any train detail in the system.

(i) The system asks the actor if he want to add/delete/modify a train.

(ii) If actor selected to add a train, he will be directed to add train page.
(iii) The actor will then fill train details like train number, train name, train route, its schedule,
seats available, categories of seats etc and then submit it for a preview of details filled.
(iv) Then a preview will be displayed and it requests for a confirmation from the actor.
(v) If the actor confirms then the changes will be done in the database.
(vi) If actor selected to delete a train information, he will be directed to delete train page.
(vii) Then the actor can search trains with any of the train number, train name or boarding
station.
(viii) System validates the train number/train name/boarding station, and if finds correct it
displays all the list of the trains that fulfil criteria.
(ix) Then the actor can select the train to delete from the list.
(x) System will then ask for confirmation from the actor, if confirmed, that train database will
be deleted.
(xi) If actor selected to modify a train information, he will be directed to modify train page.
(xii) The actor can search trains with any of the train number, train name or boarding station.
(xiii) System validates the train number/train name/boarding station, and if finds correct it
displays all the list of the trains that fulfil criteria.
(xiv) Then the actor can select the train from the list to edit its details.
(xv) The actor will then can edit train details like train number, train name, train route, its
schedule, seats available, categories of seats etc and then submit it for a preview of details
filled.
(xvi) Then a preview will be displayed and it requests for a confirmation from the actor.
(xvii) If the actor confirms then the changes will be done in the database.
9.6) Alternate Flows: If in the basic flow, the actor refuses the confirmation then the system
returns to previous page to edit details. The actor can choose to either submit again or cancel the
process, at that point, the use case ends.

9.7) Special Requirements: None

9.8) Associated Use Case: None

18
3.2.10. Cancellation Charges Use Case Description:
10.1) Introduction- This use case describes how cancellation charges will be calculated according
to the date of cancellation with respect to date of journey.

10.2) Actors- None

10.3) Pre-Condition-
i) User must be logged in into system.
ii) User must have atleast one booked ticket

10.4) Post-Condition- If the cancellation is successful, user will be provided with calculated
refund amount via payment gateway within 7 working days.

10.5) Basic Flow- This use case will start when the customer interacts with cancel tickets use
case.
i) System will fetch details from cancel ticket use case and calculate cancellation
charges according to following slabs:
Duration Cancellation Charges
Less than 4 hours 100%
Between 4hours and 24 hours 50%
Between 24 hours and 48 hours 25%
More than 48 hours 0%

10.6) Alternate Flow- None

10.7) Special Requirement- None

10.8) Associated Use case- Login, Cancel Tickets, Refund Amount

4. SYSTEM FEATURES
This section demonstrates RRS’s most prominent features and explains how they can be used
and the results they will give back to the user.

4.1 Login
• This function will allow a registered customer to log in to his/her account on the RRS.
The user will enter his/her username and password to login into the system. If a user is
not registered, the website will allow the user to sign up in the system, and then he/she
can reserve a ticket. However, any user can view the trains in the system without any
login/signup.
• This provides security to the system by authenticating each member and provides
confidence to the customer that his/her personal information is secure.

19
4.2. Search Train
• This function provides a customer to search trains on the basis of train number/train
name/ origin and destination even without login to the system.

4.3. Book Tickets

• The user can use the Book Tickets function to reserve any seat in the RRS. The system
shall present the customer a list of all the related trains which he/she has searched for
in the system. Customer can select the train according to his/her specifications and then
book the tickets. Finally, the system will guide the customer completely through the
checkout process.
• The heart of the business is selling train tickets to the customers. This section provides
the primary source of system transactions.

4.4. View Reserved Tickets

• Customers can use the View Reserved Tickets function to view the tickets booked by
him/her. Every information about the ticket which is reserved by the customer will be
shown by this function such as time of reservation, details of ticket, payment details,
availability of cancellation, etc.

4.5. Cancel Reserved Tickets

The customers can use the Cancel Reserved tickets function to cancel the already reserved
tickets. The system shall present the user with tickets which can be cancelled and show the
refund amount according to refund policy. The customer may then select the corresponding
ticket, which needs to be cancelled. Finally, the system shall guide the user through the
cancellation process and refund policy.

4.6. Logout
• The Logout section provides a way for the customer to securely log out of the system.
This process will save all user operations when he/she exits the system. If a user wishes
to continue accessing the website, he/she must log in again to access user features.
• Customers often use shared computers. Providing a way to clearly state and log out
gives our customers confidence that nobody else will use their data.

5. OTHER NON-FUNCTIONAL REQUIREMENTS

5.1. Performance Requirements
The minimum hardware requirements of the Course Reservation System are 1 Gigahertz CPU
and 1 Gigabytes of RAM. The system must interface with the standard output device, keyboard,
and mouse to interact with this software.

20
5.2. Safety Requirements
To ensure that no one of RRS’s users loses any data while using RRS (due to a crash or a bug
of some kind) the developer team updates RRS regularly.

5.3. Security Requirements

RRS has two levels of users each with different privileges i.e.
● Administrator who is the super user and can perform most of the functions in the system such
as managing users, trains, routes, payments, bookings.
● Customer who can view trains without login and can book tickets, cancel tickets, search
booked history after log in.

5.4. Software Quality Attributes

RRS provides the users with very simple features. Due to its well-designed and easy-to-use
interface, it can be used by any user. However, users must already have a basic knowledge of
using a computer.

APPENDIX A: GLOSSARY
SRS- Software Requirements Specification
CPU- Central Processing Unit
RRS- Railway Reservation System
RAM- Random Access Memory
NTES – National Train Enquiry System
IVRS – Interactive Voice Response system
DFD – Data Flow Diagram

Learning: We have successfully understood and written SRS document for Railway
Reservation System.

21