Software Requirement Specification Software Engineering

Software Requirement
Specification
Software Engineering
CS 2002
Software Requirement Specification

CS 2002
Table of Contents
1.
Introduction .......................................................................................................................... 2
1.1 Purpose ............................................................................................................................. 2
1.2 Intended Audience and Reading Suggestions .................................................................. 2
1.3 Project Scope .................................................................................................................... 3
1.3.1
Definitions................................................................................................................. 4
1.3.2 Acronyms and Abbreviations ........................................................................................ 5
2. General characteristics ...................................................................................................... 6
2.1 Product Perspective .......................................................................................................... 6
2.2 Product Functions ............................................................................................................. 6
2.3 User Classes and Characteristics ...................................................................................... 7
2.3.1
Role based access ...................................................................................................... 7
2.4 Constraints........................................................................................................................ 8
2.4.1
Design and Implementation Constraints ................................................................... 8
2.5 Project Documentation ..................................................................................................... 9
2.6 Assumptions and Dependencies ....................................................................................... 9
3. System Features ................................................................................................................ 10
3.1 Functional requirements ................................................................................................. 10
3.2 Entity Relationship Diagram .......................................................................................... 11
4. External Interface Requirements ................................................................................... 12
4.1 External Interfaces.......................................................................................................... 12
4.2 User Interfaces................................................................................................................ 12
4.3 Hardware Interfaces ....................................................................................................... 16
4.4 Software Interfaces ......................................................................................................... 16
4.5 Communications Interfaces ............................................................................................ 16
5. The Nonfunctional Requirements .................................................................................. 17
5.1 Performance Requirements ............................................................................................ 17
5.2 Safety Requirements ...................................................................................................... 17
5.3 Security Requirements ................................................................................................... 17
5.4 Software Quality Attributes ........................................................................................... 17
5.5 Business Rules................................................................................................................ 18
6. Appendix ............................................................................................................................ 19
6.1 References ...................................................................................................................... 19
7. Group Members ................................................................................................................ 19
Railway Reservation System
Page 1

CS 2002
1. Introduction
1.1 Purpose
This Software Requirement Specification (SRS) specifies the requirements of the Railway
Reservation System which provides the train timing details, reservation, billing and cancellation
on various types of reservation namely,

Arrival and departure details

To confirm the reservation of seats.
Train delay alert services
Reservation against cancellation.
Handling of train tickets
Online Reservation.
Using these systems Ticket Counter person can perform operations like finding out the train
timings and to know information about seats availability and costs of each ticket etc.
1.2 Intended Audience and Reading Suggestions

The intended audience can vary. They would be developers, testers, and document
writers. They refer this document for various purposes such as developing, testing and
documenting letting the users to have better understanding about the system mainly the endusers, system users and managers, and others who interested on this system are the intended
audience of this document.

Developer team who develops this system.

The administrative staff of SLRA.
Operators- Person who uses the system.
Tester- Person who does the testing process.
Documentation writers- person who does the documentation of the system.
Academic evaluators and supervisors
Page 2

CS 2002
1.3 Project Scope

The project mainly focuses to handle manual activities by converting into an automated
desktop system and a web based system, which reduces workload of passengers and officers in
SLRA. System reduces the human involvement of entering data and using imported data
company management can perform detailed analysis. Management can monitor and control the
train reservation functions easily. Stand-alone application will replace the current manual
system.
By converting to a fully automated system, the users who are working with the system
can do their manual activities automatically. Saving time is the most effective advantage in this
system. The proposed system has included new features to overcome the problems in current
system and user meets more benefits rather than the current system. It reduces the human
resource involvement of entering data. And using imported data, SLRA management can
perform detailed analysis about the train reservation and so forth. As the system is a web based,
system SLRA management can access it from anywhere and use it. Newly proposed system
comes up with security features for avoiding access to the system by unauthorized persons. The
project provides a user-friendly reliable system that is having high performance and concurrent
user access.
The following functionality is required,
Creating an account by registering, modify account details, deregister from the services
Making a fresh multi passenger reservations, the customers are provided to choose their
berths/reservation spots rather than being randomly allocated positions
Viewing , modifying or cancelling past reservations
Customers are provided with different reservation status, just as in real life systems
Consumers are informed, through emails, about updates in the reservations and trains
Consumers are informed about the various seasonal offers and discounts.
Page 3

CS 2002
1.3.1 Definitions
System
System refers to the railway reservation system which provides the train timing details,
reservation, billing and cancellation on various types of reservation.
Server
A computer, or a software package, that provides a specific kind of service to the client
software running on other computers. In the case of our system, it refers to the server used by
the SLRA.
Database
This term is generally referred with the term Database Management System. A database is a
set of data that has a regular structure and that is organized in such a way that a computer can
easily find the desired information.
LAN
The LAN refers to Local Area Network, a computer network that spans around a relatively
small area. Most LANs are confined to a single building or a group of buildings. This refers to
the networking capability within by the SLRA.
Apache
Apache is the most popular Web server software. It enables a computer to host one or more
websites that can be accessed over the Internet using a Web browser.
PHP
The PHP Hypertext Preprocessor allows web developers to create dynamic content that
interacts with databases. This is a server side scripting language which is used to create the
backend of the web site.
Java Script
Java Script is a user interface scripting language developed by Netscape for its Navigator and
Communicator World-Wide Web browsers. This is the scripting language of the web which is
used to add functionalities to the web site
WAMP
Windows + Apache + My SQL + PHP
Page 4

CS 2002
1.3.2 Acronyms and Abbreviations

CMS - Content Management System
DBMS - Database Management System
SLRA- Sri Lankan Railway Authority
GB - Giga Bytes
GUI - Graphical User Interface
HTML - Hyper Text Markup Language
HTTP - Hyper Text Transfer Protocol
IE - Internet Explorer
LAN - Local Area Network
PC - Personal computer
PHP - Hypertext Preprocessor
RAM - Random Access Memory
SAD - Systems Analysis and Design
SQL - Structured Query Language
SRS - System Requirements Specification
Page 5

CS 2002
2. General characteristics
2.1 Product Perspective
The railway reservation system includes a web reservation system which enables the customers
to gain the train details like their timings, number of seat available and reservation billing and
cancelling the tickets.
To expand the scope of travelling the following features are expected.
Providing existing clerks with a new environment in which to make reservations for train
travelling.
Providing an avenue for customers to get their tickets in a more convenient way.
Regaining control of the railway ticket sales to avoid scalping and overselling of tickets.
Implementing a prototype of a scaled down version of the final system to test the solution
and further develop requirements.
Collecting statistics in a more efficient manner for future railroad development and
construction.
Increasing efficiency of railroads.
Therefore people can interact with the system by reserving seats and trains online and
paying using credit cards.
2.2 Product Functions

Log in Ensuring that only authorized users gain access to the Reservation databases.
Typing a valid username and password is essential to gain access.
Reserve Allowing the user to make a reservation for a particular train on a particular
date for a certain number of tickets.
Display train schedule information Allowing the user to see a list of all scheduled
train departures including train name, city from and to which the train is going, the
number of seats available, and the prices for different ticket types.
Pay reservation Allowing the user to pay his/her current reservation cost. The user
may either pay entire balance due or select to pay in person within 48 hours. The user
must also input a valid credit card number.
Cancelling the reservation Allowing the user to cancel the reserved train.
Manager Online Features Viewing reservations and payments.
Page 6

CS 2002
Passenger Online Features Viewing the information and facilities in SLRA.
2.3 User Classes and Characteristics

2.3.1 Role based access
SLRA Operator
This is the administrator of the site and able to access the system any time and any level.
Functions of the SLRA operator includes checking the availability of the reservation
made by the registered passenger and confirming the reservation, cancelling the
reservation and accepting the payments made by the passenger for the ticket.
The use case diagram for the SLRA Operator is given below:
Figure 1.1
User
Users will be able to visit the web site and have the access to most basic features of the
site including train timing details, train information, information about the ticket
reservation etc. Users don't have access to more advance features. In order to so users
must register and become a registered passenger. Figure 1.2 illustrates the use case
diagram for guest user.
Figure 1.2
Page 7

CS 2002
Registered Passenger
Registered passengers are the users that have given their information and registered in the
system. They are able to login to the system and are able to access the more advance
features of the system including checking the availability of the seats, making ticket
reservations, making payments for the reserved tickets using credit cards, making
cancellation of the reservations they have done etc. The use case diagram for the
Registered Passenger is given below:
Figure 1.3
2.4 Constraints
The Constraints for the project are:
The number of passengers that can be taking a train at once is limited to 500 passengers.
Reservation should be done prior to 60 days of the journey.
Cancellation should be done prior to 30 days of the journey
Only 5 tickets are issued per one person
Payments can be done through credit cards only. Cash is not expected.
Scalping of tickets is a popular activity in Sri Lanka, and SLRA wants to discourage
such practices
2.4.1 Design and Implementation Constraints
The passenger is responsible to do the pricing since we do not have access to the
accounts.
The passenger is responsible for maintain the delivered system.
Some of import details of SLRA are confidential for outsiders (Passengers).
Payroll is not fully automated due to lack of information from the passenger.
Page 8

CS 2002
2.5 Project Documentation

The project described in this document is software for a Railway reservation system. This system
has 4 user levels, hence it provides privilege levels for this users and it makes this system a
secure one. The system allows users to use the system in an intuitive and efficient manner.
2.6 Assumptions and Dependencies
There are five classes of tickets as listed below:

o Sleeping - compartment style coaches - 4 passenger per compartment
o Sitting - typical first class coach
o Sitting - tourist class coach
o Sitting - typical second class coach
o Sitting typical third class coach
Reservation can be made up to one month before a particular trip.
Seats are assigned during reservation
Online reservation involves tickets being purchased within 24 hours after making the
reservation. Otherwise, the reservation will be cancelled.
No reservations can be made 48 hours prior to the trip.
Passenger lists will be provided for conductors at each stop.
The trains will be assumed to be of a constant size that accommodates 500 passengers at
a time.
The expected reservations during test period may amount to approximately 5000 per day.
This volume varies by hour, day, and season.
SLRA will provide us with information about identification process used in Sri Lanka, so
that it can be applied to the reservation system and scalping of tickets is avoided.
Network connection will always remain established.
SLRA trains occasionally may become non-operational. In that case, a new train will be
dispatched, but a delay of up to a few days could occur.
The SLRA will provide all the required hardware and software resources for the
development of the project.
Facilitators from SLRA to help make arrangements with government authorities, make
travel arrangements, and serve as a host.
Page 9

CS 2002
3. System Features
3.1 Functional requirements
Registration
Users only have limited access to the web site and able to process only basic features of the site.
So in order to gain more access to the web site a user must register with the site and become a
registered passenger by giving some basic information such as First Name, Last Name,
Username and Password, Email address, contact number.
Once the user fills the form and gets registered with the site the system will check the Username
with other existing registered-users usernames and if it is matched with another username then
the system will request the user to change the username that was entered. Otherwise registration
will be done successfully and the information will be send to the data base. If the user is not
willing to register with the site then he/she wont be able to make ticket reservations and to
access other advanced features of the site.
Login
A registered passenger can log into the system by entering the correct combination of username
and the password.
Once the registered passenger enters the username and password the system will check the
combination with the records in the database.
If it is matching with the existing record in the database then passenger can log into the system
successfully. Otherwise passenger will be warned with Incorrect username or password prompt
and system will allow them to re-enter the username and password.
Logout
Once the registered passenger finishes function after login into the system he/she must logout
from the system by clicking the "Log out" button in the interface. After login out of the system
successfully a message will be displayed "successfully logout from the system".
Page 10

CS 2002
3.2 Entity Relationship Diagram
Figure 1.4
Page 11

CS 2002
4. Exter nal Interface Requirements

4.1 External Interfaces

Train Delay Alert Service.

Booking Terminals.
Interactive voice Response System.
Touch Screen.
Passengers operated Enquiry Terminals
4.2 User Interfaces
Employee:
An employee can only view the login interface and after login to the system he can just
view the front page where it can enter some record, delete it, shift it to some other place
and logout after a certain time.
Passenger:
It doesnt have any direct link with the system. It just can browse the web browser for
online booking facility. There we had to record its information and then he/she will view
the configuration page having a message.
Administrator:
It can view various reports. i.e.

o
o
o
Total income a particular journey has made.

Total numbers of seats are reserved in a particular journey.
Number of trains arrival and depart per day.
System Actor:
This is a system actor that provides the whole schedule to the original system it just can
update the system according to its need, Online booking is also handled by it provides a
complete interface to passengers for online booking.
Page 12

CS 2002
The diagrams below demonstrate the major transition from one user interface to another.
The following diagram illustrates the major functionalities the railway reservation system
could provide. These functionalities will be displayed depending on the user. Selecting one
of these functions will take the user to a different user interface.
HOME
CANCEL
HELP
2012 SLRA TRAVEL SERVICES PRIVATE LIMITED
Figure 1.5
When Ticket Reservation is selected it will display the following web page. The title of this
page is consistent with the function selected, and since the Ticket Reservation was selected,
the title displays Ticket Reservation. The purpose of this is to allow the user know what part
of the system they are accessing. Furthermore, the user can select any of the four
functionalities.
LOG OUT
HELP
MAIN MENU
Figure 1.6
Page 13

CS 2002
Customers can make a reservation by looking at the availability of the trains, seats and what
city they want to travel to. When the user selects the Make Reservation function the
following interface will be displayed. The person can fill up the following information by
selecting the desired location from the drop down menu and the date and the time of travel or
return if he/she wishes.
The three buttons allow the user to navigate through the interfaces. The Display Available
function displays all the trains traveling from one city to another and the seats available on
that train.
LOG OUT
BACK
DISPLAY AVAILABLE
CLEAR
Figure 1.7
The Display Available illustrates the available trains, seats and the city they travel to.
However, before we get to the next page when clicking Display Available the interface
below demonstrates the Make Reservation function. The following is the list of available
seats for the trains the customer specified. The confirm button will forward the customer to
the payment page.
Page 14

CS 2002
LOG OUT
CONFIRM
BACK
Figure 1.8
The following interface allows the user to pay for the ticket as appropriate. This page is part
of the Passenger Account function, and it is used to make payment for the ticket reserved.
LOG OUT
MAIN MENU
SUBMIT
CLEAR
Figure 1.9
Finally, the submit button displays the appreciation page as shown below with a button to go
to the main menu.
Page 15

CS 2002
LOG OUT
SLRA TRAVEL SERVICES PRIVATE LIMITED
MAIN MENU
Figure 1.10
4.3 Hardware Interfaces

The major hardware component is the regular PC which communicates with the server. The
server then communicates with the database. The protocol involved between the PC's and the
server is the HTTP protocol, which allows communication between the PC's and the Server.
4.4 Software Interfaces

The database engine can be embedded on a platform using
An active mySQL server
A browser which acts as a client
An Apache HTTP server
The Apache server between the client and the database will handle all communication, and the
server will run on a Linux operating system. This will be provided and handled by the domain
name provider. For database handling a DBMS will be required. MySQL will be used for this
purpose. The online component consists of an Internet based calendar, where interaction occurs
through a web browser. The web interface should support at least Mozilla Firefox 2.0 and
greater, Internet Explorer 6.0 and greater, Google Chrome 4.0 and greater and Opera 9.0 and
greater.
4.5 Communications Interfaces

There is a LAN used for communication among the different client systems to be used.
Page 16

CS 2002
5. The Nonfunctional Requirements

5.1 Performance Requirements
All the view data functions should execute within one second.
All the update, delete and add functions should execute within one second.
At least 500 users should be able to login to the website at once.
5.2 Safety Requirements
System should be able to recover from crash.
5.3 Security Requirements
Each and every user has to log in to the system using a Username and a Password and
should thereby prove their identity.
An encryption method will be used when storing the passwords in the database and
therefore even if the database is hacked the passwords would be kept safe.
Only the super admin will have full access and privileges to the system.
The user information will never be sold to other parties and will be kept secure at all
times.
Users will be authenticated to ensure that no unauthorized users gain access to private
information.
5.4 Software Quality Attributes

Adaptability
The system is adapted to the current manual system that the company is using.
Availability
The system is available in 24 hours daily.
The Administrator can access all data in database at any time.
Other users can access to the data according to their privileges.
System needs 5-10 min of down time once a week for database backup purposes
Correctness

The correctness of the system should be at least 85% when taking the assumptions
and the constraints together
Page 17

CS 2002
Flexibility
Modifications can be done to the system according to the changing requirements due to
time factor.
Maintainability
System can be developed easily to because of its object oriented design
Can easily increase its functionality by adding classes
Any minor maintenance issue should be sorted out by less number of days.
Reliability
The system runs on at least 99% reliability.
If any system failures occur, crash recovers with back-ups.
Reusability
It helps to makes the software substantial savings in the development costs.
5.5 Business Rules

Illegal accesses and illegal data manipulation not allowed in this system and all the
manipulations are under supervision of the Administrator. The Administrator has the full access
to the any subsystem. The reports can be generated at any time due to business requirements.
Page 18

CS 2002
6 . A p p e n d ix
6.1 References
o SRS Sample
www.jsu.edu/mcis/docs/SRSSample.doc, Accessed on Aug. 05, 2012
http://www.scribd.com/doc/38642993/SRS-Documentation-for-Railway-ReservationSystem, Accessed on Oct. 07, 2012
o SRS Sample Manual Testing
www.gcreddy.net/2010/03/sample-srs-document.html, Accessed on Aug. 06, 2012
o Sumathi, S., Esakkirajan, S., 2007. Fundamentals of Relational Database
Management Systems. Berlin, Heidelberg, New York, USA: Springer
7. Group Members
Name
1)
2)
3)
4)
5)
C. Jayaweera
K. D. Ranasinghe
M. A. L. H. N. Munasinghe
J. K. H. M. Perera
T. K. R Nipuni
Index No.
10424
10392
10469
10477
10472
Page 19

Software Requirement Specification Software Engineering

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirement Specification Software Engineering

Uploaded by

Copyright:

Available Formats

Software Requirement

Software Requirement Specification

Railway Reservation System

Software Requirement Specification

Arrival and departure details

1.2 Intended Audience and Reading Suggestions

Developer team who develops this system.

Railway Reservation System

Software Requirement Specification

1.3 Project Scope

Railway Reservation System

Software Requirement Specification

Railway Reservation System

Software Requirement Specification

1.3.2 Acronyms and Abbreviations

Railway Reservation System

Software Requirement Specification

2.2 Product Functions

Railway Reservation System

Software Requirement Specification

2.3 User Classes and Characteristics

Railway Reservation System

Software Requirement Specification

2.4.1 Design and Implementation Constraints

Railway Reservation System

Software Requirement Specification

2.5 Project Documentation

2.6 Assumptions and Dependencies

There are five classes of tickets as listed below:

Railway Reservation System

Software Requirement Specification

Railway Reservation System

Software Requirement Specification

3.2 Entity Relationship Diagram

Railway Reservation System

Software Requirement Specification

4. Exter nal Interface Requirements

Train Delay Alert Service.

4.2 User Interfaces

It can view various reports. i.e.

Total income a particular journey has made.

Railway Reservation System

Software Requirement Specification

2012 SLRA TRAVEL SERVICES PRIVATE LIMITED

2012 SLRA TRAVEL SERVICES PRIVATE LIMITED

Railway Reservation System

Software Requirement Specification

2012 SLRA TRAVEL SERVICES PRIVATE LIMITED

Railway Reservation System

Software Requirement Specification

2012 SLRA TRAVEL SERVICES PRIVATE LIMITED

2012 SLRA TRAVEL SERVICES PRIVATE LIMITED

Railway Reservation System

Software Requirement Specification

SLRA TRAVEL SERVICES PRIVATE LIMITED

4.3 Hardware Interfaces

4.4 Software Interfaces

4.5 Communications Interfaces

Railway Reservation System

Software Requirement Specification

5. The Nonfunctional Requirements

5.2 Safety Requirements

System should be able to recover from crash.

5.3 Security Requirements