COMSATS University Islamabad (CUI)

Software Requirement Specification

(SRS DOCUMENT)
for

TravelTailor: AI Trip Planner for Pakistan

Version 1.0

By

Syed Muhammad Hamza CIIT/SP22-BCS-099/ISB

Saad Ameer Khan CIIT/SP22-BCS-085/ISB

 Table of Contents
Contents
1. Introduction .............................................................................................................................................. 4
1.1 Purpose ............................................................................................................................................... 4
1.2 Scope ................................................................................................................................................... 4
1.3 Modules .............................................................................................................................................. 4
1.3.1 Module 1: User Account Management........................................................................................ 4
1.3.2 Module 2: AI-based Itinerary Generator...................................................................................... 4
1.3.3 Module 3: Customized Mapping and Navigation ........................................................................ 4
1.3.4 Module 4: Language and Cultural Guide ..................................................................................... 4
1.3.5 Module 5: Budget and Expense Tracker ...................................................................................... 5
1.3.6 Module 6: Points of Interest Recommendations ......................................................................... 5
1.3.7 Module 7: Community Review Hub ............................................................................................. 5
1.3.8 Module 8: Travel Safety and Alerts Module ................................................................................ 5
1.4 Overview ............................................................................................................................................. 5
2. Overall Description.................................................................................................................................... 5
2.1 Product Perspective ............................................................................................................................ 5
2.2 User Classes and Characteristics ......................................................................................................... 5
2.3 Operating Environment ...................................................................................................................... 6
2.4 Design and Implementation Constraints ............................................................................................ 6
3. Requirement Identifying Technique ......................................................................................................... 6
3.1 Use Case .............................................................................................................................................. 6
3.1.1 Use Case Diagram ........................................................................................................................ 6
3.1.2 Detailed Use Cases ....................................................................................................................... 7
3.2 Event Response Tables...................................................................................................................... 15
3.2.1 ERT-1: User Submits Tour Preferences ...................................................................................... 15
3.2.2.ERT-2: AI Itinerary Generation Completed ................................................................................ 15
3.2.3.ERT-3: Payment Completion ...................................................................................................... 16
3.2.4.ERT-4: User Cancels Booking ..................................................................................................... 16
3.2.5.ERT-5: User Provides Feedback.................................................................................................. 16
4. Functional Requirements ........................................................................................................................ 17
4.1 UC-1: Register Account ..................................................................................................................... 17
 4.2 UC-2: Login ........................................................................................................................................ 17
4.3 UC-3: Password Reset ...................................................................................................................... 18
4.4 UC-4: Profile Update ......................................................................................................................... 18
4.5 UC-5: Authentication via Google ...................................................................................................... 18
5. Non-Functional Requirements ................................................................................................................ 19
5.1 Usability ............................................................................................................................................ 19
5.2 Performance ..................................................................................................................................... 19
5.3 Interoperability ................................................................................................................................. 19
5.4 Security ............................................................................................................................................. 20
5.5 Integrity ............................................................................................................................................. 20
6. External Interface Requirements ............................................................................................................ 20
6.1 User Interface Requirements ............................................................................................................ 20
6.2 Software Interfaces ........................................................................................................................... 21
6.3 Hardware Interfaces ......................................................................................................................... 21
6.4 Communications Interfaces .............................................................................................................. 21
1. Introduction

1.1 Purpose
The purpose of the TravelTailor application is to simplify travel planning for tourists visiting Pakistan by
providing a user-friendly, AI-powered itinerary management platform. It caters to individual travel needs
such as interests, budget, available time, and preferences for activities (adventure, food, culture,
nature), offering a seamless and personalized experience for both local and international tourists.

1.2 Scope
TravelTailor is a comprehensive travel planning application designed for tourists interested in exploring
Pakistan. Its main functionalities include personalized itinerary generation, customized maps, budgeting
tools, cultural guidance, and real-time travel alerts. This project aims to bridge the gap for tourists
unfamiliar with local customs, languages, and destinations by providing a smart, AI-driven platform that
covers all aspects of a tour, from planning to navigation and local recommendations.

1.3 Modules
1.3.1 Module 1: User Account Management
 FE-1: Register and log in using email or social media accounts.

 FE-2: Save user preferences and travel history.

 FE-3: Update profile information and manage saved trips.

1.3.2 Module 2: AI-based Itinerary Generator

 FE-1: Generate a detailed itinerary based on user input (e.g., days, interests, budget).

 FE-2: Provide daily activity breakdown and estimated travel times.

 FE-3: Suggest optimized routes and schedules.

1.3.3 Module 3: Customized Mapping and Navigation

 FE-1: Display customized maps with detailed directions.

 FE-2: Provide location-based directions and estimated travel time between points.

 FE-3: Show daily map routes for scheduled activities.

1.3.4 Module 4: Language and Cultural Guide

 FE-1: Offer language translation for common travel phrases.

 FE-2: Provide cultural etiquette tips for local customs and norms.

 FE-3: Include a guide for safe interaction and behavior.

1.3.5 Module 5: Budget and Expense Tracker
 FE-1: Allow users to set a travel budget and track expenses.

 FE-2: Record daily spending and provide a budget summary.

 FE-3: Offer alerts when spending exceeds a preset limit.

1.3.6 Module 6: Points of Interest Recommendations

 FE-1: Suggest popular tourist attractions based on interests.

 FE-2: Recommend places for food, shopping, and cultural experiences.

 FE-3: Provide information on peak visiting times and special events.

1.3.7 Module 7: Community Review Hub

 FE-1: Allow users to view reviews and feedback from other tourists.

 FE-2: Enable users to post reviews and rate destinations.

 FE-3: Integrate with social media for travel sharing.

1.3.8 Module 8: Travel Safety and Alerts Module

 FE-1: Provide real-time safety alerts and location-based notifications.

 FE-2: Offer emergency contact information and medical resources.

 FE-3: Track and update users on area-specific travel advisories.

1.4 Overview
TravelTailor consolidates multiple travel planning features into one application for tourists visiting
Pakistan. Its AI-driven itinerary, custom maps, budgeting tool, and community-driven review hub make
it an ideal travel assistant. The app's modular structure ensures flexibility and adaptability for adding
new features as travel needs evolve.

2. Overall Description
2.1 Product Perspective
TravelTailor is an AI-based tour and itinerary management application tailored for tourists in Pakistan,
integrating functionalities that streamline travel planning and enhance user experience with AI-
generated itineraries, budget tracking, custom maps, and real-time safety alerts.

2.2 User Classes and Characteristics

 Tourists: Individuals seeking a customized and structured travel plan for visiting attractions in
Pakistan.

 Local Travelers: Domestic users who want to explore Pakistan with organized itineraries.
  Admin/Service Providers: Admins manage safety alerts, POI data, and community content,
keeping information relevant and updated.

2.3 Operating Environment

 TravelTailor is compatible with both mobile devices and web browsers.

 The app will require internet access for real-time updates and location-based services.

2.4 Design and Implementation Constraints

 Data Security: Implement strong security measures for user data and payment details.

 Real-time Data: Ensure accuracy for map navigation, weather, and safety updates.

 Scalability: Design the backend to support high traffic as more users adopt the app.

3. Requirement Identifying Technique

3.1 Use Case

For the TravelTailor project, the primary use case actor can be the Tourist, as they represent the main
user group seeking itinerary planning and personalized travel guidance. The use case will focus on the
essential actions a Tourist performs, such as selecting preferences, viewing itineraries, and managing
schedules.

3.1.1 Use Case Diagram

3.1.2 Detailed Use Cases
UC-1: Register Account
Description: In this use case, a tourist aims to register an account in the TravelTailor application. They
provide essential details such as name, email ID, phone number, and password. The system checks the
uniqueness of the email ID. If the email is already in use, the tourist is prompted to provide a different
one. Upon successful registration, a confirmation message is displayed, and the user is redirected to the
application's home page.

Actors:

 Primary Actor: Tourist

Trigger:

 Tourist selects the "Register Account" option after opening the application.

Preconditions:

 PRE-1: Tourist has a valid phone number.

 PRE-2: Tourist has a valid email ID.

Postconditions:

 POST-1: Tourist's record is saved in the database.

 POST-2: Tourist is redirected to the application's home page.

Normal Flow:

1. Tourist selects the "Register Account" option.

2. Tourist enters their name.

3. Tourist enters an email ID. (see 1.0.E1)

4. Tourist enters a phone number.

5. Tourist sets a password.

6. System displays a message confirming successful account creation.

Alternative Flows:

 1.1 Register via Google

1. Tourist selects "Register via Google" option.

 2. The use case resumes at step 6 of the normal flow after Google authentication is
successful.

Exceptions:

 1.0.E1 Already registered email

1. The system displays an error message that the email is already registered. 2a. If
the tourist decides to cancel the registration process, the system terminates the
use case.
2b. If the tourist decides to enter a new email ID, the use case resumes at step 3
of the normal flow.
Business Rules:

 BR-1: Only one account can be registered for a given email ID.

Assumptions:

1. An active internet connection is available to the tourist.

2. Tourist knows the process of registering in applications.

UC-2: Login
Description: The tourist logs into their account by entering their email and password. If the credentials
are correct, they gain access to the app; otherwise, an error is shown.

 Actors: Tourist

 Trigger: Tourist selects the "Login" option.

 Preconditions: Tourist has registered with valid credentials.

 Postconditions: Tourist is logged into the app.

Normal Flow:

1. Tourist selects "Login" and enters email and password.

2. System validates credentials.

3. System grants access and redirects to the home page.

Exceptions:
  E1: Incorrect credentials - System shows an error message.

Business Rules:

 BR-1: Only registered users can log in.

UC-3: Edit Profile

Description: The tourist updates personal information like name, email, or phone number.

 Actors: Tourist

 Trigger: Tourist selects "Edit Profile".

 Preconditions: Tourist is logged in.

 Postconditions: Tourist's updated information is saved in the database.

Normal Flow:

1. Tourist selects "Edit Profile".

2. Tourist updates relevant fields.

3. System saves changes and confirms update.

Exceptions:

 E1: Invalid data format - System displays error message.

Business Rules:

 BR-1: Unique email ID must be maintained.

UC-4: Select Location

Description: Tourist chooses a preferred location for a tour.

 Actors: Tourist

 Trigger: Tourist selects a location.

 Preconditions: Tourist is logged in.

 Postconditions: Location preference is saved.

Normal Flow:

1. Tourist selects "Location".

2. System saves the location preference.

UC-5: Enter Personalized Details about Tour

Description: Tourist enters preferences like number of days, interests, and budget to receive customized
tour suggestions.

 Actors: Tourist

 Trigger: Tourist provides personalized details.

 Preconditions: Tourist is logged in.

 Postconditions: Preferences are saved for AI itinerary generation.

Normal Flow:

1. Tourist enters trip preferences.

2. System saves and processes the data.

UC-6: Generate AI Itinerary

Description: The system generates a tailored itinerary based on tourist’s input.

 Actors: Tourist

 Trigger: Tourist requests AI-generated itinerary.

 Preconditions: Tourist has entered trip preferences.

 Postconditions: AI-generated itinerary is displayed.

Normal Flow:

1. Tourist selects "Generate Itinerary".

2. System processes input and displays an itinerary.

Exceptions:
  E1: Insufficient data - System prompts for additional input.

UC-7: Plan Manually

Description: Tourist manually creates a tour plan by selecting destinations and dates.

 Actors: Tourist

 Trigger: Tourist chooses "Plan Manually".

 Preconditions: Tourist is logged in.

 Postconditions: Custom tour plan is saved.

Normal Flow:

1. Tourist adds locations and dates.

2. System saves the custom plan.

UC-8: Search for Nearby Activities

Description: The tourist searches for activities available near the selected location.

 Actors: Tourist

 Trigger: Tourist initiates a search for nearby activities.

 Preconditions: Tourist has selected a location.

 Postconditions: Nearby activities are displayed.

Normal Flow:

1. Tourist initiates search.

2. System displays nearby activities.

UC-9: Get Navigation Directions

Description: Tourist requests navigation directions to a specific location.

 Actors: Tourist
  Trigger: Tourist selects "Get Directions".

 Preconditions: Tourist has selected a destination.

 Postconditions: Directions are displayed.

Normal Flow:

1. Tourist selects "Get Directions".

2. System displays navigation.

UC-10: Search for Pre-Made Tours

Description: Tourist searches for pre-made tour packages available for the selected location.

 Actors: Tourist

 Trigger: Tourist initiates search for pre-made tours.

 Preconditions: Tourist has selected a location.

 Postconditions: Available tours are displayed.

Normal Flow:

1. Tourist selects "Pre-Made Tours".

2. System displays tour packages.

UC-11: Book a Tour

Description: Tourist books a selected tour package.

 Actors: Tourist

 Trigger: Tourist selects "Book Tour".

 Preconditions: Tourist has selected a tour package.

 Postconditions: Tour is booked, and booking details are saved.

Normal Flow:

1. Tourist selects "Book".

 2. System processes booking and confirms.

UC-12: Checkout
Description: Tourist completes the payment for a booked tour.

 Actors: Tourist

 Trigger: Tourist proceeds to checkout.

 Preconditions: Tourist has a booked tour.

 Postconditions: Payment is processed, and a receipt is generated.

Normal Flow:

1. Tourist selects "Checkout".

2. System processes payment.

Exceptions:

 E1: Payment failure - System displays error and allows retry.

UC-13: Feedback
Description: Tourist provides feedback after completing a tour.

 Actors: Tourist

 Trigger: Tourist selects "Feedback" option.

 Preconditions: Tourist has completed a tour.

 Postconditions: Feedback is saved.

Normal Flow:

1. Tourist enters feedback.

2. System saves feedback.

UC-14: Logout
Description: The tourist logs out of the application.

 Actors: Tourist

 Trigger: Tourist selects "Logout".

 Preconditions: Tourist is logged in.

 Postconditions: Tourist is logged out of the application.

Normal Flow:

1. Tourist selects "Logout".

2. System ends the session.

3.2 Event Response Tables

3.2.1 ERT-1: User Submits Tour Preferences

System Exception
ID Event Data Element System Response System State
State Condition

Tour In case of yes: System Preferences

User submits preferences Awaiting Missing or validates and saves saved and
1 tour (number of user invalid preferences.<br>In case of ready for
preferences days, budget, input input no: System prompts for itinerary
interests) required fields. generation

3.2.2.ERT-2: AI Itinerary Generation Completed

Data System Exception

ID Event System Response System State
Element State Condition

In case of yes: System

Itinerary
AI- AI algorithm displays the generated
AI itinerary Waiting generated
generated fails to itinerary.<br>In case of no:
2 generation for AI and
itinerary generate System displays an error
completed response displayed to
details itinerary message and offers manual
user
planning options.
3.2.3.ERT-3: Payment Completion

Data System Exception

ID Event System Response System State
Element State Condition

In case of yes: System

Payment confirms booking and sends Booking
Awaiting Payment
Payment details, receipt.<br>In case of no: confirmed
3 payment gateway
completion transaction System displays error and and recorded
processing error
ID prompts user to retry in system
payment.

3.2.4.ERT-4: User Cancels Booking

Data System Exception

ID Event System Response System State
Element State Condition

In case of yes: System processes

Booking
User Unable to cancellation and updates
Booking Booking canceled and
4 cancels find booking records.<br>In case of no: System
details confirmed records
booking details displays error and suggests
updated
contacting support.

3.2.5.ERT-5: User Provides Feedback

Data Exception System

ID Event System State System Response
Element Condition State

In case of yes: System saves

User Awaiting No feedback and thanks Feedback
Feedback
5 provides feedback feedback user.<br>In case of no: System recorded in
content
feedback submission provided prompts user to add feedback system
before submission.
4. Functional Requirements
4.1 UC-1: Register Account
 FR-1: Account.Register
The system shall provide an option for users to register an account by entering essential details
like name, username, email, phone number, and password.

 FR-2: Account.Validate
The system shall validate that the username and email entered during registration are unique
and not already registered within the system.
Business Rules:

o BR-1: Only one account can be registered per username.

o BR-2: Only one account can be registered per email ID.

 FR-3: Account.Invalid.Username
If the entered username is already registered, the system shall display an error message
prompting the user to choose another username.

 FR-4: Account.Invalid.Email
If the entered email is already registered, the system shall display an error message prompting
the user to use a different email.

 FR-5: Account.Registration.Confirmation
Upon successful registration, the system shall display a confirmation message and redirect the
user to the application's home page.

4.2 UC-2: Login

 FR-6: Login.Information
The system shall provide a login form for users to enter their registered email or username
along with a password to access their account.

 FR-7: Login.Information.Validate
The system shall validate the entered credentials. If they match an existing account, access will
be granted.

 FR-8: Login.Information.Invalid
If the credentials are incorrect, the system shall display an error message, allowing the user to
re-enter their credentials.

 FR-9: Login.Information.Valid
Upon successful login, the user is granted access to the application's main interface.
4.3 UC-3: Password Reset
 FR-10: Password.Reset.Request
The system shall provide an option for users to reset their password if they have forgotten it.

 FR-11: Password.Reset.EmailInput
The user must enter their registered email to initiate a password reset request. The system will
send a password reset link to the specified email.

 FR-12: Password.Reset.Validate
The system shall verify that the entered email is associated with an account in the database.

 FR-13: Password.Reset.Link
The system shall send a password reset link to the user's email upon successful validation.

 FR-14: Password.Reset.NewPassword
The password reset page shall allow users to enter a new password.

4.4 UC-4: Profile Update

 FR-15: Profile.View
The system shall provide a profile page where users can view their current details, including
name, username, email, and phone number.

 FR-16: Profile.Edit
The system shall allow users to update their profile information, such as name, email, and
phone number.

 FR-17: Profile.Update.Validate
When updating email or username, the system shall validate that the new values are unique.

 FR-18: Profile.Update.Invalid
If the new email or username is already in use, the system shall display an error message
prompting the user to enter a unique value.

 FR-19: Profile.Update.Confirmation
Upon successful profile update, the system shall display a confirmation message and save the
new information.

4.5 UC-5: Authentication via Google

 FR-20: Login.Google.Option
The system shall provide an option for users to authenticate via Google.
  FR-21: Login.Google.Redirect
When the user selects the Google authentication option, the system shall redirect them to
Google’s authentication page.

 FR-22: Login.Google.Validation
The system shall validate the response from Google to ensure the user has successfully
authenticated.

 FR-23: Login.Google.AccountCreation
If the user authenticates via Google for the first time, the system shall create an account with
the basic information provided by Google.

 FR-24: Login.Google.Access
Upon successful authentication via Google, the user is granted access to the application.

5. Non-Functional Requirements
5.1 Usability
 NFR-1: The application shall be intuitive and easy to navigate, allowing new users to understand
the main features within the first 5 minutes of use.

 NFR-2: The design of the application shall be responsive, enabling a seamless experience across
various devices such as desktop, tablet, and mobile.

 NFR-3: The application shall follow accessibility guidelines (e.g., WCAG 2.1) to ensure it is usable
for individuals with disabilities, including keyboard navigation and screen reader compatibility.

5.2 Performance
 NFR-4: The system shall load the main dashboard within 2 seconds for 95% of user interactions.

 NFR-5: The application shall be able to handle up to 10,000 concurrent users without a
degradation in performance.

 NFR-6: Any search query shall return results within 1 second for up to 1,000 results.

 NFR-7: The application shall maintain consistent response times under varying network
conditions, including 4G, Wi-Fi, and LAN.

5.3 Interoperability
 NFR-8: The application shall be compatible with all major browsers, including Chrome, Firefox,
Safari, and Edge, for the latest and previous versions.

 NFR-9: The system shall support integration with third-party authentication providers, including
Google and Facebook.
  NFR-10: The application shall have an API that allows integration with other external systems,
such as CRM and analytics tools, via RESTful services.

5.4 Security
 NFR-11: The system shall require secure password criteria (minimum length, alphanumeric,
special characters) to ensure password strength.

 NFR-12: All user data shall be encrypted in transit using SSL/TLS protocols to prevent
unauthorized access.

 NFR-13: The application shall implement role-based access control (RBAC) to limit access to
sensitive data based on user roles.

 NFR-14: The system shall support multi-factor authentication (MFA) to enhance security during
login.

 NFR-15: The application shall log and monitor all user login attempts and provide alerts for any
suspicious activity, such as multiple failed login attempts.

5.5 Integrity
 NFR-16: The system shall automatically back up all data daily and maintain these backups for 30
days.

 NFR-17: Any modifications to user data shall be logged with the date, time, and user ID
responsible for the change.

 NFR-18: The system shall detect and prevent any attempts to manipulate stored data by
implementing checksums and data validation mechanisms.

6. External Interface Requirements

6.1 User Interface Requirements
 UIR-1: The application shall provide a consistent layout across all screens, with a header,
navigation menu, and footer for easy navigation.

 UIR-2: Buttons, icons, and text shall be large enough to be easily selectable on mobile devices
without zooming in.

 UIR-3: Error messages and form validation feedback shall be clearly visible and provide specific
guidance on how to correct errors.

 UIR-4: The color scheme shall provide sufficient contrast to enhance readability and
accommodate users with color vision deficiencies.
6.2 Software Interfaces
 SIR-1: The application shall connect to a MySQL database to store user and system data.

 SIR-2: The system shall support integration with Google APIs for authentication and map
services.

 SIR-3: The application shall communicate with a third-party payment gateway (e.g., PayPal,
Stripe) to handle transactions.

 SIR-4: An API shall be provided for third-party services to access specific data, like user profiles
and activity logs, via secure RESTful endpoints.

6.3 Hardware Interfaces

 HIR-1: The application server shall support a minimum of 16 GB RAM and 4 CPUs for optimal
performance.

 HIR-2: The application shall be compatible with smartphones, tablets, laptops, and desktops,
including devices running Windows, macOS, iOS, and Android.

 HIR-3: The system shall utilize hardware-based encryption, where available, to ensure data
security on physical devices.

6.4 Communications Interfaces

 CIR-1: The system shall communicate with users via email and SMS for notifications such as
registration confirmation, password reset, and account alerts.

 CIR-2: The application shall support both HTTP and HTTPS protocols, with HTTPS enforced for all
data transmission.

 CIR-3: WebSocket technology shall be used to enable real-time updates for certain features, like
live chat or real-time notifications.