2. Software Requirements Specification for Railway Reservation System
Page ii
Table of Contents
1. Introduction................................................................................................................................1
2. Overall Description....................................................................................................................2
3. External Interface Requirements............................................................................................. 4
4. System Features......................................................................................................................... 5
5. Other Nonfunctional Requirements.........................................................................................6
6. Other Requirements................................................................................................................ 18
Revision History
Name Date Reason For Changes Version
3. Software Requirements Specification for Railway Reservation System
Page 1
1. Introduction
1.1 Purpose
This document provides a description of the interfaces, key concept, and overall
purpose of the software project “Railway Reservation System”. This document intends
to comprehend and clarify the requirements, also serving as the basis of further
design.
1.2 Document Conventions
This document follows the standards of IEEE.
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
This project automates the task of the reservation system for a railway station.
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.>
4. Software Requirements Specification for Railway Reservation System
Page 2
2. Overall Description
2.1 Product Perspective
< _ State whether the product is independent and totally
self contained
_ If the product is component of a larger system then:
– describe the functions of each component of the
larger system and identify interfaces
– overview of the principal external interfaces of this
product
– overview of HW and peripheral equipment to be
used
_ Give a block diagram showing the major components
of the product, interconnections, and external
interfaces.. <Put a DFD level 0 diagram here >>
2.2 Product Functions
Not Applicable at this time.
2.3 User Classes and Characteristics
Following are some users of this system.
1. Passenger
2. Employee
3. Administrator
4. System user
Passenger:
A person who will come to a booth to purchase a ticket and to inquire something.
He can book, cancel and transfer his/her seat according to his/her requirement.
Employee:
An employee is a person who is in service and who directly interacts with the
system. He can store info of the passengers, can issue tickets, cancel and transfer the
seat of a passenger according to his/her need, so we can say that user can insert into
the system also.
Administrator:
5. Software Requirements Specification for Railway Reservation System
Page 3
It is a person responsible for all admin tasks but in this project he can view the
reports of the whole day in which the following information is provided to it.
• 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:
It is responsible to maintain the scheduling of trains which are updated by the
scheduling department. It also handles the online booking system and issuing of the
tickets.
2.4 Operating Environment
The system automates the booking, canceling and transferring of seats.
2.5 Design and Implementation Constraints
Not Applicable at this time.
2.6 User Documentation
This process is as below:
1. The booths are set up on the Railway stations.
2. The passengers come to those booths if they want to get some information about
the schedule or if they ought to buy ticket of some train.
3. Booking can be done online also.
4. If he/she wants to get any information, the employee will consult the schedule and
tell the passenger its required information.
5. If he wants to buy a ticket the employee will ask the passenger its name and the
route he/she wants to travel the employee manages a record of it and takes a
particular amount then issues a ticket to it with a specific number and a seat
number.
6. If the user wants to cancel its seat the same process is repeated again and he/she
gets its money back.
6. Software Requirements Specification for Railway Reservation System
Page 4
7. If the passenger wants to shift/change its package then the employee transfers its
record to that other list.
8. The record of every thing is managed in parallel so the administrator can view the
whole report of the day after the end of a day.
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. External Interface Requirements
3.1 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 doesn’t 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
• 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:
7. Software Requirements Specification for Railway Reservation System
Page 5
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.
3.2 Hardware Interfaces
<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware, and
communication protocols to be used.>
3.3 Software Interfaces
<Describe the connections between this product and other specific software components (name
and version), including databases, operating systems, tools, libraries, and integrated commercial
components. Identify the data items or messages coming into the system and going out and
describe the purpose of each. Describe the services needed and the nature of communications.
Refer to documents that describe detailed application programming interface protocols. Identify
data that will be shared across software components. If the data sharing mechanism must be
implemented in a specific way (for example, use of a global data area in a multitasking operating
system), specify this as an implementation constraint.>
3.4 Communications Interfaces
<Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols, electronic
forms, and so on. Define any pertinent message formatting. Identify any communication
standards that will be used, such as FTP or HTTP. Specify any communication security or
encryption issues, data transfer rates, and synchronization mechanisms.>
4. System Features
<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of
these, whatever makes the most logical sense for your product.>
4.1 System Feature 1
<Don’t really say “System Feature 1.” State the feature name in just a few words.>
4.1.1 Description and Priority
<Provide a short description of the feature and indicate whether it is of High,
Medium, or Low priority. You could also include specific priority component ratings,
such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of
1 to a high of 9).>
4.1.2 Stimulus/Response Sequences
8. Software Requirements Specification for Railway Reservation System
Page 6
<List the sequences of user actions and system responses that stimulate the
behavior defined for this feature. These will correspond to the dialog elements
associated with use cases.>
4.1.3 Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These
are the software capabilities that must be present in order for the user to carry out
the services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and
necessary. Use “TBD” as a placeholder to indicate when necessary information is
not yet available.>
<Each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind.>
REQ-1:
REQ-2:
4.2 System Feature 2 (and so on)
5. Other Nonfunctional Requirements
5.1 Performance Requirements
<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. You may need to state performance requirements for individual functional
requirements or features.>
5.2 Safety Requirements
<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well
as actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied.>
5.3 Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect
the product. Define any security or privacy certifications that must be satisfied.>
9. Software Requirements Specification for Railway Reservation System
Page 7
5.4 Software Quality Attributes
<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.>
5.5 Business Rules
<List any operating principles about the product, such as which individuals or roles can perform
which functions under specific circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements to enforce the rules.>
5.6 4 Use case overview
4.1 All Users
4.1.1 Login
Every user can login to the system.
4.1.2 Logout
All users can logout from the system.
4.1.3 Change Password
Every user can change hisher password with the system.
Login
Logout
Change
Password
All
Users
10. Software Requirements Specification for Railway Reservation System
Page 8
4.2 Employee
4.2.1 In person Booking
An employee on the booth can make manual booking in the following steps.
• Get the all required information about the passenger.
• Get the required amount of money of the specific journey.
• Register the passenger.
• Booth officer issues the required ticket to the passenger.
4.2.2 Canceling
To cancel a reserve seat the employee has to follow the following steps.
• Get the issued ticket from the passenger.
• Match the information from ticket.
• Cancel the ticket.
• Give passenger his money back.
4.2.3 Changing package
In Person
Booking
Cancellin
g
Shifting
Seats
Employee
Insert
Records
11. Software Requirements Specification for Railway Reservation System
Page 9
Employee can change passenger’s package from one specific train to another on
the passenger’s demand.
4.2.4 Insert Record
Employee can add/modify new records of the passenger on the system.
Administrator
4.3.1 View Reports
Admin can see the following reports
• 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.
4.3.2 Update system
Admin can update the whole system whenever any type of new information is
available.
Passenger
View
Reports
Update
System
Administrator
In person
booking
Canceling
Passenger
12. Software Requirements Specification for Railway Reservation System
Page 10
4.4.1 In person Booking
Passenger can order to reserve his/her seat for a particular train journey.
4.4.2 Canceling
Passenger can order to cancel his/her ticket for a particular train journey.
4.4.3 Shifting Seat
Passenger can shift his/her reserved seat from one train to another.
4.5 System Actor
4.5.1 Online Booking
System actor can make an online booking of the seats for the passengers.
4.5.2 Issue Ticket
System actor can automatically generate a ticket for the passengers after
confirming all the available information of the passenger.
4.5.3 Schedule
Shifting
Seat
Online
Booking
Ticket
Issue
System Actor
Schedule
Update
Trains
13. Software Requirements Specification for Railway Reservation System
Page 11
System actor can automatically handle and use all the scheduling information
which came from the schedule department.
4.5.4 Update Trains
System actor also update it self whenever new information about trains and
scheduling of train is available.
5 Future Enhancements
5.1 Booking could be done by landline also.
5.2 The payment can be accepted by credit cards also.
5.3 The system can be made a part of the network.
5.4 The salary system of employees can made automatic.
5.5 Report with more information and more efficient could be generated from the system.
5.7 6. Use cases Description
Login
All
Users Change
Password
Logout
14. Software Requirements Specification for Railway Reservation System
Page 12
6.1 Use case # 001
6.1.1 Use case name: Login
6.1.2 Pre conditions:
The user accessed to the system login page.
6.1.3 Post conditions:
System displays a login page.
6.1.4 Basic Flow:
• The user enters his username.
• The user enters his password.
• The user clicks on the “login” button.
• System checks whether the username and password is correct. (E_1)
• The system displays the main page for user to process further.
6.1.5 Alternate Flow:
E_1: If the username and password is wrong system asks user to re-enter it.
6.2 Use case #:002
6.2.1 Use case Name: Logout
6.2.2 Actor: All Users
6.2.3 Pre conditions:
The user is logged in to the system.
6.2.4 Post conditions:
The user is logout from the system.
15. Software Requirements Specification for Railway Reservation System
Page 13
6.2.5 Basic Flow:
• The user clicks on logout option.
• System ends the user session.
6.3 Use case #:003
6.3.1 Use case Name: Change Password
6.3.2 Actor: All Users
6.3.3 Pre conditions:
User is logged in to the system.
6.3.4 Post conditions:
Password of the user is changed and main page is displayed.
6.3.5 Basic Flow:
• The user clicks in the change password option.
• The system shows the change password GUI.
• The user enters his new password.
• The user enters the confirm password.
• User clicks on change button.
• System checks whether the new password and confirm password match to each
other.(E_1)
• The system displays the “change Password” message.
6.3.6 Alternate Flow:
(E_1) User can click on the “Logout” option at any time.
In Person
Booking
Cancellin
g
16. Software Requirements Specification for Railway Reservation System
Page 14
Employee
System Actor
6.4 Use case #:004
6.4.1 Use case Name: In person booking
6.4.2 Actor: System Actor, Employee
6.4.3 Pre conditions:
The user is logged in to the system.
6.4.4 Post conditions:
System will display a message that “Seat has been reserved”.
6.4.5 Basic flow
• Employee enters all the relevant details of passenger.
• Employee collects the specific number of amount from passenger.
• Employee enters the amount which is collected.(E_1)
• Employee clicks on “Register/book” button. (E_2)
• The system will generate a ticket with a specific number of train seats for the
passenger.
• System will show a message that “Seat has been booked”.
6.4.6 Alternate Flow:
(E_1) If the amount enters is less than the registered amount for a particular travel then
system will asks to re-enter it.
(E_2) If any of the required information about the passenger is missing the system will
asks the passenger to re-enter it correctly.
(E_3) Employee can cancel the under process booking at any time.
Shifting
Seats
Insert
record
17. Software Requirements Specification for Railway Reservation System
Page 15
6.5 Use case #:005
6.5.1 Use case Name: Canceling
6.5.2 Actor: System Actor, Employee
6.5.3 Pre conditions:
Employee is logged in to the system.
6.5.4 Post conditions:
System will show a message that “Seat has been cancelled”.
6.5.5 Basic flow
• The user will find the saved record.
• User clicks on the “Cancel” option.
• System will again confirm the user whether to cancel it or not. (E_1)
• System will show the message that “Seat has been cancelled”.
6.5.6 Alternate Flow:
(E_1) if user clicks on “No” option then system will return to the main page.
(E_2) Users can logout to the system at any time.
6.6 Use case #:006
6.6.1 Use case Name: Shifting Seat
6.6.2 Actor: System Actor, Employee
6.6.3 Pre conditions:
Employee is logged in to the system.
6.6.4 Post conditions:
System will show a message that “Seat has been shifted”.
6.6.5 Basic flow
• The user will find the saved record.
• User clicks on the “Cancel” option.
18. Software Requirements Specification for Railway Reservation System
Page 16
• System will again confirm the user whether to cancel it or not. (E_1)
• Employee will registered the user in the other specific train as ordered by the
passenger.
• System will show the message that “Seat has been Shifted”.
• System will generate new Ticket for the passenger.
6.6.6 Alternate Flow:
(E_1) if user clicks on “No” option then system will return to the main page.
(E_2) Users can logout to the system at any time.
6.7 Use case #:007
6.7.1 Use case Name: Insert record
6.7.2 Actor: System Actor, Employee
6.7.3 Pre conditions:
The user is logged in to the system.
6.7.4 Post conditions:
System will display a message that “record has been entered”.
6.7.5 Basic Flow:
• Employee will find the specific record.
• Employee will update the existing record of the passengers.
• Employee will click on the “Update” button.
• System will check whether the inserted record is correct or not. (E_1)
• System will show a message that “New Record has been updated”.
6.7.6 Alternate Flow:
(E_1) If the new inserted record is incorrect then system will ask to en-enter the required
data.
19. Software Requirements Specification for Railway Reservation System
Page 17
(E_2) Users can logout to the system at any time.
6.8 Use case #:008
6.8.1 Use case Name: View reports
6.8.2 Actor: Administrator
6.8.3 Pre conditions:
The user is logged in to the system.
6.8.4 Post Conditions:
The page will display all the required Report.
6.8.5 Basic Flow:
The user can view the following reports.
• 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.
After seeing them he/she can make decisions.
6.9 Use case #:009
6.9.1 Use case Name: Update system
6.9.2 Actor : Administrator
View
Reports
Update
System
Administrator
20. Software Requirements Specification for Railway Reservation System
Page 18
6.9.3 Pre conditions:
System is working with the old updates.
6.9.4 Post conditions:
System will show a message that “system is updated”.
6.9.5 Basic flow:
• System will receive new update from schedule department.
• System will show a message that new updates are received.
• System will ask the administrator whether to update the system or not. (E_1)
• System will show a message that “System is updated”.
6.9.6 Alternate flow:
E_1 if user presses “NO” then system will insist the user to accept the new changes.
6. 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.>
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.>
