U-KRATER System Requirements Document

1. Introduction

The U-KRATER project is designed to provide a platform where users can share and view real-time alerts about obstacles on the streets. The system will allow users to interact by submitting new findings to a database and engage in temporary conversations related to these findings. The primary interface will be a map displaying the locations of reported obstacles.

2. System Overview

U-KRATER aims to enhance road safety by enabling users to report and view obstacles on streets through a map interface. Users can contribute by adding new findings to the database and participate in short-lived conversations about these obstacles. The system will manage these interactions to ensure the information remains current and relevant.

3. Functional Requirements as Story Points

• As a User, I should be able to report an obstacle in one step: upon opening the app, I receive a message to confirm the presence of an obstacle and must press a confirmation button.

  • The GPS should be running; if not, a reminder will be sent to the user to activate it.
  • Once confirmed, the obstacle will be presented on the map for others to see live.
  • The obstacle information will be posted for a limited time of 10 minutes.
  • Other users can see the obstacle and confirm if it is still there or has been removed.

• As a User, I should be able to view a map displaying the locations of reported street obstacles.

• As a User, I should be able to submit new findings about street obstacles to the database.

• As a User, I should be able to engage in temporary conversations related to obstacle findings, limited to 10 posts, with older posts disappearing as new ones are added.

4. User Personas

• User: A general user who reports obstacles and engages in conversations about them.

5. Core User Flows

• User opens the app -> Views map with obstacle locations -> Submits a new finding -> Engages in a conversation about the finding (limited to 10 posts).

6. Visuals Colors and Theme

[Default — not specified by user]

• primary: #007BFF (a bright blue for brand recognition)
• primary_light: #66B2FF (a lighter blue for hover states)
• secondary: #6C757D (a neutral gray for secondary elements)
• accent: #FFC107 (a vibrant yellow for call-to-action elements)
• highlight: #28A745 (a green for notifications and active states)
• bg: #F8F9FA (a light gray for the background)
• surface: #FFFFFF (white for card/panel backgrounds)
• text: #212529 (a dark gray for primary text)
• text_muted: #6C757D (a softer gray for secondary text)
• border: #DEE2E6 (a subtle gray for borders)

7. Signature Design Concept

The U-KRATER landing page will feature an interactive map that dynamically updates with user-submitted obstacle reports. The map will serve as a living interface where users can click on obstacle markers to view details and engage in conversations. The map will animate smoothly as new reports are added, providing a real-time visualization of street conditions.

Landing Hero Motion Brief

The hero section will feature a continuously updating map with animated markers representing new obstacle reports. As users submit findings, markers will appear with a subtle bounce animation, drawing attention to new entries. The map will pan and zoom to accommodate new data, ensuring users have a clear view of all reported obstacles. This interactive map will be built using motion/react for smooth transitions and animations.

8. Interaction Model & Motion Direction

• Intended Interaction Model: Animated
  • The landing page will feature moderate scroll-triggered reveals and hover transitions. Interactive elements like the map and obstacle markers will have spring physics for a polished user experience.

9. Non-Functional Requirements

• The system must handle real-time data updates efficiently.
• The map interface should be responsive and accessible on various devices.
• Conversations should be managed to ensure they do not exceed 10 posts.

10. Tech Stack

• Frontend: React for Web
• Backend: Python, FastAPI
• Database: MySQL or MariaDB
• Local Orchestration: Docker, docker-compose

11. Assumptions and Constraints

• The system assumes users have internet access to interact with the map and submit findings.
• Conversations are limited to 10 posts to maintain relevance and manage database load.

12. Glossary

• Obstacle: Any object or condition on the street that may impede traffic or cause accidents.
• Finding: A user-submitted report of an obstacle.
• Temporary Conversation: A short-lived discussion related to a finding, limited to 10 posts.