Ridesharing App 1. Objective Build a lightweight ridesharing mobile app that supports: 1. Passenger-first shared trip (A→B created by first passenger) 2. Driver-first trip listing (driver publishes A→B) 3. On-demand private ride (taxi-style) Users must choose role during signup: • Passenger • Driver Roles remain separate after signup (no mixed UI). ________________________________________ 2. User Roles & Access Control 2.1 Roles • Passenger • Driver User must select role during signup. Role determines available features and screens. Acceptance Criteria • On first launch, user sees role selection: “Register as Passenger” or “Register as Driver”. • After signup, only role-specific dashboard is shown. • Passenger cannot access driver screens. • Driver cannot access passenger booking screens. • Role is stored permanently in user profile. ________________________________________ 3. Signup & Authentication Flow 3.1 Signup Steps 1. Enter phone number 2. Verify OTP 3. Enter name 4. Select gender 5. Select role (Passenger / Driver) If Driver selected: • Upload vehicle details • Upload license Acceptance Criteria • OTP verification required before proceeding. • Gender selection mandatory (MALE / FEMALE). • Role selection mandatory before account creation. • Driver must upload: o Vehicle type o Plate number o License image o Year • Passenger signup does not require vehicle details. ________________________________________ 4. Core Modes Supported 4.1 Passenger-First Shared Trip Passenger creates route A→B and other passengers join along the path. 4.2 Driver-First Trip Listing Driver publishes route A→B with seats and fare; passengers join. 4.3 On-Demand Private Ride Passenger requests ride; nearest driver is matched. ________________________________________ 5. Core Data Models 5.1 User Fields: • id • name • phone • gender • role (PASSENGER | DRIVER) • rating Acceptance Criteria • Role stored and immutable after signup (unless admin changes). • Gender must be used for filtering rides. ________________________________________ 5.2 Trip Fields: • tripId • mode (PASSENGER_FIRST | DRIVER_FIRST | ON_DEMAND) • origin (lat,lng) • destination (lat,lng) • routePath (polyline) • baseFare • seatsTotal • seatsAvailable • genderPreference • driverId (nullable) • passengers list • status (OPEN | MATCHING | CONFIRMED | STARTED | COMPLETED) Acceptance Criteria • Trip must store route path. • Seats-available decreases when passenger joins. • Trip status updates in correct lifecycle order. ________________________________________ 5.3 Passenger Segment Fields: • userId • pickup • dropoff • calculatedFare Acceptance Criteria • Fare must be calculated proportional to traveled segment. • Each passenger record linked to a trip. • For security purposes, the Photo of passenger and driver should be shared upon joining. ________________________________________ 6. Passenger Features 6.1 Create Shared Trip (Passenger-First) Passenger inputs: • Departure (A) • Destination (B) • Gender preference (optional) System creates trip with mode PASSENGER_FIRST. Acceptance Criteria • Trip appears publicly in “Available Trips”. • Seats default = 4 (configurable). • DriverId remains null until driver accepts. • After Trip Confirmation (joined), Passenger Can See: Driver photo, Driver first name, Vehicle model, Plate number, Driver rating, In-app Call button, In-app Chat, NOT real phone number plus passengers also can see each others’ photo after joining. ________________________________________ 6.2 Join Existing Trip Passenger enters: • Pickup location • Dropoff location System validates: • Locations lie along route corridor • Direction matches trip • Gender preference satisfied Acceptance Criteria • Passenger can join only if route overlap exists. • System shows calculated fare before join. • After join, seatsAvailable decreases. • After Trip Confirmation (joined), Passenger Can See: Driver photo, Driver first name, Vehicle model, Plate number, Driver rating, In-app Call button, In-app Chat, NOT real phone number plus passengers also can see each others’ photo after joining. ________________________________________ 6.3 On-Demand Ride Request Passenger enters pickup + destination. System: • Finds nearest available driver • Sends request • Creates ON_DEMAND trip Acceptance Criteria • Nearest driver determined by distance sorting. • Passenger sees driver details once accepted (photo & phone number). • Only one passenger per ON_DEMAND trip. ________________________________________ 7. Driver Features 7.1 Publish Route Trip (Driver-First) Driver inputs: • Origin • Destination • Seats • Base fare • Gender preference Trip created with mode DRIVER_FIRST. Acceptance Criteria • For both, drivers & passengers, the trip becomes visible to passengers searching along route & at custom radius. • Driver can edit or cancel before confirmation. ________________________________________ 7.2 Accept Passenger-First Trips Driver sees list of open passenger-created routes and can accept one. Acceptance Criteria • Once driver accepts, driverId assigned to trip. • Trip status changes to CONFIRMED. ________________________________________ 7.3 Accept On-Demand Ride Driver receives nearby ride requests sorted by proximity. Acceptance Criteria • Driver must accept within timeout. • If accepted, trip created with driver assigned. ________________________________________ 8. Matching & Route Logic 8.1 Route Corridor Matching Passenger pickup and drop-off must lie within configurable radius (e.g., 1km) of trip route line. This could be customized by both, passengers and drivers. Acceptance Criteria • If pickup or dropoff outside corridor → join rejected. • System must not require heavy map SDK. ________________________________________ 8.2 Direction Matching Passenger travel direction must align with trip direction. Acceptance Criteria • Angle between vectors < 45° allowed. • Opposite direction requests rejected. ________________________________________ 9. Fare Calculation Rules Fare is proportional to passenger segment distance. Formula: fare = baseFare × (segmentDistance / totalRouteDistance) Acceptance Criteria • Fare displayed before join confirmation. • Fare recalculated if route changes. • Full route passenger pays full baseFare. ________________________________________ 10. Sorting Logic Available vehicles and trips must be sorted by proximity to passenger pickup. Acceptance Criteria • Distance computed using Haversine formula. • Closest trips appear first in list. ________________________________________ 11. Gender Preference Enforcement Trips may define allowed gender. Acceptance Criteria • Passenger cannot join trip if gender not allowed. • Gender filtering applied during search and join. ________________________________________ 12. Trip Lifecycle States States: OPEN → MATCHING → CONFIRMED → STARTED → COMPLETED Acceptance Criteria • State transitions must follow strict order. • STARTED only when driver begins trip. • COMPLETED only after final drop-off. ________________________________________ 13. UI/UX Screens Passenger App 1. Role-based dashboard 2. Create Shared Trip 3. Available Trips List (sorted by proximity) 4. Join Trip Preview (shows dynamic fare) 5. Request Private Ride 6. Active Trip Tracking 7. Trip History Driver App 1. Driver dashboard 2. Publish Route Trip 3. Incoming Passenger-First Trip Requests 4. On-Demand Ride Requests 5. Active Trip Navigation 6. Earnings & Trip History Acceptance Criteria • Passenger UI must not show driver-only options. • Driver UI must not show passenger booking options. ________________________________________ 14. Notifications System must send: • New passenger joined • Driver assigned • Trip confirmed • Trip started • Trip completed Acceptance Criteria • Push notifications triggered on every state change. • Users receive only relevant role-based notifications. ________________________________________ 15. Edge Case Handling Case: Passenger outside route → Show “No matching shared trips found”. Case: Seats full → Join button disabled. Case: No driver for passenger-first trip → Trip remains open until accepted. Acceptance Criteria • System must gracefully handle all edge scenarios. • No crashes or inconsistent states allowed. ________________________________________ 16. Performance Requirements • Lightweight architecture • Minimal external SDK usage • Efficient matching logic Acceptance Criteria • Trip search response < 2 seconds. • Matching logic must run server-side. • App must support low-bandwidth environments. ________________________________________ 17. Final Mandatory Requirements 1. Role selection during signup is required. 2. Roles remain separate with independent dashboards. 3. App supports three ride modes simultaneously. 4. Shared trip joining must use route corridor + direction matching. 5. Fare must be dynamically calculated per passenger segment. 6. Trips must be sorted by proximity to passenger. 7. Gender preference filtering must be enforced. ________________________________________ 18. Definition of Done (Global Acceptance Criteria) The feature is complete when: • Users can signup with role selection. • Passenger can create shared trip A→B. • Other passengers along route can join with correct fare. • Drivers can publish trips and accept shared routes. • On-demand rides match nearest driver successfully. • All flows enforce gender preference, seat limits, and route matching. • Trips transition correctly through lifecycle states. • Passenger and Driver apps remain fully separated after signup. • Other features will be added & necessary changes will be made to the above feature upon client initiation.