srs template

Software Requirements Specification

for

Railway Reservation System

Version 1.0 approved

Prepared by:

Syed Husnain Bukhari 061-bscs-08

Hassan Arif 115-bscs-08

Ahsan Bilal 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 SystemPage ii

Table of Contents

Table of Contents....................................................................................................................... iiRevision History......................................................................................................................... ii1. Introduction.......................................................................................................................... 1

1.1 Purpose......................................................................................................................................11.2 Document Conventions..............................................................................................................11.3 Intended Audience and Reading Suggestions..............................................................................11.4 Product Scope............................................................................................................................11.5 References..................................................................................................................................1

2. Overall Description.............................................................................................................. 22.1 Product Perspective....................................................................................................................22.2 Product Functions.......................................................................................................................22.3 User Classes and Characteristics.................................................................................................22.4 Operating Environment...............................................................................................................22.5 Design and Implementation Constraints......................................................................................32.6 User Documentation...................................................................................................................32.7 Assumptions and Dependencies..................................................................................................3

3. External Interface Requirements........................................................................................43.1 User Interfaces............................................................................................................................43.2 Hardware Interfaces....................................................................................................................43.3 Software Interfaces.....................................................................................................................53.4 Communications Interfaces.........................................................................................................5

4. System Features................................................................................................................... 54.1 System Feature 1........................................................................................................................54.2 System Feature 2 (and so on)......................................................................................................6

5. Other Nonfunctional Requirements....................................................................................65.1 Performance Requirements.........................................................................................................65.2 Safety Requirements...................................................................................................................65.3 Security Requirements................................................................................................................65.4 Software Quality Attributes........................................................................................................75.5 Business Rules...........................................................................................................................7

6. Other Requirements........................................................................................................... 18Appendix A: Glossary.............................................................................................................. 18Appendix B: Analysis Models.................................................................................................. 18Appendix C: To Be Determined List....................................................................................... 18

Revision History

Name Date Reason For Changes Version

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


2. Overall Description

2.1 Product Perspective

< _ State whether the product is independent and totallyself contained_ If the product is component of a larger system then:

– describe the functions of each component of thelarger system and identify interfaces– overview of the principal external interfaces of thisproduct– overview of HW and peripheral equipment to beused_ Give a block diagram showing the major componentsof 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:

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.

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





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.

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

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

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

Login

Logout

Change Password

All Users


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 his\her password with the system.

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

In Person Booking

Cancelling

Shifting SeatsEmployee

Insert Records


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

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




4.3.2 Update system

Admin can update the whole system whenever any type of new information is

available.

View Reports

Update System

Administrator


Passenger

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

In person booking

Canceling

Passenger

Shifting Seat

Online Booking

Ticket Issue

System ActorSchedule

Update Trains


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

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

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:

Login

All Users

Change Password

Logout


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


The user is logged in to the system.


The user is logout from the system.

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


User is logged in to the system.


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.


(E_1) User can click on the “Logout” option at any time.


Employee

System Actor

6.4 Use case #:004

6.4.1 Use case Name: In person booking

6.4.2 Actor: System Actor, Employee




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


(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

In Person Booking

Cancelling

Insert record


6.5 Use case #:005

6.5.1 Use case Name: Canceling



Employee is logged in to the system.


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


(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



Employee is logged in to the system.


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.

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.


(E_1) if user clicks on “No” option then system will return to the main page.


6.7 Use case #:007

6.7.1 Use case Name: Insert record





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


(E_1) If the new inserted record is incorrect then system will ask to en-enter the required

data.


View Reports

Update System

Administrator


6.8 Use case #:008

6.8.1 Use case Name: View reports

6.8.2 Actor: Administrator



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.




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


System is working with the old updates.


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

srs template

Documents