Requirements & Specifications - snuhcs-course/swpp-2026-project-team-16 GitHub Wiki

Requirements & Specifications

1. Document Revision History

Version Date Key Changes Author
v0.1.0 2026-09-29 Initial draft for Iteration 1 SoonYoung Park
v0.1.1 2026-09-30 Scope Management Changes & Functional Requirements Part SoonYoung Park
v0.1.2 2026-10-06 Updated backend stack (Django), routing module (TMAP Pedestrian API), and GeoJSON standard alignment SoonYoung Park
v0.1.3 2026-10-09 Updated In-Scope MVP features (Point-to-Point, POI Search, Bilingual UI) and latency specs SoonYoung Park

2. Project Abstract

RunTime is an AI-driven running route generator for urban runners. Standard navigation tools often fail to create returning loop routes and prioritize main roads with frequent traffic lights, while fitness heatmaps ignore micro-conditions. RunTime solves this via a pragmatic hybrid pipeline: combining geometric waypoint sampling with commercial pedestrian routing APIs (TMAP Pedestrian API) for guaranteed returning loops and point-to-point routes (within ±10% distance error), parsing elevation profiles and traffic signals via Open-Elevation and OpenStreetMap data, outputting geometry in GeoJSON (RFC 7946) standard, and utilizing LLMs (Gemini) to deliver personalized pre-run briefings.


3. Target Customer

  • Urban Runners: Runners who want to maintain a consistent pace without frequent stops from traffic lights, pedestrian crossings, or steep inclines.
  • Travelers & Neighborhood Visitors: Runners in unfamiliar areas who need safe running routes (loops or point-to-point) starting directly from their current location.

4. Scope Management

In-Scope (Iteration 1 MVP) Next Iterations Scope Out-of-Scope
• Route generation based on user input (Start point, optional End point, distance) • Real-time elevation profile rendering on map • Real-time GPS tracking during workout
• TMAP POI Place Search for start/end points • Route sharing with other users • Preferred path selection (e.g., parks, greenways)
• AI LLM (Gemini) pre-run briefing about generated route • Writing reviews for saved/community routes
• Ability to save & store routes per user in app • Signal count management
• Ability to delete saved routes • Offline job support
• Bilingual UI support (Korean & English)

5. Competitive Landscape

Feature Standard Maps (Kakao/Naver) Fitness Heatmaps (Garmin/NRC) RunTime (Ours)
Point-A-to-Point-A Returning Loop X O O
Guaranteed Real-world Walkability O X O
Signal/Crosswalk Obstacle Avoidance X X O
Elevation Gain Profile & Caching X Partial O
LLM Personalized Pace Briefing X X O

6. Functional Requirements

1. User Stories

We defined our core user stories using the Connextra format (As a <role>, I want to <capability>, so that <benefit>) based on our MVP scope.

  • User 1 (Loop & Point-to-Point Route Generation with Briefing): As a traveling runner who is unfamiliar with local routes, I want to request a loop route or point-to-point route of my target distance with an LLM briefing, so that I can complete a smooth run at a steady pace.

  • User 2 (Place Search & Language Preference): As an international or local urban runner, I want to search for starting/ending points by place name and switch the app language (Korean/English), so that I can easily plan my run regardless of language barriers.

  • User 3 (Route Management - Save & Delete): As a runner managing my routes, I want to save a generated route to my personal list and delete routes that I no longer need, so that I can easily run good routes again and keep my saved list clean.


2. User Acceptance Criteria

  • Acceptance 1 (for User 1 - Route Generation & Briefing):

    • Given the user sets a starting location (and optional end location) and inputs a target distance (in km),
    • When the user taps the "Generate" button,
    • Then the app displays a route matching the parameters within a ±10% distance margin, along with an LLM-generated pre-run briefing.
    • And if distance parameters trigger fallback shortest path logic, a clear notice (is_shortest_path) is provided to the user.
  • Acceptance 2 (for User 2 - Place Search & Bilingual UI):

    • Given the user types a location keyword in the search bar,
    • When the search request is sent,
    • Then top TMAP POI search results are returned and displayed.
    • And when the language toggle button is tapped, the entire UI and briefings switch between Korean and English.
  • Acceptance 3 (for User 3 - Route Save & Delete Management):

    • Given the user is viewing a generated route,
    • When the user taps the "Save" button,
    • Then the route is stored in their saved route list on My Page.
    • Given the user is viewing their list of saved routes in My Page,
    • When the user selects a route and taps "Delete",
    • Then the route is removed from the saved list.

7. Non-functional Requirements

  • Response Latency: Candidate route generation and LLM briefings should typically complete within 10 seconds. For fresh map data requests from public map servers, a maximum server timeout limit of 35 seconds is enforced with an appropriate fallback notice (HTTP 503).
  • Accuracy: Generated loop routes must stay within a ±10% margin of error relative to the user-requested distance.
  • Reliability: TMAP Pedestrian Routing API combined with geometric waypoint fallback guarantees 100% real-world walkable paths.

8. User Interface Requirements (Wireframe)

IMG_4031
  • Home Input Page: Location input/POI search, optional end point, distance slider/input, language toggle button.
  • Route Result Page: Canvas/Map view displaying generated coordinates, distance summary, shortest path notice, and LLM pre-run briefing box.
  • My Page: List of saved user routes with detail view, delete functionality, and user profile information.
⚠️ **GitHub.com Fallback** ⚠️