System Requirements Document (SRD) for super-database

1. Introduction

The super-database project is a full-stack web application designed to streamline the management of student tutoring registrations. Developed exclusively for Patryk Biniek in Poland, this system will enable efficient handling of student data, lesson scheduling, and real-time updates. The application is tailored for single-user use, ensuring a clean and conflict-free database for managing tutoring sessions.

This document outlines the functional and non-functional requirements, user personas, design concepts, and technical specifications necessary to bring the super-database to life.

2. System Overview

The super-database is a responsive web application that allows Patryk to:

• Add, view, and delete student records.
• Prevent scheduling conflicts by enforcing database-level constraints.
• Manage lesson schedules efficiently with real-time updates.

The system will feature:

• A form for adding student details.
• A dynamic table for displaying student records.
• A mechanism for deleting records by student ID.
• Validation to prevent overlapping lesson times for the same student on the same day.

The backend will be built using Python and FastAPI, while the frontend will leverage React for a modern and responsive user interface. Data will be stored in a MySQL database with constraints to ensure data integrity.

3. Functional Requirements

• As Admin, I should be able to add a student by filling out a form with the following fields:
  • Auto-generated ID
  • First name
  • Last name
  • Address
  • Subject
  • School class
  • Level (basic or extended)
  • Lesson day
  • Lesson time (start and end)
  • Hourly rate
• As Admin, I should be able to view all students in a dynamic table that updates in real-time.
• As Admin, I should be able to delete a student by entering their assigned ID number.
• As Admin, I should be prevented from scheduling overlapping lesson times for the same student on the same day.

4. User Personas

Admin (Patryk Biniek)

• Role: Sole user of the system.
• Goals: Efficiently manage student tutoring registrations and schedules without conflicts.
• Pain Points: Avoiding scheduling errors and ensuring real-time updates for a seamless workflow.

5. Visuals Colors and Theme

The super-database will feature a clean and professional design with a unique color palette that reflects trust, efficiency, and clarity:

• Background: #F5F7FA (Soft Light Gray)
• Surface: #FFFFFF (Pure White)
• Text: #2C3E50 (Deep Navy Blue)
• Accent: #3498DB (Vivid Sky Blue)
• Muted: #BDC3C7 (Soft Gray)

This palette ensures a modern and visually appealing interface that is easy on the eyes during extended use.

6. Signature Design Concept

The super-database homepage will feature a "Dynamic Schedule Dashboard" as its centerpiece. This dashboard will display:

• A live, interactive calendar that highlights scheduled lessons.
• Color-coded blocks for each subject (e.g., blue for math, green for physics).
• Hover animations that reveal detailed student information (name, level, hourly rate, etc.).
• A "conflict alert" system that visually flags overlapping lesson times in red.

The dashboard will use smooth transitions and micro-interactions to enhance usability:

• Clicking on a calendar block will open a modal with options to edit or delete the lesson.
• Adding a new lesson will trigger a subtle "success" animation (e.g., a green checkmark fading in and out).
• The table view will feature a "slide-in" animation for new entries and a "fade-out" effect for deleted ones.

This design ensures the homepage is not only functional but also engaging and intuitive.

7. Non-Functional Requirements

• The system must be responsive and accessible on desktop, tablet, and mobile devices.
• Real-time updates should occur within 1 second of any database change.
• The database must enforce constraints to prevent overlapping lesson times for the same student on the same day.
• Form inputs must be validated for completeness and correctness before submission.
• The application must support at least 1,000 student records without performance degradation.

8. Tech Stack

Frontend

• React for Web

Backend

• Python
• FastAPI

Database

• MySQL (with Alembic for migrations)

AI Tools

• None required for this project.

Local Orchestration

• Docker
• docker-compose

9. Assumptions and Constraints

Assumptions

• The system will be used exclusively by Patryk Biniek.
• All data will be entered manually by the admin.
• The application will be hosted locally or on a private server.

Constraints

• The database must prevent overlapping lesson times for the same student on the same day.
• The system must support real-time updates without requiring a page reload.

10. Glossary

• Admin: The sole user of the system (Patryk Biniek).
• Dynamic Table: A table that updates automatically without requiring a page reload.
• Real-Time Updates: Changes to the database are reflected instantly in the user interface.
• Lesson Conflict: A situation where a student is scheduled for overlapping lessons on the same day.
• SQL Database: A structured database used to store and manage student records.