-
Notifications
You must be signed in to change notification settings - Fork 0
Elicitation Questions Neighborhood Accessibility Mapper
Bora Aydemir edited this page Feb 24, 2026
·
3 revisions
- Q1: Beyond wheelchair users, should the system specifically cater to other groups such as parents with strollers, elderly individuals with walkers, or visually impaired users? If so, how do the priority features differ for each group?
- Q2: Will there be different user roles in the system? For example, do we need a separate interface for "Expert Contributors" (e.g., NGO members) versus "Casual Users"?
- Q3: Should businesses (e.g., cafes, shops) have a special account type to update their own accessibility status, or will all data be strictly crowdsourced from the public?
- Q4: Regarding "accessibility features," how granular should the data be? Is a binary "Accessible/Not Accessible" tag sufficient, or does the system need detailed attributes like "Ramp width," "Door opening mechanism," or "Slope percentage"?
- Q5: How should the routing algorithm handle "unknown" or "missing" data? Should the system suggest a route that might be accessible but isn't verified, or only strictly verified paths?
- Q6: Is "Real-time Navigation" (turn-by-turn voice guidance) a must-have for the MVP (Minimum Viable Product), or is "Pre-trip Planning" (showing the map and route overview) the primary goal?
- Q7: How should the system handle temporary obstacles (e.g., construction work, broken elevators, parked cars on sidewalks)? Do these need a "time-to-live" (expiration duration)?
- Q8: To ensure data reliability, should we implement a "Trust Score" or "Reputation System" for contributors? (e.g., A new user's edit requires approval, while a trusted user's edit goes live immediately).
- Q9: What is the primary incentive for users to contribute data? Should we include gamification elements (badges, leaderboards, points) to encourage participation?
- Q10: When a user reports an issue (e.g., "Steep Slope"), should they be required to upload a photo as proof, or is text description sufficient?
- Q11: Considering the target audience might have motor impairments, are there specific interface constraints? (e.g., High contrast mode, large buttons, voice command support).
- Q12: Given that internet connection might be unstable outdoors, is Offline Mode (caching maps and routes) a critical requirement? If yes, should users be able to download specific neighborhoods?
- Q13: Regarding image uploads, is the system required to automatically blur faces and license plates to comply with privacy regulations (KVKK/GDPR), or is manual moderation preferred?
- Q14: Should the system allow users to create "Private Routes" (e.g., Home to Work) that are not shared with the public database?
- Q15: For the MVP (Minimum Viable Product), what is the geographical scope? Are we targeting a specific campus (e.g., Boğaziçi University), a single neighborhood (e.g., Hisarüstü), or the entire city?
- Q16: Should the system handle multi-floor mapping (e.g., inside shopping malls or metro stations), or is it strictly limited to outdoor street-level accessibility?
- Q17: Regarding the reporting interface: Should users manually drop a pin on the map to mark an obstacle, or should the system automatically capture their GPS coordinates when they take a photo?
- Q18: Will the map interface allow users to "draw" accessible routes (e.g., highlighting a safe path on a sidewalk), or is the data limited to specific point-based markers (POIs)?
- Q19: Since accessibility issues often require fixing by local authorities, should the system generate automated reports or "Heat Maps" that can be sent to municipalities (e.g., "This street has 5 reported broken ramps")?
- Q20: Is there a plan to integrate with existing city data (e.g., Istanbul Metropolitan Municipality's open data portal) to import existing bus stop or sidewalk data?
- Elicitation Questions
- Requirements
- Implementation Plan
- Test Plan & Coverage
- MVP Demo Plan
- Communication Plan
- Responsibility Assignment Matrix
- Use of Standards
- Project Retrospective
- Final Demo Plan
- Final Milestone Deliverables
- Report 1 - Requirements Elicitation & Repository Setup
- Report 2 - SRS Through Scenarios & Mock-ups
- Report 3 - From Scenarios to Use Case Diagrams
- Report 4 - Class Diagrams & Use-case Diagrams
- Report 5 - Git Workflow, Stub Application, and Planning
- Report 6 - Planning for Implementations & Tests
- Report 7 - Finalizing Plan for MVP Milestone Demo
- Report 8 - Standards & Plan Revision
- Report 9 - Requirements Review & Acceptance Testing
- Report 10 - Finalizing Plan for Final Milestone Demo
- 2026-02-18: Weekly Meeting #1
- 2026-02-18: Customer Meeting #1
- 2026-02-25: Stakeholder Meeting
- 2026-02-25: Weekly Meeting #2
- 2026-03-04: Weekly Meeting #3
- 2026-03-11: Weekly Meeting #4
- 2026-04-01: Weekly Meeting #5
- 2026-04-15: Weekly Meeting #6
- 2026-04-22: Weekly Meeting #7
- 2026-04-29: Weekly Meeting #8
- 2026-05-06: Weekly Meeting #9