Software Requirements Specification (SRS)

Glossary

1. Functional Requirements

1.1 User Requirements

(This section defines what the users can do, initiate, or are required to provide.)

1.1.1 Registration & Authentication

• 1.1.1.1: An unregistered user (Guest) shall be able to browse the map interface without creating an account.
• 1.1.1.2: An unregistered user shall be able to view existing obstacle pins on the map.
• 1.1.1.3: A user shall be able to register a new account using a valid email address, full name, and birth date.
• 1.1.1.4: A user shall be required to define a secure password during registration.
• 1.1.1.5: A registered user shall be able to securely log in to their account using their email and password.
• 1.1.1.6: A registered user shall be able to log out of the system.
• 1.1.1.7: A registered user shall be able to request a password reset link via email.

1.1.2 Profile & Accessibility Preferences

• 1.1.2.1: A registered user shall be able to create a permanent "Mobility Profile" associated with their account.
• 1.1.2.2: A registered user shall be able to select their primary mobility aid (e.g., “Wheelchair”) from predefined categories.
• 1.1.2.3: An unregistered user shall be able to set temporary routing preferences (e.g., "Avoid Stairs") for a single session.
• 1.1.2.4: A registered user shall be able to save frequent destinations (e.g., "Home", "Work") to their profile.
• 1.1.2.5: A registered user shall be able to view their earned badges (e.g., Trusted Contributor) on their profile page.
• 1.1.2.6: A user shall be able to toggle system notifications (on/off) from their settings.

1.1.3 Map Interaction & Discovery

• 1.1.3.1: A user shall be able to pan and browse the interactive map freely.
• 1.1.3.2: A user shall be able to zoom in and out of the map interface.
• 1.1.3.3: A user shall be able to click on an obstacle marker to view its detailed description and photos.
• 1.1.3.4: A user shall be able to view Indoor Obstacles (POI markers) when examining a specific building at high zoom levels.
• 1.1.3.5: A user shall be able to toggle a visibility filter to show or hide "Passive Reports" (stale/unverified issues).
• 1.1.3.6: A user shall be able to search for a specific location using text input (e.g., address, building name).
• 1.1.3.7: A user shall be able to manually select a location by dropping a pin on the map.

1.1.4 Route Planning

• 1.1.4.1: A user shall be able to manually select a starting geographic point.
• 1.1.4.2: A user shall be able to manually select a destination point.
• 1.1.4.3: A user shall be able to request a route calculation.
• 1.1.4.4: A user shall be able to view the generated route strictly as a static visual path (Blueprint).
• 1.1.4.5: A user shall be able to view a textual summary of the route (Total Distance, Estimated Time).

1.1.5 Obstacle Reporting

• 1.1.5.1: A user shall be able to initiate a new obstacle report at their current GPS location.
• 1.1.5.2: A user shall be required to categorize the report context as either "Outdoor" or "Indoor".
• 1.1.5.3: A user shall be able to optionally select an obstacle category (e.g., Broken Ramp, Narrow Sidewalk).
• 1.1.5.4: A user shall be required to upload at least one photograph as evidence of the obstacle.
• 1.1.5.5: A user shall be able to add a text description to the report.

1.1.6 Verification & Community Moderation

• 1.1.6.1: A user shall be able to "Upvote" (Confirm) an unverified report submitted by another user.
• 1.1.6.2: A user shall be able to "Flag" a report as inaccurate or fake.
• 1.1.6.3: A user shall be able to propose a solution by uploading a "Resolved" photo for an existing obstacle.
• 1.1.6.4: A user shall be able to view the status timeline of an issue (Reported -> Resolved -> Validating -> Confirmed).

1.1.7 Infrastructure Authority Operations

• 1.1.7.1: An Infrastructure Authority user shall be able to access a dedicated dashboard for issue management.
• 1.1.7.2: An Infrastructure Authority shall be able to filter reports by status (Open, Awaiting Validation, Resolved).
• 1.1.7.3: An Infrastructure Authority shall be able to mark an issue as "Resolved – Awaiting Validation".
• 1.1.7.4: An Infrastructure Authority shall be required to upload a post-repair verification photo to update the status.
• 1.1.7.5: An Infrastructure Authority shall be able to append official repair notes to the issue.

1.1.8 Administrator Operations

• 1.1.8.1: An Admin user shall be able to view a system-wide queue of reports flagged as malicious by the community.
• 1.1.8.2: An Admin user shall be able to permanently delete malicious reports and remove them from the database.
• 1.1.8.3: An Admin user shall be able to suspend or ban user accounts that exhibit abusive behavior.

1.2 System Requirements

(This section defines what the system does in the background, rules, and algorithms.)

1.2.1 General Visualization & User Interface

• 1.2.1.1: The system shall display an interactive geospatial map covering the MVP Scope (Boğaziçi University North/South Campuses) as the default interface upon launch.
• 1.2.1.2: The system shall render standard geographic base layers (e.g., roads, building footprints, green areas) to provide context for accessibility overlays.
• 1.2.1.3: The system shall hide Indoor Obstacle markers until the map zoom level exceeds the predefined "High-Detail" threshold.
• 1.2.1.4: The system shall render "Passive" reports with a distinct, semi-transparent visual style on the map to differentiate them from active issues.

1.2.2 Routing Engine Logic

• 1.2.2.1: The system shall calculate routes using a graph based on outdoor street networks.
• 1.2.2.2: The system shall exclude all reports categorized as "Indoor" from the route calculation graph.
• 1.2.2.3: The system shall exclude reports with "Passive" status from the route calculation graph.
• 1.2.2.4: The system shall generate routes up to the building entrance of the selected destination.

1.2.3 Report Lifecycle & State Management

• 1.2.3.1: The system shall assign an initial status of "Unverified" to all new reports submitted by standard users.
• 1.2.3.2: The system shall automatically change a report's status to "Passive" if it receives no interactions (upvotes/flags) for a predefined period.
• 1.2.3.3: The system shall automatically change a report's status to "Confirmed Obstacle" once the upvote count reaches the Verification Threshold.

1.2.4 Resolution & Validation Workflow

• 1.2.4.1: When an Infrastructure Authority marks an issue as "Resolved", the system shall not immediately remove the marker.
• 1.2.4.2: The system shall update the issue status to "Resolved – Awaiting Validation".
• 1.2.4.3: The system shall trigger a notification to the original reporter of the issue.
• 1.2.4.4: The system shall trigger a notification to users who previously upvoted the issue.
• 1.2.4.5: The system shall require a specific number of "Confirm Resolution" votes from citizens to transition the status to "Closed/Archived".

1.2.5 Trust & Gamification System

• 1.2.5.1: The system shall maintain a "Trust Score" for each registered user.
• 1.2.5.2: The system shall increment a user's Trust Score when their submitted report is verified by the community.
• 1.2.5.3: The system shall not increment Trust Scores for reports submitted by Unregistered (Guest) users.
• 1.2.5.4: The system shall grant the "Trusted Contributor" role to users whose Trust Score exceeds the defined threshold.
• 1.2.5.5: The system shall assign a lower Verification Threshold to reports submitted by Trusted Contributors.

1.2.6 Data Moderation & Alerts

• 1.2.6.1: The system shall automatically flag user accounts that submit a high volume of unverified reports within a short timeframe as "Potential Spam".
• 1.2.6.2: The system shall trigger an asynchronous push notification to the original reporter when their report achieves "Confirmed Obstacle" status.
• 1.2.6.3: The system shall trigger an asynchronous push notification to the original reporter and upvoters when the issue is marked as "Resolved" by an Infrastructure Authority.

Non-Functional Requirements — Neighborhood Accessibility Mapper

1. Availability

• NFR-1.1 The system shall be available and functional as a web application.
• NFR-1.2 The system shall be available and functional as a mobile application.

2. Performance

• NFR-2.1 The system shall render map data and accessibility markers without perceptible delay during normal usage.
• NFR-2.2 The system shall compute accessible routes within a reasonable time frame regardless of route complexity.
• NFR-2.3 The system shall handle concurrent users without degradation in response time.

3. Reliability

• NFR-3.1 The system shall not lose user-submitted accessibility reports due to internal failures.
• NFR-3.2 The system shall validate all user-submitted data before displaying it on the public map.
• NFR-3.3 The system's routing algorithm shall prioritize verified accessibility data over unverified crowdsourced reports.
• NFR-3.4 The system shall recover from unexpected failures without requiring manual intervention.

4. Usability

• NFR-4.1 The system shall conform to WCAG 2.1 Level AA accessibility standards.
• NFR-4.2 The system shall be usable on both desktop and mobile screen sizes.
• NFR-4.3 The system shall be operable using screen readers on all supported platforms.
• NFR-4.4 The system shall allow a first-time user to submit a report without prior training.

5. Security

• NFR-5.1 The system shall authenticate users before allowing issue submission or data modification.
• NFR-5.2 The system shall transmit all data over encrypted connections.
• NFR-5.3 The system shall enforce role-based access control to separate citizen, municipality officer, and administrator privileges.

6. Privacy

• NFR-6.1 The system shall require explicit user permission to access device location services.
• NFR-6.2 The system shall not expose personally identifiable information of users who report accessibility issues.

7. Portability

• NFR-7.1 The web application shall function correctly on all major modern browsers.
• NFR-7.2 The mobile application shall support current and recent versions of iOS and Android.

8. Scalability

• NFR-8.1 The system shall support multiple municipalities without degradation in functionality.
• NFR-8.2 The system shall accommodate a growing number of accessibility reports and users over time.