Download as pdf or txt
Download as pdf or txt
You are on page 1of 10

Travel and Tourism Management System

Use Case Specification

19BCE228 Rudransh Vyas


19BCE236 Samariya Darsh
19BCE244 Ronak Saxena
Revision History
Date Version Description Author
1.0 Initial Version
Table of Contents
1. SignUp

2. Login

3. Update Account

4. Book Package

5. Delete Package

6. Update Package

7. Feedback/support
Use Case Specification: SIGN UP
1. SIGN UP
1.1 Brief Description
This use case describes the flow of the registration process in the system.
2. Actors
Customer
Administrator
3. Basic Flow
3.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Sign Up” icon.
3) The user fills up the form which opens up.
4) On clicking the “Sign Up” button, the details entered are successfully saved in t h e d atabase.
The user can now access the system with the username and password he/she has chosen.
3.2 Alternative Flows
3.2.1 First Alternative Flow
1) The user doesn’t enter all the mandatory fields in the registration form.
2) Clicking on the “Sign Up” button, the validation is fired and the user is asked to fill in the
required fields.
3.2.2 Second Alternative Flow
1) The user enters wrong values for some of the fields. For example: In the email f ield , t h e u ser
doesn’t follow the convention somename@provider.com
2) The validation will be fired when “Sign Up” button is clicked and the user will be asked to
enter a valid email address. Same holds for any other fields which have some patterns to be
followed.
3)If the user forgets the password, he/she can retrieve password by replying to security question.
3.2.3 Third Alternative Flow
1) All the fields have been entered properly.
2) The user clicks the “Sign Up” button. Some problem occurs while saving the records in
database.
3) The records will not be saved and the user will be displayed the message “Sign Up Failed!”

4. Post Conditions
1) On successful registration, the user will be logged into the system automatically with the
registered username and password.
2) The user will be redirected to their profile page.
Use Case Specification: Login
1. Login
1.1 Brief Description
This use case describes the flow of the login process in the system.
2. Actors
Customer
Administrator
3. Basic Flow
3.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Login” link.
3) The login page opens up which asks for username and password. Also it asks to select th e ro le
of the user.
4) The user enters the username, password and selects the role; then clicks on t h e lo gin b u t ton .
The user is logged into the system based on their role.
3.2 Alternative Flows
3.2.1 First Alternative Flow
1) All the fields on login page are mandatory. The user skips any of the fields and clicks on Login
button.
2) The validation is fired asking to user to enter all the mandatory fields.
3.2.2 Second Alternative Flow
1) The user enters wrong values for the email field. In the email field, the user doesn’t follo w t h e
convention somename@provider.com
2) The validation will be fired when “Login” button is clicked and the user will be asked to enter a
valid email address.
3.2.3 Third Alternative Flow
1) The user doesn’t enter the password with the format – 8 characters, Uppercase character,
Lowercase character, Special Character
2) The validation will be fired when “Login” button is clicked and the user will be asked to enter a
valid password.
3.2.4 Fourth Alternative Flow
1) The user enters incorrect username or password.
2) On clicking the “Login” button, the message will be displayed “Incorrect Username or
Password”. The user will have to again enter the correct details and login.
3)User can retrieve password by answering a security question that they entered during sign up.
3.2.5 Fifth Alternative Flow
1) All the fields have been entered properly.
2) The user clicks the “Login” button. The database connection fails at this point.
3) The details can’t be checked at this point and a message is displayed “C ould n’t l o gin . So m e
error occurred. Please try again”.

4. Post Conditions
On successful login, the user will be redirected to the home page.
Use Case Specification: Update Account
1. Update Account
1.1 Brief Description
This use case describes the flow for updating the profile of users in the system

2. Actors
Customer
Administrator
3. Flow of Events
3.1 Basic Flow
1) The user clicks on the “Update Account” link.
2) The registration form opens up with all the filled in details.
3) The user can update the required fields and on clicking the “Submit” button, the details are
saved in the database.

3.2 Alternative Flows


3.2.1 First Alternative Flow
1) The user mistakenly skips any of the required fields.
2) Clicking on the “Submit” button, the validation is fired and the user is asked to fill in the
required fields.

3.2.2 Second Alternative Flow


1) All the fields have been entered properly.
2) The user clicks the “Submit” button. Some problem occurs while saving the records in
database.
3) The records will not be saved and the user will be displayed the message “Updation Failed!
Please try again”

4. Pre Condition
The user must be logged into the system before he/she can update their profile.
5. Post Condition
On successful updation, the user will be notified with the message “Profile up dated successfully”.
Use Case Specification: BOOK PACKAGE
1. Book Package
1.1 Brief Description
This use case describes the flow of booking package process in the system.
2. Actors
Customer
3. Basic Flow
3.1 Basic Flow
1) The user accesses the home page of the app.
2) The user clicks on the “View Package” icon.
3)User can search the best package according to suitable place, price, accommodations
3) The user fills up the form which opens up after selecting particular p ackage wh ich in v olv es
details regarding members, days, mode of travel, hotels etc.
4) On clicking the “Book Package” button, the details entered are successfully saved in the
database.
5)Booking id is generated.
6)User can click on pay and he/she will be forwarded to payment gateway.
3.2 Alternative Flows
3.2.1 First Alternative Flow
1) The customer mistakenly skips any of the required fields.
2) Clicking on the “Submit” button, the validation is fired and the customer is asked to f ill in t h e
required fields.
3.2.2 Second Alternative Flow
1) All the fields have been entered properly.
2) The customer clicks the “Submit” button. Some problem occurs while sa v in g t h e reco rd s in
database.
3) The records will not be saved and the customer will be displayed the message “Couldn’t b o ok!
Please try again”
4. Pre Condition
The customer must be logged into the system before he/she can book a package.
5. Post Condition
On successfully adding the booking is succesfull, the customer will be notified with the message
“Package booking successful”.
Use Case Specification: Delete Package
1. Delete Package
1.1 Brief Description
This use case describes the flow of the deleting package/booked package process in the system.
2. Actors
Customer
Administrator
3. Basic Flow
3.1 Basic Flow
1) The user accesses the home page of the site.
2) The user logins into his/her account.
3) The user clicks on the “Booked package” icon.
4) A text field is displayed where the booking id needs to be entered.
5) On clicking the “Delete Package” button, final warning is given regarding package delet io n.
Then is user asserts then package is removed and message “Package successfully removed” is
popped up and then details are cleared from the database.
3.2 Alternative Flows
3.2.1 First Alternative Flow
1) The user mistakenly tries to delete a paid booked package.
2) Clicking on the “Delete” button, the process is fired and the customer is reminded “Payment for
booked package was already done! Package cannot be deleted”.
3.2.2 Second Alternative Flow
1) The user mistakenly enters invalid booking id
2) The user clicks the “Submit” button. Some problem occurs while opening booked package.
3) The booked package will not be displayed and the customer will b e d isp la y ed t he m essage
“Enter correct booking id”
4. Pre Condition
The customer must be logged into the system before he/she can track a shipment.
The customer should not have paid/purchased booked package.
Use Case Specification: Update Package
1. Update Package
1.1 Brief Description
This use case describes the flow of the update Package in the system.
2. Actors
Employee
Administrator
3. Basic Flow
3.1 Basic Flow
1) The user accesses the home page of the site.
2) The user logins into his/her account
3) The user clicks on the “Update Package” icon.
4) A text field is displayed where the booking id needs to be entered.
5) On clicking the “Update Package” button, gets redirected to a page “Package details”, wh ere
the details related to package like hotels, mode of travel, pickup point, route etc. are
displayed.
6) Now, the admin or the employee can change the Package details like pickup location, ho tels,
mode of transport, route time to time as when it is required.
7) He/She then clicks on “Update Package”, and the details are saved on the database.
3.2 Alternative Flows
3.2.1 First Alternative Flow
1) The user mistakenly skips any of the required fields.
2) Clicking on the “Submit” button, the validation is fired and the customer is asked to f ill in t h e
required fields.
3.2.2 Second Alternative Flow
1) The user mistakenly typed some of the characters that are not allowed in some fields.
2) The user clicks the “Submit” button. Some problem occurs while saving the records in
database.
3) The records will not be saved and the customer will be displayed the message “ Please ent er
correct details.”

4. Pre Condition
The customer must be logged into the system before he/she can update a package.

5. Post Condition
On successfully adding the package, the customer will be notified with t h e m essage “ Package
update successful”.
Use Case Specification: Feedback Support
1. Feedback Support
1.1 Brief Description
This use case describes the flow of the feedback support process in the system.
2. Actors
Customer
3. Basic Flow
3.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Feedback” icon.
3) A text field is displayed where the feedback can be entered.
4) Also by clicking the “Complaint” button, the customer will be asked to give the reason f or t h e
complaint.
5) Then a popup box will display a complaint number used for future reference of the complaint
3.2 Alternative Flows
3.2.1 First Alternative Flow
1) The user mistakenly skips any of the required fields.
2) Clicking on the “Submit” button, the validation is fired and the customer is asked to f ill in t h e
required fields.
3.2.2 Second Alternative Flow
1) The user mistakenly typed some of the characters that are not allowed in some fields.
2) The user clicks the “Submit” button. Some problem occurs while saving the records in
database.
3) The records will not be saved and the customer will be displayed the message “ Please ent er
correct details.”

4. Pre Condition
The customer must be logged into the system before he/she can lo g a co m plain t a gainst a n y
inconvenience.

5. Post Condition
On successfully adding an feedback and complaint, the customer will be notified with the
message “Feedback registered”.

You might also like