Functional Requirement Document

2020

Functional Requirement Document

Railway reservation system

Altaf

COEPD
Version Private & Confidential Page 1
 Functional Requirement Document

1. Document Version Control List

Version Date Author Description

01 02-05-2020 Altaf FRD Doc

2. Distribution List

Version Date Name Role Distribution

Purpose
01 03-05-2020 Ronald Senior BA Doc Owner
01 03-05-2020 Veer Project Manager Project Sponsor

Version Private & Confidential Page 2

 Functional Requirement Document

Contents
1. Document Version Control List...........................................................................................................1
2. Distribution List...................................................................................................................................1
3. Business Rules.....................................................................................................................................3
4. System Rules.......................................................................................................................................3
5. Control Flow........................................................................................................................................3
6. Purpose...............................................................................................................................................3
7. Project Background.............................................................................................................................3
8. Project Objective.................................................................................................................................3
9. Business Requirements.......................................................................................................................3
9.1. Stake Holder Requirements........................................................................................................4
10. Assumptions & Constraints.............................................................................................................4
11. Use Case Diagrams [UML]...............................................................................................................4
11.1. Actor Specific Use Case Diagrams...........................................................................................4
11.2. Use Case Specifications...........................................................................................................5
9. Activity Diagram......................................................................................................................................5
9.1. Process Specific Activity Diagrams..............................................................................................5
9.2. Activity Specification...................................................................................................................6
9.2.1. Basic Flow............................................................................................................................6
9.2.2. Alternative Flow..................................................................................................................6
9.2.3. Exception Flow....................................................................................................................6
10. Functional Requirements................................................................................................................6
11. Non Functional Requirements........................................................................................................6
12. Prototyping.....................................................................................................................................7
13. Master Tables..................................................................................................................................7
14. Notes...............................................................................................................................................7

Version Private & Confidential Page 3

 Functional Requirement Document

3. Business Rules
 Customer Can book E-Ticket sitting at home & take print of that & travel.
 Customer can book I-Ticket sitting at home & the ticket is couriered to his/her home.
 Cancellation of E-Ticket is also possible from sitting at home through online.
 Cancellation of I-Ticket is possible through visiting ticket counter & submitting the filled form
to clerk at counter.
 View train availability online.
 Checking ticket availability online.
 E-Ticket will not be couriered to the customer.
 I-Ticket printout is not allowed as a valid ticket for travel.

4. System Rules
 System should pop up for any error.
 Ticket cannot be booked between 11:30pm to 12:30am.
 System must daily backup the data by 12pm.
 System must allow customer to modify/delete personal details while booking ticket.
 System should pop up a message, if any issues in the system from railways side.
 System should not allow customer to take I-Ticket printout.
 System should not allow courier of E-Ticket to the customer
 System should confirm the payment & book ticket subsequently.

Version Private & Confidential Page 4

 Functional Requirement Document

5. Control Flow

6. Purpose
 To Avoid the queue at the ticket counter at stations by 50-80%.
 To increase customer base by 50%.
 To attract more customer towards buying tickets online.
 To create a user friendly & easy to use application.
 This document specifies the functionality of the system performance ie. It describes what
the system has to do.
 As per Business requirements this document also tells what should be the functionality of
the web portal

7. Project Background
 There is huge queue for ticket booking at counter.
 We have to increase more no. of counter to handle those queue.
 Current issues were there so generator cost also keep on adding up.
 Lots of paper & documents were in use.
 Sometimes people start quarrelling standing in queue for longer time period.

To address the above issues, we needed an application to overcome them.

Version Private & Confidential Page 5

 Functional Requirement Document

8. Project Objective
 To create a user friendly & easy to use application.
 Proving customer with E-Ticket & I-Ticket options
 To provide customer with a user friendly application.
 Customer Can book train ticket sitting at home.
 Customer Can cancel train ticket sitting at home.
 Customer can view trains available in between their source & destination station.
 Customer can check tickets available in the train.
 Customer can make payment easily for the tickets that are bought.
 Customer can get the refund of the cancelled tickets.
 Customer can take printout of E-tickets
 Customer can get the physical I-ticket couriered to their address which are being bought.

9. Business Requirements
A web based system to be developed for following :-

Sl. Requirement ID Requirement Name Description Priority

No.

1 BR001 Web portal Interface used to support the Railway Reservation High
system process.
2 BR002 Login Credential Create login credential for clerk High
3 BR003 View train details Customer should be able to view train details between High
source & destination stations.
4 BR004 Check ticket availability Customer should be able to check ticket availability High
details
5 BR005 Book ticket Customer should be able to book train ticket with either High
E-Ticket or I-Ticket options.
6 BR006 Make Payment Customer should be able to make payment online for the High
train ticket booking wither via card or cheque.
7 BR007 Cancel Ticket Customer should be able to cancel either E-Ticket or I- High
Ticket.
8 BR008 Refund for cancellation Refund of the cancelled ticket should be transferred to High
customers bank account.
9 BR009 Update system on ever After every booking or cancellation system should get High
booking / cancellation updated automatically.

Version Private & Confidential Page 6

 Functional Requirement Document

9.1. Stake Holder Requirements

Stakeholder Requirements
Customer 1. Login isn’t compulsory
2. view trains available in between their source & destination
station.
3. Check tickets available in the train.
4. Make payment easily for the tickets that are bought.
5. Get the refund of the cancelled tickets.
6. Take printout of E-tickets
7. Get the physical I-ticket couriered to their address after
buying.
Clerk 1. Personal login,
2. Should be able to cancel ticket

10. Assumptions & Constraints

Assumptions
 No additional change request.
 Proper funding is provided.
 There is internet connectivity present.
 Cancellation form will be available at station.
 Vendor for courier service is available for couriering the ticket.

Constraints
 Login will be provided to the clerk
 Register & login is optional for customer.
 System should update on every ticket booking or cancel.
 The whole System should update on every day basis where no one can access it
(mostly in night).
 Clerk should be able to cancel the ticket.
 Cancelled ticket amount should get refunded to customer account directly.

11. Use Case Diagrams [UML]

11.1. Actor Specific Use Case Diagrams

Version Private & Confidential Page 7

 Functional Requirement Document

Version Private & Confidential Page 8

 Functional Requirement Document

11.2. Use Case Specifications

Use Case ID RRS_CS6_UC1

Use Case Name Search Train
Brief Description In this Use Case Customer can access Railway Reservation System to search train
& check train availability.
Actors Customer
Pre Condition - Customer should have access to Railway Reservation System.
- Train details & Its availability details have been updated by system.
- Active internet connection should be available.
Basic Flow Step 1. The Use case begins when customer opens the RR system.
Step 2. Then customer can click on “search” button to search for train.
Step 3. Then customer can click on “Train availability” button to check availability
of train
Step 4. The use case ends successfully.
Alternative Flow A. If in Step 1 of the basic flow, customer is not able to open the RR system then
system shows an error as “system error, kindly restart” then use case resumes at
step 1.
B. If in Step 2 of the basic flow, customer won’t be able to search train then
system shows an error as “Try Again” then use case resumes at step 2.
C. If in Step 3 of the basic flow, customer won’t be able to check Train availability
then system shows an error as “Try Again” then use case resumes at Step 3.
Exceptional Flow Valid error condition is displayed if there is any error in accessing the information.
Post Condition - Successful Completion :
- Customer should be able to search trains.
- Admin should be able to check Train availability.
Scenarios No Response from the server.

Use Case ID RRS_CS6_UC2

Use Case Name Book Ticket
Brief Description In this Use Case Customer can book train ticket either by I-Ticket or E-Ticket.
Actors Customer
Pre Condition - Customer should have access to Railway Reservation System.
- Customer should have checked Train details & Its availability in system.
- Active internet connection should be available.
Basic Flow Step 1. The Use case begins when customer click on “Book Ticket” button to Book
the Train Ticket.
Step 2. Then customer can click on “E-Ticket” button to book ticket via E-
Ticketing.
Step 3. Or Customer can click on “I-Ticket” button to book ticket via I-Ticketing.
Step 4. Then customer can click on “payment” button to make payment for the
ticket

Version Private & Confidential Page 9

 Functional Requirement Document

Step 5. Then system confirms the booking & issue E-Ticket or I-Ticket.
Step 6. Customer can click on “Print E-Ticket” button to take print for issued E-
Ticket.
Step 7. Then customer gets E-Ticket Printed.
Step 8. Or Customer can click on “Courier I-Ticket” Button to get Issued I-Ticket
couriered.
Step 9. Customer can get I-Ticket couriered.
Step 10. The use case ends successfully.
Alternative Flow A. If in Step 1 of the basic flow, customer won’t be able to book ticket then
system shows an error as “Try Again” then use case resumes at step 1.
B. If in Step 2 of the basic flow, customer won’t be able to Book E-Ticket then
system shows an error as “Try Again” then use case resumes at step 2.
C. If in Step 3 of the basic flow, customer won’t be able to Book I-Ticket then
system shows an error as “Try Again” then use case resumes at Step 3.
D. If in Step 4 of the basic flow, customer won’t be able to make payment then
system shows an error as “Try Again” then use case resumes at step 4.
E. If in Step 6 of the basic flow, customer won’t be able to Print E-Ticket then
system shows an error as “Try Again” then use case resumes at Step 3.
F. If in Step 8 of the basic flow, customer won’t be able to courier I-Ticket then
system shows an error as “Try Again” then use case resumes at Step 8.
Exceptional Flow Valid error condition is displayed if there is any error in accessing the information.
Post Condition - Successful Completion :
- Customer should be able Book E-ticket & take confirmed E-Ticket Print.
- Customer should be able Book I-ticket & get confirmed I-Ticket couriered.
Scenarios No Response from the server.

Use Case ID RRS_CS6_UC3

Use Case Name Cancel Ticket
Brief Description In this Use Case Customer can cancel E-Ticket or I-Ticket for confirmed tickets.
Actors Customer
Pre Condition - Customer should have access to Railway Reservation System.
- Customer should have booked tickets online.
- Active internet connection should be available.
Basic Flow Step 1. The Use case begins when customer click on “Cancel ticket” button.
Step 2. Then customer can click on “E-ticket” button to cancel booked E-ticket.
Step 3. Then E-ticket gets cancelled & refund is transferred to account.
Step 4. Then customer can click on “I-ticket” button to request cancel of booked I-
ticket.
Step 5. Then system pop up a message that “customer have to Fill cancellation
form & submit to Clerk at reservation Office along with I-Ticket received via
courier for Cancellation”.
Step 6. The use case ends successfully.
Alternative Flow A. If in Step 1 of the basic flow, customer won’t be able to cancel ticket then
system shows an error as “Try Again” then use case resumes at step 1.
B. If in Step 2 of the basic flow, customer won’t be able to cancel E-Ticket then

Version Private & Confidential Page 10

 Functional Requirement Document

system shows an error as “Try Again” then use case resumes at step 2.
C. If in Step 4 of the basic flow, customer won’t be able to cancel I-Ticket then
system shows an error as “Try Again” then use case resumes at Step 4.
Exceptional Flow Valid error condition is displayed if there is any error in accessing the information.
Post Condition - Successful Completion :
- Customer should be able cancel E-ticket & get Refund transferred to
account.
- Customer should be able request for I-ticket cancellation.
Scenarios No Response from the server.

Use Case ID RRS_CS6_UC4

Use Case Name Cancel I-Ticket
Brief Description In this Use Case Clerk can cancel I-Ticket for confirmed ticket of customer.
Actors Clerk
Pre Condition - Clerk should have access to Railway Reservation System.
- Customer should have Filled the cancellation form & submit to Clerk at
reservation Office along with I-Ticket received via courier
- Active internet connection should be available.
Basic Flow Step 1. The Use case begins when clerk open RR system.
Step 2. Then clerk click on “Cancel I-ticket” button to cancel booked I-ticket.
Step 3. Then I-ticket gets cancelled & refund is transferred to account.
Step 4. The use case ends successfully.
Alternative Flow A. If in Step 1 of the basic flow, clerk is not able to open the RR system then
system shows an error as “system error, kindly restart” then use case resumes at
step 1.
B. If in Step 2 of the basic flow, clerk is not able to click the cancel I-ticket button
then he needs to check with IT dept. to rectify the error & then use case resumes
at step 2.
Exceptional Flow Valid error condition is displayed if there is any error in accessing the information.
Post Condition - Successful Completion :
- Clerk should be able cancel I-ticket & get Refund transferred to
customer’s account.
- Customer should be able get his/her I-ticket cancelled.
Scenarios No Response from the server.

Version Private & Confidential Page 11

 Functional Requirement Document

12. Activity Diagram

12.1. Process Specific Activity Diagrams

Version Private & Confidential Page 12

 Functional Requirement Document

12.2. Activity Specification

Version Private & Confidential Page 13

 Functional Requirement Document
12.1.1 Basic Flow
12.1.2 Alternative Flow
12.1.3 Exception Flow
Version Private & Confidential
Process Steps :
Step 1: Flow starts when system ask visitor to
enter train details
Step 2: Accept train details from visitor
Step 3: Check ticket availability
Step 4: Ticket is available
Step 5: Ask visitor to enter booking details
Step 6: Accept booking details from visitor
Step 7: Book Ticket via E-ticket
Step 8: Make payment for ticket
Step 9: Payment Successful
Step 10: Booking Confirmed
Step 11: Print ticket
Step 12: Ask visitor whether to cancel ticket or
not
Step 11: No cancellation, Flow Ends.
Process Steps :
Step 1: Ask visitor to enter train details
Step 2: Accept train details from visitor
Step 3: Check ticket availability
Step 4: Ticket is available
Step 5: Ask visitor to enter booking details
Step 6: Accept booking details from visitor
Step 7: Book Ticket via I-ticket
Step 8: Make payment for ticket
Step 9: Payment Successful
Step 10: Booking Confirmed
Step 11: Ticket couriered to visitor’s address
Step 12: Ask visitor whether to cancel ticket or
not
Step 11: No cancellation, Flow Ends.
Process Steps :
Step 1: Ask visitor to enter train details
Step 2: Accept train details from visitor
Step 3: Check train details whether correct or not
Step 4: Wrong train details entered
Step 5: Ask visitor to enter correct train details &
then use case resumes at step 1.
Step 6: Check ticket availability
Step 7: Tickets not available
Step 8: Ask visitor to try another train or date
then use case resumes at step 1.
Step 9: Ticket is available
Step 10: Ask visitor to enter booking details
Step 11: Accept booking details from visitor
Step 12: Book Ticket via E-ticket
Step 13: Make payment for ticket
Step 14: Payment Successful
Page 14
 Functional Requirement Document

Step 15: Booking Confirmed

Step 16: Print ticket
Step 17: Ask visitor whether to cancel ticket or
not
Step 18: Visitor wants to cancel the ticket.
Step 19: cancel E-Ticket
Step 20: Refund transferred to account, Flow
Ends.

13 Functional Requirements

S.No. Req ID Req Name Description Priority

1 RQ 1 Login Validation System should validate the login credentials of Should
clerk
2 RQ 2 View Train Details System should allow visitor to view train details Should
between source & destination stations.
3 RQ 3 Check Ticket System should allow visitor check ticket Should
Availability availability details
4 RQ 4 Book Ticket System should allow visitor to book train ticket Should
with either E-Ticket or I-Ticket options..
5 RQ 5 Make Payment System should allow visitor to make payment Must
online for the train ticket booking wither via
card or cheque
6 RQ 6 Cancel Ticket System could allow visitor to cancel ticket Could
7 RQ 7 Refund for cancellation System must transfer the refund amount to Must
customers bank account upon cancellation
8 RQ 8 Update system on ever System must update automatically after each Must
booking / cancellation booking / cancellation
9 RQ 9 Visitor Login / Register System would allow visitor to Login / Register Would

14 Non Functional Requirements

S.NO Req ID Description
1 NFR 1 System response time should be maximum 1sec
2. NFR 2 All data should have a regular backup.
3. NFR 3 System must be connected to internet 24/7
4. NFR 4 Interface- should be user friendly
5. NFR 5 Security- Pop up to change password after every 30 days.

Version Private & Confidential Page 15

 Functional Requirement Document

15 Prototyping

1. LogIn Page

Version Private & Confidential Page 16

 Functional Requirement Document

2. Visitor LogIn Page

Version Private & Confidential Page 17

 Functional Requirement Document

3. Visitor Search Page

Version Private & Confidential Page 18

 Functional Requirement Document

4. Booking Page

Version Private & Confidential Page 19

 Functional Requirement Document

5. E-Ticket

Version Private & Confidential Page 20

 Functional Requirement Document

6. I-Ticket

Version Private & Confidential Page 21

 Functional Requirement Document

7. Clerk LogIn

Version Private & Confidential Page 22

 Functional Requirement Document

8. Clerk

16 Master Tables
 Govt – Government
 & – And
 ie. – That Is
 UC – Use Case
 RRS – Railway Reservation System

17 Notes

Version Private & Confidential Page 23