Software Requirements Specification (SRS)

Glossary

A

Accessibility Marker A visual icon or symbol displayed on the map that indicates the presence of accessibility-related infrastructure such as ramps, slopes, or stairs.

Accessibility Overlay A graphical layer rendered on top of the base map that highlights accessibility-relevant features (e.g., obstacle pins, ramp locations, slope indicators).

Admin (Administrator) A privileged system role responsible for managing flagged content, deleting malicious reports, and suspending or banning abusive user accounts.

Asynchronous Push Notification A background-triggered alert sent to a user's device without requiring the user to be actively using the application at the time of delivery.

B

Badge A visual reward displayed on a user's profile, earned through community contributions (e.g., "Trusted Contributor").

Base Layer The foundational map layer showing standard geographic features such as roads, building footprints, and green areas, upon which accessibility overlays are rendered.

Blueprint The term used within the application to describe the static, pre-calculated route displayed to the user as a fixed visual guide — without real-time tracking or automatic re-routing.

Blue Dot A real-time moving location marker commonly used in navigation apps. This feature is explicitly not used in this system; users navigate manually.

C

Citizen Contributor A registered or unregistered user who reports accessibility obstacles, upvotes existing reports, or participates in the community validation process.

Closed The final status of an issue that has been resolved by the Infrastructure Authority and confirmed by a sufficient number of citizen votes. The warning marker is removed from the map.

Confirmed Obstacle (Verified) The status assigned to a report after it has received enough community upvotes to meet the Verification Threshold, indicating the obstacle is validated.

Crowdsourced Report An accessibility issue or obstacle submitted by a citizen user, including location data, category, photo evidence, and optional description.

D

Dashboard A shared management interface accessible by all Infrastructure Authority users for viewing, filtering, and acting on reported issues.

F

Flag A community moderation action where a user marks a report as inaccurate, fake, or misleading, signaling it for review.

Fixed Path / Fixed Route The single optimized route generated by the system that remains unchanged throughout the user's journey, regardless of deviations.

G

Gamification System A set of mechanisms (Trust Score, badges, contributor roles) designed to incentivize and reward active, reliable participation in the community.

Geospatial Map An interactive digital map displaying geographic data with coordinate-based overlays for obstacles, routes, and points of interest.

GPS (Global Positioning System) Satellite-based positioning technology used to automatically capture the user's location when submitting an obstacle report.

Graph (Routing Graph) The underlying data structure representing the street network as nodes (intersections) and edges (road segments), used by the routing engine to calculate paths.

Guest User The base user type. A user who can browse the map, view obstacle pins, request routes, set temporary routing preferences, and register for an account — all without logging in.

H

Hand Cart A wheeled cart used for carrying heavy loads. Included as a mobility aid type because users pushing hand carts require accessible, obstacle-free routes similar to wheelchair users.

High-Detail Threshold A predefined map zoom level at which Indoor Obstacle markers become visible to the user.

I

Indoor Obstacle An accessibility barrier located inside a building (e.g., lack of elevator, narrow doorway), displayed as a POI marker at high zoom levels. Indoor obstacles are excluded from route calculations.

Infrastructure Authority A municipal officer or government user role (inherits from Registered User) responsible for reviewing citizen reports, performing real-world repairs, uploading post-repair evidence, and updating issue statuses.

Interaction A user action performed on an existing obstacle report. Types include Upvote (confirm), Flag (mark as fake), and Confirm Resolution (validate a fix).

Issue Lifecycle / Report Lifecycle The sequence of status transitions a reported obstacle goes through: Reported → Unverified → Verified → Resolved – Awaiting Validation → Closed. Reports may also transition to Passive status if inactive.

M

Manual Navigation The navigation approach used in this system where the user follows the static route by visually matching street names and landmarks to their surroundings, without automated turn-by-turn guidance.

Mobility Profile A user-defined configuration specifying mobility constraints (e.g., wheelchair user, avoid stairs) that the system uses to customize route calculations.

MVP Scope The Minimum Viable Product coverage area, defined as Boğaziçi University North and South Campuses for the initial release.

N

Notification An asynchronous message sent to users affected by or involved with a reported obstacle. A single obstacle can trigger notifications to multiple users (many-to-many relationship).

O

Obstacle Category A predefined classification for reported issues, such as Road Construction, Damaged Surface, Blocked Path, Broken Ramp, Narrow Sidewalk, or Other.

Obstacle Pin / Obstacle Marker A map icon representing a reported accessibility issue at a specific geographic location.

Optimal Route The single best path calculated by the system based on the user's mobility constraints, avoiding steep slopes, stairs, narrow sidewalks, and active obstacles.

Outdoor / Indoor Context A required classification when submitting a report, determining whether the obstacle is on a street or sidewalk (Outdoor) or inside a building (Indoor).

P

Passive Report / Passive Status A report that has received no community interaction (upvotes or flags) within a predefined period. Passive reports are displayed with a semi-transparent style on the map and are excluded from route calculations. Users can toggle their visibility on or off.

POI (Point of Interest) Marker A map marker indicating a notable indoor location, such as a building with known accessibility issues.

Post-Repair Photo An official photograph uploaded by the Infrastructure Authority showing the completed fix, required before an issue status can be updated to "Resolved – Awaiting Validation."

Potential Spam An automatic flag applied to user accounts that submit a high volume of unverified reports in a short timeframe.

R

Registered User A user who has created an account (inherits from Guest User). Can report obstacles, upvote/flag reports, review resolutions, rate fixes, and build a Trust Score.

Re-routing (Automatic) The dynamic recalculation of a route in response to user movement or new obstacles. This feature is explicitly disabled in this system.

Report A user-submitted entry documenting an accessibility obstacle, containing GPS location, category, at least one photo, and optional text description.

Resolved – Awaiting Validation An intermediate issue status set by the Infrastructure Authority after a repair is completed, indicating the fix needs citizen confirmation before the marker is removed.

Route Calculation The process by which the system computes the optimal path between two points using the street network graph, factoring in mobility constraints and active obstacles.

S

Slope Calculation The analysis of terrain gradient data along potential route segments to avoid paths too steep for wheelchair users or users with mobility limitations.

Static Map / Static Visual Guide A non-interactive route display that does not update based on the user's real-time location, serving as a fixed reference for manual navigation.

Status Change A recorded transition between two report statuses, including timestamp, notes, and the user who initiated the change.

Stroller A baby carriage. Included as a mobility aid type because users pushing strollers require smooth, step-free, and obstacle-free routes.

T

Temporary Marker / Warning Marker A map indicator that appears immediately after a new obstacle is reported, visible to all users until the report is further verified or expires.

Trust Score A numerical value maintained for each registered user, incremented when their reports are verified by the community. Higher scores unlock the Trusted Contributor role.

Trusted Contributor A user role automatically granted when a user's Trust Score exceeds a defined threshold, resulting in a lower Verification Threshold for their future reports.

U

Unverified The initial status assigned to every new report submitted by a standard user, before any community interaction has occurred.

Upvote (Confirm) A community moderation action where a user validates another user's unverified report, contributing toward the Verification Threshold.

V

Validation Score A calculated metric based on citizen ratings of an Infrastructure Authority's repair, used to determine whether a resolved issue can be marked as "Closed."

Verification Engine The backend system component responsible for managing report lifecycle transitions, calculating trust scores, checking passive timeouts, computing validation scores, and detecting spam.

Verification Threshold The minimum number of community upvotes required for a report to transition from "Unverified" to "Verified." This threshold is lower for Trusted Contributors.

Visibility Filter A user-controlled toggle that shows or hides Passive Reports on the map interface.

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 registered user shall be able to enable or disable in-app notifications from their profile 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 render standard geographic base layers (e.g., roads, building footprints, green areas) to provide context for accessibility overlays.
• 1.2.1.2: The system shall hide Indoor Obstacle markers until the map zoom level exceeds the predefined "High-Detail" threshold.
• 1.2.1.3: 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 asynchronously create an in-app notification record for the original reporter when their report transitions to "Confirmed Obstacle" status
• 1.2.6.3: The system shall asynchronously create in-app notification records for the original reporter and all users who have upvoted the report when its status transitions to "Resolved – Awaiting Validation".
• 1.2.6.4: The system shall provide an authenticated endpoint for users to retrieve their notification list ordered by most recent first.

Non-Functional Requirements —

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.