Skip to content

Software Requirements Specification (SRS-Lite)

1. Purpose

This document defines a lightweight set of software requirements for the MVP version of the Travel App. It outlines the functional and non-functional requirements to help the development team implement features aligned with the business goals.

2. Scope

The system is a web-based platform that allows users to browse travel packages, customize itineraries, view maps/routes, and select hotels. The backend will be managed by the Admin using Django Admin.

3. Definitions

Term Description
Itinerary A personalized version of a travel package
Package A general travel blueprint/template
Admin Internal software team managing the app
User Refers to travelers, agencies, or hotels

4. System Overview

The system has the following components:

  • Frontend: Next.js + Tailwind CSS
  • Backend: Django with PostgreSQL
  • Design: Figma for UI/UX
  • Documentation: MkDocs + PlantUML (PUML) + Cloudflare Pages

5. Functional Requirements

5.1 User Roles & Authentication

  • Users must register and log in using email or Google.
  • Agencies and Hotels require admin approval.
  • Role-based access control
  • Passwords must be hashed and meet complexity requirements.
  • Users can reset passwords via email verification.

5.2 Packages

  • Display popular packages by default on homepage.
  • Users can filter packages (days, people, preferences).
  • Users can fork a package into a custom itinerary.
  • Group itineraries can be created by agencies.
  • Save itineraries to user profile.

5.3 Itineraries

  • Itineraries are personal and can be fully customizable.
  • Should support detailed view.
  • Users can save, edit, and delete itineraries from their profile.
  • Itineraries include daily schedules with timestamps and locations.

5.4 Maps & Routes

  • Users can view travel routes via map based on their itinerary.
  • Standalone route view for casual browsing.
  • Routes include estimated travel times and distances.

5.5 Hotels

  • Hotel details include name, address, star rating, and amenities
  • Hotels are assigned manually by Admin (for MVP).
  • Users can select hotel options within itinerary creation flow.

5.6 Admin Dashboard

  • Admin can manage users using Django Admin..
  • Admin can create/edit/delete packages, itineraries, and hotel listings.

  • Admin can view all user generated itineraries.

5.7 Feedback

  • Users can submit feedback like rating, comments.

6. Non-Functional Requirements

Area Requirement
Performance Initial response time < 2s
Scalability Should support 10,000+ users (post-MVP)
Security OAuth2 (Google) + secure password handling
Maintainability Modular and well-documented codebase
Accessibility Web responsive; mobile-friendly

7. Constraints

  • All management features must use Django Admin in MVP.
  • Limited third-party APIs (Google Maps allowed).
  • No real payment or booking APIs in MVP.

8. System Diagrams

8.1 User Role & Flow (PlantUML)

TravelerAgencyHotelAdminBrowse PackagesCustomize ItineraryView MapSelect HotelsCreate Group ItineraryRequest ApprovalApprove UsersManage PackagesManage HotelsView All Itineraries
TravelerAgencyHotelAdminBrowse PackagesCustomize ItineraryView MapSelect HotelsCreate Group ItineraryRequest ApprovalApprove UsersManage PackagesManage HotelsView All Itineraries

9. Future Considerations

  • Payment gateway integration
  • In-app notifications
  • Role-based dashboards
  • CMS for admin beyond Django

This is a living document and should be reviewed and updated as features evolve.