Software Requirements Specification

for

Railway Reservation System

Version 1.0 approved

Prepared by: Syed Husnain Bukhari Hassan Arif Ahsan Bilal 061-bscs-08 115-bscs-08 105-bscs-08

Pakistan Railway
November4, 2009

Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

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

Software Requirements Specification for Railway Reservation System Page 1

1.
1.1

Introduction
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.>

Software Requirements Specification for Railway Reservation System Page 2

2.
2.1

Overall Description
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:

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.

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.
3.1

External Interface Requirements

User Interfaces
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 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.

Employee:

System Actor:

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
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).>

<Dont really say System Feature 1. State the feature name in just a few words.>

4.1.2

Stimulus/Response Sequences

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.
5.1

Other Nonfunctional Requirements

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 products 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.>

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.1

Use case overview

All Users
Login

Logout

All Users

4.1.1 Login 4.1.2 Logout

Change Password

Every user can login to the system. All users can logout from the system.

4.1.3 Change Password

Every user can change his\her password with the system.

Software Requirements Specification for Railway Reservation System Page 8

4.2

Employee
In Person Booking

Cancellin g

Employee

Shifting Seats

4.2.1 In person Booking

An employee on the booth can makeInsert manual booking in the following steps. Records 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

Software Requirements Specification for Railway Reservation System Page 9

Employee can change passengers package from one specific train to another on the passengers demand.

4.2.4 Insert Record

Employee can add/modify new records of the passenger on the system.

Administrator
View Reports

Update 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

In person booking

Canceling Passenger

Software Requirements Specification for Railway Reservation System Page 10

Shifting Seat

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
Online Booking

Ticket Issue System Actor Schedule

4.5.1 Online Booking 4.5.2 Issue Ticket

Update System actor can make an online bookingTrains of the seats for the passengers. System actor can automatically generate a ticket for the passengers after

confirming all the available information of the passenger.

4.5.3 Schedule

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.

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

Logout

All Users

Change Password

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 All Users 6.2.1 Use case Name: Logout 6.2.2 Actor: 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.

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 All Users

6.3.1 Use case Name: Change Password 6.3.2 Actor: 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

Software Requirements Specification for Railway Reservation System Page 14

Shifting Seats Employee System Actor Insert record

6.4

Use case #:004

6.4.1 Use case Name: In person booking 6.4.2 Actor: 6.4.3 Pre conditions:
The user is logged in to the system.

System Actor, Employee

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.

Software Requirements Specification for Railway Reservation System Page 15

6.5

Use case #:005 System Actor, Employee

6.5.1 Use case Name: Canceling 6.5.2 Actor: 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 System Actor, Employee

6.6.1 Use case Name: Shifting Seat 6.6.2 Actor: 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.

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 System Actor, Employee

6.7.1 Use case Name: Insert record 6.7.2 Actor: 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.

Software Requirements Specification for Railway Reservation System Page 17

(E_2) Users can logout to the system at any time.

View Reports

Update System Administrator

6.8

Use case #:008 Administrator

6.8.1 Use case Name: View reports 6.8.2 Actor: 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 Administrator

6.9.1 Use case Name: Update system 6.9.2 Actor :

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.>