TOur management SYSTEM

Functional Requirement Document

 1. Document Version Control List

Version Date Author Description

01 Murthy FRD Doc

2. Distribution List

Version Date Name Role Distribution

Purpose
01 Murthy Senior BA Doc Owner
01 Project Manager Project Sponsor
01 Dev lead Coding
01 Testing lead Testing

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

Page 2
3. Business Rules
[List some of the business rules]
1. The payment through cash for the desired tour package should be done only to the company
staff and to not any third-party executives or vendors.
2. Only if the tickets are available for the desired tour scheme, the availability shall be displayed.

4. System Rules
[System rules related to task to do with the system on daily basis or in schedule times]

1. The system shall allow the admin to add a tour scheme only at morning 7 a.m. or night 7
p.m.
2. The system shall automatically check the availability of a tour scheme after every 2
hours between 6 a.m. to night 12 p.m.
3. It should alert staff to check for any confirmed tour schemes by customer at 4 p.m.,
every day.

5. Control Flow
[Insert any Hierarchical Diagrams]

6. Purpose
[Describe the purpose of this document]

The purpose of this document is to provide an overview on the background of the project and
the business requirements along with it. And to also describe the functionalities of the modules
present in the product/project to the technical/development team.

1. Check availability of tour module: Under this the customer is allowed to search for his
desired tour package and check its availability
2. Registration module: once the customer has chosen his desired package, he is asked to
register himself/herself by entering his personal and tour details. After this

7. Project Background
[Provide a brief history of how the project came to be proposed and initiated, including
the business issues/problems identified, and expected benefit of implementing the
project/developing the product.]

The client’s current tour management system consists much of manual labor than an automated
online system. A potential customer has to visit the business’s office to check for his desired tour
package and upon its availability he needs to submit a hardcopy containing the details required
to make the booking. And the payment is accepted only through cash. If there are any changes
that the customer would like to make then he/she need to visit the office once again and make
the desired changes, which is time consuming. To reserve the tickets and to book an
accommodation at the destination, the business had to have personnel in that respective
location or had one of the personal from the office to travel to make the bookings. Once the
tickets have been reserved the tickets are posted to the customer’s address which is time

Page 3
 consuming as well. For an addition or modification of a tour package the business personnel
have to make changes to the hardcopy every single time, which is kind of tedious and not
effective.

By the proposed business change, the customer shall be able to do all of the above activities
through his system back at home or through an app, due to which the client’s customer range
shall increase. The admin shall be able to just delete or add any tour schemes to the system
database which shall be available for the customer to view and moreover, the staff can book the
tickets and accommodation through the system available in the office. Thereby reducing the
time taken by each of the users to perform their activities and also reduces the cashflow spent
by each of them.

8. Project Objective
[These should describe the overall goal in developing the product, high level descriptions
of what the product will do, how they are aligned to business objectives, and the
requirements for interaction with other systems.]

The goal of this project is to convert the client’s manual tour management system into an online
tour management system which is more efficient and less time consuming; thereby increasing the
customer count and making profit for the client. The product shall allow the customer to book his
desired tour scheme and also manage his profile; to allow the staff to reserve the tickets based
on the customer’s details and, admin to add/delete/modify new or existing tour schemes into the
tour information system database.

There shall be network connection between the customer’s system, admin’s system and the
database located at the client’s place, as the customer profile along with the details of his desired
tour package are stored in the Tour information system database of the system and so is the
maintenance of the tour schemes, respectively.

9. Business Requirements
[Include all business requirements related to project to as listed below (or) module specific
requirements]

9.1. Stake Holder Requirements

Stakeholder Requirements
Actor 1 1.Personal Login
2. Other functionality
Actor 2 1. Personal login,
2. Functionality Requirement 1
Actor 3 Personal Login

Page 4
 Functionality Requirement 2

10.Assumptions& Constraints
# List All Assumptions& Constraints Functional requirements are based on
1. The availability of the tour package should only be displayed if there are availability of tickets.
2. The customer needs to confirm before 48 hours as the availability may vary depending on the
availability of tickets.
3. The staff needs to reserve tickets within 12 hours of the confirmation by the customer on the
tour package.
4. Admin needs to delete or modify the tour schemes within 2 hours from the time of removal
or modification.
5. Customer is unable to check the availability of the tour scheme due to network failure
between the user’s system and the database.
6. Username and password is not generated.

7. Use Case Diagrams [UML]

a. Actor Specific Use Case Diagrams

[Insert all Actor Specific Use Case diagrams for all the actors in the system]

Page 5
Use Case Diagram

Page 6
 b. Use Case Specifications
[Use Case Specifications for each Use Case diagrams mentioned above]

1. Check for availability of tour package:

1.1. Use case Name: Check for availability of tour package
1.2. Use case Description: The above Use case describes the activity flow of the new
customer checking for availability of the tour package.
1.3. Actors:
1.3.1. Primary actor: New customer
1.3.2. Secondary actor: Tour information system database
1.4. Pre-conditions:
1.4.1. There is a server connection between the system and the tour information system.
1.5. Basic Flow:
1.5.1. The use case is activated when the customer selects “Check for availability of tour
package” option to check for the availability of the tour that he wants to go on.
1.5.2. After the option is selected by the customer, the system checks the availability of
the tour with the tour information system database.
1.5.3. Once the system has checked with the TIS for the availability, it displays whether
the tour package is available or not, to the customer.
1.5.4. Post the result is displayed to the customer, the use case ends successfully.
1.6. Alternative flows:
1.6.1. Search for other tour: If the tour package selected by the customer is not
available, then:
1.6.1.1. The system displays message “Not available” and ask the customer to
search for other tour.
1.6.1.2. Use case resumes at point 1.
1.7. Key Scenarios: No response from the TIS.
1.8. Post-Conditions:
1.8.1. Successful completion: The customer is able to check the availability of the tour
package

2. Registration:
2.1. Use case Name: Registration
2.2. Use case Description: The above Use case describes the activity flow of the new
customer registering his details for future purpose.
2.3. Actors:
2.3.1. Primary actor: New customer
2.4. Pre-conditions:

Page 7
 2.4.1. The customer has the tour details and his personal info ready.
2.5. Basic Flow:
2.5.1. The use case is activated when the customer selects “register” option to register
his personal and tour details for future purpose.
2.5.2. After the option is selected by the customer, the customer has to follow up with
the process of entering his personal and tour details.
2.5.3. These details are stored in the TIS.
2.5.4. Once the customer has done entering these details, the use case ends successfully.
2.6. Alternative flows: NA
2.7. Dependency: this use case has include dependencies on Enter personal details and Enter
tour details use cases.
2.8. Key Scenarios: NA
2.9. Post-Conditions:
2.9.1. Successful completion: The customer is able to register successfully.

3. Enter personal details:

3.1. Use case Name: Enter personal details
3.2. Use case Description: The above Use case describes the activity flow of the new
customer entering his details to register.
3.3. Actors:
3.3.1. Primary actor: New customer
3.3.2. Secondary actor: Tour information system database
3.4. Pre-conditions:
3.4.1. The customer has his personal info ready.
3.5. Basic Flow:
3.5.1. The use case is activated when the customer selects “Enter personal detail” option
to register his personal details for registration.
3.5.2. After the option is selected by the customer, the customer enters his details into
the system.
3.5.3. These details are stored in the TIS as cust_info.
3.5.4. Once the customer has done entering the details, the use case ends successfully.
3.6. Alternative flows:
3.6.1. Missing info: If the customer fails to fill any of the necessary information, then:
3.6.1.1. The system displays “Missing info” message and asks the customer to
enter the details once again.
3.6.1.2. Use case resumes at point1.
3.7. Key Scenarios: NA
3.8. Post-Conditions:
3.8.1. Successful completion: The customer is able to enter his personal details
successfully.

Page 8
4. Enter tour details:
4.1. Use case Name: Enter tour details
4.2. Use case Description: The above Use case describes the activity flow of the new
customer entering the tour details to register.
4.3. Actors:
4.3.1. Primary actor: New customer
4.3.2. Secondary actor: Tour information system database
4.4. Pre-conditions:
4.4.1. The customer has the tour details ready.
4.5. Basic Flow:
4.5.1. The use case is activated when the customer selects “Enter tour details” option to
enter the tour details for his registration.
4.5.2. After the option is selected by the customer, he/she enters the details into the
system.
4.5.3. These details are stored in the TIS as tour_info.
4.5.4. Once the customer has done entering the details, the use case ends successfully.
4.6. Alternative flows: NA
4.7. Key Scenarios: NA
4.8. Post-Conditions:
4.8.1. Successful completion: The customer is able to enter tour details successfully.

5. Generate id:
5.1. Use case Name: Generate id
5.2. Use case Description: The above Use case describes the activity done by the system
once the new customer has registered.
5.3. Actors:
5.3.1. Primary actor: system clock
5.4. Pre-conditions: NA
5.5. Basic Flow:
5.5.1. The use case is activated when the system generates the id for the new customer,
after he/she is done with the registration.
5.5.2. Once the system has generated the id, the use case ends successfully.
5.6. Alternative flows: NA
5.7. Dependency: this use case has include dependency on registration use case.
5.8. Key Scenarios: NA
5.9. Post-Conditions:
5.9.1. Successful completion: Id is generated successfully by the system.

6. Generate password:
6.1. Use case Name: Generate password

Page 9
 6.2. Use case Description: The above Use case describes the activity done by the system
once the new customer has registered.
6.3. Actors:
6.3.1. Primary actor: system clock
6.4. Pre-conditions: NA
6.5. Basic Flow:
6.5.1. The use case is activated when the system generates the password for the new
customer, after he/she is done with the registration.
6.5.2. Once the system has generated the password, the use case ends successfully.
6.6. Alternative flows: NA
6.7. Dependency: this use case has include dependency on registration use case.
6.8. Key Scenarios: NA
6.9. Post-Conditions:
6.9.1. Successful completion: Password is generated successfully by the system.

7. Reservation of tour:
7.1. Use case Name: Reservation of tour
7.2. Use case Description: The above Use case describes the activity flow of the new
customer for reserving the tour, after he has registered.
7.3. Actors:
7.3.1. Primary actor: New customer
7.4. Pre-conditions: NA
7.5. Basic Flow:
7.5.1. The use case is activated when the customer selects “Reservation of tour” option
to reserve his details and the tour details for his confirmation in the future on the
tour package.
7.5.2. After the option is selected by the customer, details are stored in the TIS.
7.5.3. Once the customer has reserved these details, the use case ends successfully.
7.6. Alternative flows: NA
7.7. Dependency: this use case has include dependencies on Enter personal details and Enter
tour details use cases as the customer can only reserve once these details have been
entered.
7.8. Key Scenarios: NA
7.9. Post-Conditions:
7.9.1. Successful completion: The customer reserves the tour package successfully.

8. Confirmation of tour Package:

8.1. Use case Name: Confirmation of tour Package
8.2. Use case Description: The above Use case describes the activity flow of the new
/existing customer confirming the tour package.
8.3. Actors:
Page 10
 8.3.1. Primary actor: New/existing customer
8.4. Pre-conditions: NA
8.5. Basic Flow:
8.5.1. The use case is activated when the customer selects “Confirm tour package”
option to confirm his tour package, so that the tickets can be reserved.
8.5.2. After the option is selected by the customer, he/she is asked to do the payment.
8.5.3. Once the customer has confirmed the tour, the use case ends successfully.
8.6. Alternative flows: NA
8.7. Dependency: this use case has include dependency on Make payment use case.
8.8. Key Scenarios: NA
8.9. Post-Conditions:
8.9.1. Successful completion: The customer confirms the tour package successfully.

9. Make Payment:
9.1. Use case Name: Make Payment
9.2. Use case Description: this use case describes the action done by the customer to make
the payments for the tour package.
9.3. Actors:
9.3.1. Primary actor: New/existing customer
9.4. Pre-conditions: The customer should have the mode of payment ready for the payment to
be made.
9.5. Basic Flow:
9.5.1. The use case is activated when the customer selects “Make payment” option to
complete the payment for the tickets to be reserved.
9.5.2. Once the payment has been made, the use case ends successfully.
9.6. Alternative flows: NA
9.7. Key Scenarios: NA
9.8. Post-Conditions:
9.8.1. Successful completion: Customer is able to make a successful transaction.

10. Pay by Cash:

10.1. Use case Name: Pay by Cash
10.2. Use case Description: this use case describes the action done by the customer to
confirm the tour package by paying the amount in cash.
10.3. Actors:
10.3.1. Primary actor: New/existing customer
10.4. Pre-conditions: The customer has given the cash to the staff.
10.5. Basic Flow:
10.5.1. The use case is activated when the customer selects “Pay by cash” option to
complete the payment for the tickets to be reserved.
Page 11
 10.5.2. Once the payment has been made, the use case ends successfully.
10.6. Alternative flows: NA
10.7. Key Scenarios: NA
10.8. Post-Conditions:
10.8.1. Successful completion: Customer is able to make a successful transaction.

11. Pay by Cheque:

11.1. Use case Name: Pay by Cheque
11.2. Use case Description: this use case describes the action done by the customer to
confirm the tour package by paying the amount through Cheque.
11.3. Actors:
11.3.1. Primary actor: New/existing customer
11.4. Pre-conditions: The customer has given the cheque to the staff or dropped in the
bank.
11.5. Basic Flow:
11.5.1. The use case is activated when the customer selects “Pay by cheque” option to
complete the payment for the tickets to be reserved.
11.5.2. Once the payment has been made, the use case ends successfully.
11.6. Alternative flows: NA
11.7. Key Scenarios: NA
11.8. Post-Conditions:
11.8.1. Successful completion: Customer is able to make a successful transaction.

12. Pay by credit card:

12.1. Use case Name: Pay by credit card
12.2. Use case Description: this use case describes the action done by the customer to
confirm the tour package by paying the amount through credit card.
12.3. Actors:
12.3.1. Primary actor: New/existing customer
12.4. Pre-conditions: NA
12.5. Basic Flow:
12.5.1. The use case is activated when the customer selects “Pay by credit card” option to
complete the payment for the tickets to be reserved.
12.5.2. After the customer has selected the option, he is asked to enter the card details and
make the payment.
12.5.3. Once the payment has been made, the use case ends successfully.
12.6. Alternative flows:
12.6.1. Invalid pin: When the pin entered by the customer is incorrect, then:
12.6.1.1. The system will display an error message “Incorrect pin” and will ask the
customer to enter the card details once again.
12.6.1.2. Use case resumes back at point 2.
Page 12
 12.6.2. Decline: When the transaction gets declined due to an error in the card, then:
12.6.2.1. The system will display an error message “Decline” and will ask the
customer to enter the card details once again.
12.6.2.2. Use case resumes back at point 2
12.7. Key Scenarios: NA
12.8. Post-Conditions:
12.8.1. Successful completion: Customer is able to make a successful transaction.

13. Update personal details:

13.1. Use case Name: Update personal details
13.2. Use case Description: The above Use case describes the activity flow of the
existing customer updating his details.
13.3. Actors:
13.3.1. Primary actor: Existing customer
13.3.2. Secondary actor: Tour information system database
13.4. Pre-conditions:
13.4.1. The customer has his updated personal info ready to be entered.
13.5. Basic Flow:
13.5.1. The use case is activated when the customer selects “Update personal detail”
option to update his personal details.
13.5.2. After the option is selected by the customer, the customer enters his details into
the system.
13.5.3. These details are updated into the cust_info in TIS.
13.5.4. Once the customer is done updating the details, the use case ends successfully.
13.6. Alternative flows: NA
13.7. Key Scenarios: NA
13.8. Post-Conditions:
13.8.1. Successful completion: The customer is able to update his personal details
successfully.

14. Cancel reservation:

14.1. Use case Name: Cancel reservation
14.2. Use case Description: The above Use case describes the activity flow of the
existing customer cancelling his reservation for the desired tour package.
14.3. Actors:
14.3.1. Primary actor: Existing customer
14.3.2. Secondary actor: Tour information system database
14.4. Pre-conditions: NA
14.5. Basic Flow:
14.5.1. The use case is activated when the customer selects “Cancel reservation” option
to cancel his reservation for the tour package.
Page 13
 14.5.2. After the option is selected by the customer, the tour_info in the TIS is updated
accordingly.
14.5.3. Once the customer has cancelled the reservation, the use case ends successfully.
14.6. Alternative flows: NA
14.7. Key Scenarios: NA
14.8. Post-Conditions:
14.8.1. Successful completion: The customer is able to cancel the reservation
successfully.

15. Login:
15.1. Use case Name: Login
15.2. Use case Description: The above Use case describes the activity flow of the staff
while logging into the system.
15.3. Actors:
15.3.1. Primary actor: Staff
15.4. Pre-conditions: Staff has already been given the login credentials.
15.5. Basic Flow:
15.5.1. The use case is activated when the staff selects “login” option to login into the
system for reserving the tickets for the customer.
15.5.2. After the option is selected by the staff, he/she enters the login credentials into the
system.
15.5.3. Once the staff has logged in, the use case ends successfully.
15.6. Alternative flows:
15.6.1. Invalid credentials: If the staff fills any wrong credentials, then:
15.6.1.1. The system displays “Invalid credentials” message and asks the staff to
enter the details once again.
15.6.1.2. Use case resumes at point1.
15.7. Key Scenarios: NA
15.8. Post-Conditions:
15.8.1. Successful completion: The staff is able to login in to the system successfully.

16. Reserve the tickets:

16.1. Use case Name: Reserve the tickets
16.2. Use case Description: The above Use case describes the activity flow of the staff
reserving the tickets for the customer.
16.3. Actors:
16.3.1. Primary actor: Staff
16.4. Pre-conditions: NA
16.5. Basic Flow:
16.5.1. The use case is activated when the staff selects “Reserve tickets” option for
reserving the tickets on behalf of the customer.
Page 14
 16.5.2. After the option is selected by the staff, he/she books the tickets for the customer.
16.5.3. Once the staff has reserved the tickets, the use case ends successfully.
16.6. Alternative flows: NA
16.7. Dependency: this use case has include dependency on Login use case.
16.8. Key Scenarios: NA
16.9. Post-Conditions:
16.9.1. Successful completion: The staff is able to reserve the tickets successfully.

17. View reserved details:

17.1. Use case Name: View reserved details
17.2. Use case Description: The above Use case describes the activity flow of the
customer viewing his tickets reserved by the staff.
17.3. Actors:
17.3.1. Primary actor: Reserved customer
17.4. Pre-conditions: NA
17.5. Basic Flow:
17.5.1. The use case is activated when the customer selects “View reserved details”
option to view the reservations done by the staff.
17.5.2. Once the customer has viewed the details, the use case ends successfully.
17.6. Alternative flows: NA
17.7. Dependency: this use case has include dependency on Reserve the tickets use
case.
17.8. Key Scenarios: NA
17.9. Post-Conditions:
17.9.1. Successful completion: The customer is able to view the details successfully.

18. Manage tour schemes:

18.1. Use case Name: Manage tour schemes
18.2. Use case Description: The above Use case describes the activity flow of the
admin for managing the tour schemes.
18.3. Actors:
18.3.1. Primary actor: admin
18.3.2. Secondary actor: Tour information system
18.4. Pre-conditions:
18.4.1. The admin has the details of the tour package that has to be added or deleted or
modified.
18.4.2. There is an active connection between the system and the TIS.
18.5. Basic Flow:
18.5.1. The use case is activated when the admin selects “Manage tour scheme” option
for adding or deleting a tour package, and sometimes modify the existing tour
packages as well.
Page 15
 18.5.2. These changes are saved or modified in the TIS.
18.5.3. After the option is selected by the admin, he/she does any one of the activities
mentioned in 18.5.1.
18.5.4. Once the admin has done adding or deleting or modifying the schemes, the use
case ends successfully.
18.6. Alternative flows: NA
18.7. Key Scenarios: NA
18.8. Post-Conditions:
18.8.1. Successful completion: The admin is able to manage the schemes successfully.

19. Add:
19.1. Use case Name: Add
19.2. Use case Description: The above Use case describes the activity flow of the
admin adding new tour packages.
19.3. Actors:
19.3.1. Primary actor: admin
19.3.2. Secondary actor: Tour information system
19.4. Pre-conditions:
19.4.1. The admin has the details of the tour package that has to be added.
19.4.2. There is an active connection between the system and the TIS.
19.5. Basic Flow:
19.5.1. The use case is activated when the admin selects “add” option for adding a tour
scheme.
19.5.2. After the option is selected by the admin, he/she enters the tour details into the
system.
19.5.3. Once the admin has added the tour scheme, the use case ends successfully.
19.6. Alternative flows: NA
19.7. Key Scenarios: NA
19.8. Post-Conditions:
19.8.1. Successful completion: The admin is able to add the tour scheme successfully.

20. Delete:
20.1. Use case Name: Delete
20.2. Use case Description: The above Use case describes the activity flow of the
admin deleting new tour packages.
20.3. Actors:
20.3.1. Primary actor: admin
20.3.2. Secondary actor: Tour information system
20.4. Pre-conditions:
20.4.1. The admin has the details of the tour package that has to be deleted.
20.4.2. There is an active connection between the system and the TIS.
Page 16
 20.5. Basic Flow:
20.5.1. The use case is activated when the admin selects “delete” option for deleting a
tour scheme.
20.5.2. After the option is selected by the admin, he/she removes the tour details from the
system.
20.5.3. Once the admin has deleted the tour scheme, the use case ends successfully.
20.6. Alternative flows: NA
20.7. Key Scenarios: NA
20.8. Post-Conditions:
20.8.1. Successful completion: The admin is able to delete the tour scheme successfully.

21. Modify:
21.1. Use case Name: Modify
21.2. Use case Description: The above Use case describes the activity flow of the
admin modifying the existing tour schemes.
21.3. Actors:
21.3.1. Primary actor: admin
21.3.2. Secondary actor: Tour information system
21.4. Pre-conditions:
21.4.1. The admin has the details of the tour package that has to be modified.
21.4.2. There is an active connection between the system and the TIS.
21.5. Basic Flow:
21.5.1. The use case is activated when the admin selects “modify” option for modifying
the tour scheme.
21.5.2. After the option is selected by the admin, he/she enters the tour details into the
system.
21.5.3. Once the admin has modified the tour scheme, the use case ends successfully.
21.6. Alternative flows: NA
21.7. Key Scenarios: NA
21.8. Post-Conditions:
21.8.1. Successful completion: The admin has modified the tour scheme successfully.

9. Activity Diagram

1.1. Process Specific Activity Diagrams

Page 17
1.2. Activity Specification

Page 18
1.2.1. Basic Flow Process Steps :
Step 1 :
Step 2:
Step 3:
Step 4:
1.2.2. Alternative Flow Process Steps :
Step 1 :
Step 2:
Step 3:
Step 4:
1.2.3. Exception Flow Process Steps :
Step 1 :
Step 2:
Step 3:
Step 4:

2. Functional Requirements
Functional Requirements are those the system needs to perform all those actions which come in
the development of the application are considered to be functional requirements.]

Requirements are prioritize as per below Standards

M-Must have S-Should have C- Could be in future W-Would like to

S.NO Req ID Description Priority

1 FR_Domain_ID Functionality M/S/C/W
2 FR_Domain_ID Functionality M/S/C/W
3 FR_Domain_ID Functionality M/S/C/W

3. Non Functional Requirements

S.NO Req ID Description
1 NFR_Domain_ID Scalability Requirements
2. NFR_Domain _ID Security Requirements
3. NFR_Domain_ID Availability Requirements

Page 19
4. Prototyping

Page 20
Page 21
Page 22
Page 23
5. Master Tables

6. Notes

Page 24