Software Requirements Specification (SRS)

Glossary

1. Functional Requirements

1.1 User Profile & Preferences

• 1.1.1: The system shall allow users to define a mobility profile (e.g., wheelchair user) to customize route calculation.
• 1.1.2: The system shall allow users to manually input a starting point and a destination.
• 1.1.3: The system should allow users to save frequent locations for quick route generation.

1.2 Route Generation (The "Blueprint")

• 1.2.1: The system shall generate exactly one optimal route based on the user’s mobility constraints (slope, stairs, reported obstacles).
• 1.2.2: The system shall present the generated route as a static visual guide without the use of a real-time moving location marker (blue dot).
• 1.2.3: The system shall not perform automatic re-routing or path modification once the initial route is displayed.
• 1.2.4: The system shall highlight the chosen route in a bold, distinct visual format to assist manual navigation.

1.3 Obstacle Reporting (Citizen Contributor)

• 1.3.1: The system shall allow users to report obstacles by capturing the current GPS location automatically at the time of the report.
• 1.3.2: The system shall allow users to classify obstacles into predefined types (e.g., Road Construction, Damaged Surface, Blocked Path).
• 1.3.3: The system shall allow users to upload a photo as visual evidence of the reported obstacle.
• 1.3.4: The system shall display newly reported issues as temporary markers on the map for all other users.

1.4 Map Overlays & Visualization

• 1.4.1: The system shall render all relevant accessibility markers (ramps, slopes, stairs) as static overlays on the generated route.
• 1.4.2: The system shall display pre-reported obstacles from other users as icons on the map.
• 1.4.3: The system shall display street names and key landmarks on the static map to facilitate manual orientation.

1.5 Municipal Maintenance & Resolution

• 1.5.1: The system shall provide a dashboard for municipal officers to view all citizen-reported issues on a map.
• 1.5.2: The system shall allow municipal officers to change the status of an issue to “Resolved – Awaiting Validation.”
• 1.5.3: The system shall require the officer to upload an official post-repair photo as proof before updating the status.
• 1.5.4: The system shall allow citizens to rate/validate the accuracy of the municipality’s fix based on the uploaded photo.
• 1.5.5: The system shall mark the issue as “Confirmed Resolved” and remove the warning marker only after the validation score meets a defined threshold.

2. Non-Functional Requirements