Customer Meeting #1 Report

Customer Meeting #1 Report

Date: February 18, 2026
Duration: 30 Minutes
Topic: Initial Requirement Elicitation & Project Discovery
Status: Draft / Review Required

---

1. Description

This was an initial elicitation meeting focused on project discovery and understanding the core requirements. The primary objective was to define the system's functional boundaries, identify the target audience, and differentiate between MVP (Must-Have) features and future iterations (Nice-to-Have).

---

2. Attendance

• Arda Arslan (Customer)
• Ali Akkaya
• Arif Evren
• Baran Önder
• Bora Aydemir
• Ekin Kılıç
• Ömer Belemir Delier
• Ulaş Sertan Kemeç

---

3. Agenda & Discussion Points (Q&A)

Target Audience & Scope

• Q: Who are the primary users of the application? A: The app targets individuals with orthopedic impairments, people with limited physical stamina, the elderly, and those with walking disabilities (including their relatives/caregivers). Additionally, Infrastructure Authorities (such as municipalities and relevant institutions) are key users who can track issues and report solutions. Voluntary contributors who report obstacles also form a vital part of the user base.
• Q: What is the geographical and environmental scope? A: There are no strict geographical limits, but the MVP will utilize real-world data from campus environments (North-South campus). The system should treat Indoor (e.g., public buildings like the BM building) and Outdoor environments equally without distinction.
• Q: Should the maps be visually represented? A: Yes, a visual map is a Must-Have, though turn-by-turn navigation (e.g., "turn right in 50m") is not required for the initial phase.

Routing Mechanism

• Q: How should the routing algorithm prioritize paths? A: The primary metric is the Accessibility Level rather than the shortest time. The MVP will provide a single "Default Route" with minimum obstacles. Google APIs can be utilized for map data.
• Q: Can users customize or categorize their routes? A: For the MVP, one default route is sufficient. Future versions (Nice-to-Have) should allow users to categorize routes based on specific disabilities and toggle categories on/off.

Reporting & Verification

• Q: What kind of obstacles can be reported and what data is required? A: There are no limits; any issue like road collapses or narrow pavements can be reported. Users should be able to upload photos of the incident. While the system provides predefined categories (e.g., steep slope, narrow sidewalk), users must be able to add new problem categories.
• Q: How will the accuracy of reports be verified? A: Verification will rely on user interaction (likes/upvotes) and feedback from those using the route. High comment volume and upvotes will serve as validation.
• Q: How should "Solved" problems be handled? A: Users can provide proof (images) that a problem is resolved. This moves the report to a "Solved" category once positive feedback is received. Verification for low-traffic routes or infrastructure authority claims (e.g., "the municipality fixed it") will require a specific threshold of user feedback to be finalized.

Roles & Access Control

• Q: What are the user roles and their respective permissions? A: * Unregistered User: Can view routes and upvote reports without authentication.
  • Authenticated User/Contributor: Required for adding new reports or categories.
  • Infrastructure Authorities: Special accounts for municipalities/institutions to comment on solutions (Nice-to-Have).
  • Admin: Responsible for reviewing malicious users (those with many posts but no feedback) and managing data.

Gamification & Trust

• Q: Are motivational features like scores or leaderboards necessary? A: The system expects voluntary participation. A leaderboard is not required, but tracking and displaying the number of reports a user has submitted is a Must-Have.
• Q: How does the trust mechanism work for comments? A: A trust mechanism via user levels and badges (e.g., Elite User) can be implemented. Approvals from these users may carry enough weight to verify a report independently.

Implementation & Maintenance

• Q: Are real-time updates required for routing? A: No, real-time checks are unnecessary. Routing should be generated based on existing reports in the database at the time of request.
• Q: When should implementation begin? A: Implementation can start gradually, but the current focus remains on finalized system requirements.

---

4. Feature Priority Matrix

Category	Requirement (Must Have)	Nice to Have / Future
Route	Default accessibility-based route, Visual map display	Personalized routes by disability, Conditioned routing
Reporting	Photo support, Predefined/Custom categories, Upvotes/Comments	Direct municipality integration, User notification for fixes
Users	Report counts, User Levels (Elite/Badges), Unregistered upvoting	Malicious user notification for Admins
Scope	Indoor & Outdoor parity, Real campus data	Global geographical expansion

---

5. Action Items (Must-Haves)

• Accessibility Routing: Develop a routing mechanism that prioritizes the "Minimum Accessibility Obstacle" path.
• Reporting System: Build a reporting interface that supports photo uploads, commenting, and user-defined categories.
• Verification Loop: Implement an upvote/feedback system to validate active reports and "solved" statuses.
• User Identity: Establish a basic user level/badge system based on report counts to build a trust hierarchy.
• Data Seeding: Manually collect a minimal dataset of real obstacles (stairs, slopes) within the campus for the MVP demo.

---

Key Stakeholder Note: Maintaining continuous communication with Ms. Özlem is critical for refining specific requirement thresholds.