0% found this document useful (0 votes)
29 views19 pages

20BCE204 - SE Practical-4

This document outlines use case specifications for an online railway management system, including registering and logging in users, managing user profiles, adding, updating and deleting train schedules, and tracking trains. It describes the actors and basic flows for each use case, along with alternative flows that may occur. The document is organized by use case and includes sections for brief descriptions, actors, pre-conditions, basic flows, alternative flows, and post-conditions.

Uploaded by

Dhyan Patel
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views19 pages

20BCE204 - SE Practical-4

This document outlines use case specifications for an online railway management system, including registering and logging in users, managing user profiles, adding, updating and deleting train schedules, and tracking trains. It describes the actors and basic flows for each use case, along with alternative flows that may occur. The document is organized by use case and includes sections for brief descriptions, actors, pre-conditions, basic flows, alternative flows, and post-conditions.

Uploaded by

Dhyan Patel
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Online Railway Management System

Use Case Specification

Prepared by:
20BCE191 Drashti Panseriya
20BCE198 Bhavya Patel
20BCE204 Dhyan Patel
20BCE206 Jinesh Patel
Table of Contents
1. Register
2. Login
3. Manage Profile
4. Schedule Management
5. Track Train
6. Search Train
7. Booking
6. Cancel Booking
8. Payment
Use Case Specification: Register
1. Register
1.1 Brief Description
This use case describes the flow of the registration process in the system.
2. Actors
Administrator
Customer
3. Basic Flow
3.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Register” icon.
3) The user fills up the form which opens up.
4) On clicking the “Register” button, the details entered are successfully saved in the database.
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 “Register” 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 field, the user
doesn’t follow the convention [email protected]
2) The validation will be fired when “Register” 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.2.3 Third Alternative Flow
1) All the fields have been entered properly.
2) The user clicks the “Register” 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 “Registration
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
5. Login
5.1 Brief Description
This use case describes the flow of the login process in the system.
6. Actors
Customer
Administrator
7. Basic Flow
7.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 the
role of the user.
4) The user enters the username, password and selects the role; then clicks on the login button.
The user is logged into the system based on their role.
7.2 Alternative Flows
7.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.
7.2.2 Second Alternative Flow
1) The user enters wrong values for the email field. In the email field, the user doesn’t follow
the convention [email protected]
2) The validation will be fired when “Login” button is clicked and the user will be asked to
enter a valid email address.
7.2.3 Third Alternative Flow
1) The user doesn’t enter the password with the format – 8 characters
2) The validation will be fired when “Login” button is clicked and the user will be asked to
enter a valid password.
7.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.
7.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 “Couldn’t login. Some
error occurred. Please try again”.

8. Post Conditions
On successful login, the user will be redirected to the home page.
Use Case Specification: Manage Profile
9. Manage Profile
9.1 Brief Description
This use case describes the flow for updating the profile of users in the system
10. Actors
Customer
Administrator
11. Flow of Events
11.1 Basic Flow
1) The user clicks on the “Manage Profile” 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.

11.2 Alternative Flows


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

11.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 “Update Failed!
Please try again”

12. Pre Condition


The user must be logged into the system before he/she can update their profile.
13. Post Condition
On successful updation, the user will be notified with the message “Profile updated
successfully”.
Use Case Specification: Schedule Management
14. Add Train Schedule
14.1 Brief Description
This use case describes the flow of the Add Train process in the system.
15. Actors
Administrator
16. Basic Flow
16.1 Basic Flow
1) The administrator accesses the home page of the site.
2) The administartor clicks on the “Add Train” icon.
3) The admin fills up the form which opens up.
4) On clicking the “Add Train” button, the details entered are successfully saved in the database.
5) Along with that a unique “Trip-code” is popped up on to the screen. The admin can now
track the train using the Trip-code provided.
16.2 Alternative Flows
16.2.1 First Alternative Flow
1) The admin mistakenly skips any of the required fields.
2) Clicking on the “Submit” button, the validation is fired and the admin is asked to fill in the
required fields.
16.2.2 Second Alternative Flow
1) All the fields have been entered properly.
2) The admin clicks the “Submit” button. Some problem occurs while saving the records in
database.
3) The records will not be saved and the admin will be displayed the message “Couldn’t add
the train! Please try again”
17. Pre Condition
The admin must be logged into the system before he/she can add a train.
18. Post Condition
On successfully adding the Train, the customer will be notified with the message “Add Train
successful”.

19. Update Train Status


19.1 Brief Description
This use case describes the flow of the update Train status process in the system.
20. Actors
Administrator
21. Basic Flow
21.1 Basic Flow
1) The admin accesses the home page of the site.
2) The user clicks on the “Update Train” icon.
3) A text field is displayed where the Trip-code needs to be entered.
4) On clicking the “Update Train” button, gets redirected to a page “Scheduled Train Details”,
where the details related to Train like status, current location, expected time of completion of
journey etc is displayed.
5) Now, the admin can change the Train status details like current location or the status of the
train as there is any further improvement on the train schedule.
6) He/She then clicks on “Update Train”, and the details are saved on the database.
21.2 Alternative Flows
21.2.1 First Alternative Flow
1) The admin mistakenly skips any of the required fields.
2) Clicking on the “Submit” button, the validation is fired and the admin is asked to fill in the
required fields.
21.2.2 Second Alternative Flow
1) The admin mistakenly typed some of the characters that are not allowed in some fields.
2) The admin clicks the “Submit” button. Some problem occurs while saving the records in
database.
3) The records will not be saved and the admin will be displayed the message “Please enter
correct details.”

22. Pre Condition


The admin must be logged into the system before he/she can update a Train status.

23. Post Condition


On successfully adding the train, the admin will be notified with the message “Update Train
Status successful”.

24. Delete Train Status


24.1 Brief Description
This use case describes the flow of the delete Train process in the system.
25. Actors
Administrator
26. Basic Flow
26.1 Basic Flow
1) The admin accesses the home page of the site.
2) The admin clicks on the “Track Train” icon.
3) A text field is displayed where the trip-code number needs to be entered.
4) On clicking the “Track Train” button, gets redirected to a page “Train Details”, where the
details related to shipment like status, current location, expected time of reaching destination
etc is displayed.
5) He/She then clicks on “Delete Train”, and the details are cleared from the database.
26.2 Alternative Flows
26.2.1 First Alternative Flow
1) The admin mistakenly skips any of the required fields.
2) Clicking on the “Submit” button, the validation is fired and the admin is asked to fill in the
required fields.
26.2.2 Second Alternative Flow
1) The admin mistakenly typed some of the characters that are not allowed in some fields.
2) The admin clicks the “Submit” button. Some problem occurs while saving the records in
database.
3) The records will not be saved and the admin will be displayed the message “Please enter
correct details.”

27. Pre Condition


The admin must be logged into the system before he/she can delete a Train.

28. Post Condition


On successfully deleting the Train, the admin will be notified with the message “Delete Train
successful”.

Use Case Specification: Track Train


29. Track Train
29.1 Brief Description
This use case describes the flow of the track train process in the system.
30. Actors
Customer
31. Basic Flow
31.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Track train” icon.
3) A text field is displayed where the trip-code or PNR no. needs to be entered.
4) On clicking the “Track train” button, gets redirected to a page “train Details”, where the
details related to train like status, current location, expected time of reaching destination etc is
displayed.
31.2 Alternative Flows
31.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 fill in
the required fields.
31.2.2 Second Alternative Flow
1) The user mistakenly typed some of the characters that are not allowed in “trip-code/PNR
no.” field.
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 enter
correct Trip-code/PNR no..”
32. Pre Condition
The customer must be logged into the system before he/she can track a train.

Use Case Specification: Search Train


33. Search Train
33.1 Brief Description
This use case describes the flow of the Search Train process in the system.
34. Actors
Customer
35. Basic Flow
35.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Search train” icon.
3) Different fields are displayed where the user can needs to enter Pickup-Destination point/
Date / Price/Time to filter and search trains from list.
4) On clicking the “Search train” button, gets redirected to a page “train Details”, where the
details related to train like status, current location, expected time of reaching destination etc is
displayed.
35.2 Alternative Flows
35.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 fill in
the required fields.
35.2.2 Second Alternative Flow
1) The user mistakenly typed some of the characters that are not allowed in “Date/Price/Time.”
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 enter
correct details..”
36. Pre Condition
The customer must be logged into the system before he/she can Search a train.

Use Case Specification: Booking tickets


37. Booking
37.1 Brief Description
This use case describes the flow of the Booking of Train tickets process in the system.
38. Actors
Customer
39. Basic Flow
39.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Book train” icon.
3) Different fields are displayed where the user can needs to enter Pickup-Destination point/
Date / Price/Time to filter and search trains from list.
4) On clicking the “Book train” button, gets redirected to a page “train Details”, where the
details related to train like status, current location, expected time of reaching destination etc is
displayed and is redirected to payment gateway page after selection of number of seats and
confirmation.
39.2 Alternative Flows
39.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 fill in
the required fields.
39.2.2 Second Alternative Flow
1) The user mistakenly typed some of the characters that are not allowed in “Date/Price/Time.”
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 enter
correct details..”
40. Pre Condition
The customer must be logged into the system before he/she can Search a train.
Use Case Specification: Cancel Booking
41. Cancel Booking
41.1 Brief Description
This use case describes the flow of the Cancellation of Booked Train tickets process in the
system.
42. Actors
Customer
43. Basic Flow
43.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “booked train” icon.
3) Different fields booked train are displayed like number of seats booked and its aminities,
price details.
4) On Selecting the seats to be cancelled and clicking “confirm” icon, the user is redirected to
refund ways and refund status page .
43.2 Alternative Flows
43.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 fill in
the required fields.
43.2.2 Second Alternative Flow
1) The user mistakenly typed some of the characters that are not allowed in “Date/Price/Time.”
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 enter
correct details..”
44. Pre Condition
The customer must be logged into the system before he/she can Search a train.
45. Post Condition
The customer will be shown his refund status and cancellation successful message.
Use Case Specification: Payment
46. Payment
46.1 Brief Description
This use case describes the flow of the Payment process in the system.
47. Actors
Customer
48. Basic Flow
48.1 Basic Flow
1) The user accesses the home page of the site.
2) The user clicks on the “Confirm booking” icon.
3) Different fields booked train are displayed like number of seats booked , its aminities, price
details and different modes of payment available.
4) On Selecting the mode of payment and clicking “Pay” icon, the user is redirected to Payment
gateway for final payment details and confirmation of payment.
48.2 Alternative Flows
48.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 fill in
the required fields.
48.2.2 Second Alternative Flow
1) The user mistakenly typed some of the characters that are not allowed in “Payment detail.”
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 enter
correct details..”
49. Pre Condition
The customer must be logged into the system before he/she can book and pay for a train.
50. Post Condition
The customer will be shown his booking status and payment successful message.

You might also like