System Requirements Document (SRD)

Project Name: magic-mobile

1. Introduction

The magic-mobile project is a mobile application designed to streamline the process of managing doctor registrations for clinics and healthcare administrators. Developed using Flutter, this app aims to provide a seamless, cross-platform experience for clinics and admins to onboard, organize, and manage doctor profiles efficiently.

This document outlines the system requirements for the magic-mobile project, ensuring clarity and alignment with the project's goals.

2. System Overview

The magic-mobile app is tailored for clinics and healthcare administrators to manage doctor registrations. The app will allow admins to add new doctor profiles, view a list of registered doctors, approve or reject registration requests, and edit existing profiles.

Flutter has been chosen as the development framework to ensure compatibility across both Android and iOS platforms, providing a unified experience for users. The app will prioritize user-friendly design, secure data handling, and efficient workflows to meet the needs of healthcare administrators in India.

3. Functional Requirements

As Clinics/Admins:

• I should be able to register new doctors by entering their details.
• I should be able to view a list of all registered doctors.
• I should be able to approve or reject doctor registration requests.
• I should be able to edit existing doctor profiles.
• I should be able to search for doctors by name, specialty, or location.
• I should be able to export the list of registered doctors as a report (e.g., PDF or Excel).
• I should be able to selectively re-run specific processes to regenerate SRD content based on updated requirements.

4. User Personas

Admin:

• Description: Healthcare administrators or clinic managers responsible for onboarding and managing doctor profiles.
• Goals: Efficiently manage doctor registrations, ensure data accuracy, and maintain compliance with healthcare standards.
• Pain Points: Time-consuming manual processes, lack of centralized data, and difficulty in tracking approvals.

Doctor (Indirect User):

• Description: Healthcare professionals whose profiles are being registered and managed by admins.
• Goals: Ensure their information is accurately represented and approved for practice.
• Pain Points: Delays in registration approvals and errors in profile data.

5. Visuals Colors and Theme

Color Palette:

The magic-mobile app will feature a professional yet approachable theme, reflecting the healthcare domain while maintaining a modern aesthetic.

• Background: #F4F7FC (Soft blue-gray for a calming look)
• Surface: #FFFFFF (Pure white for cards and forms)
• Text: #2C3E50 (Deep navy for readability)
• Accent: #3498DB (Vibrant blue for actionable elements like buttons)
• Muted Tones: #95A5A6 (Neutral gray for secondary text and borders)

6. Signature Design Concept

Interactive Doctor Registration Dashboard with Animated Workflow

The home page of the magic-mobile app will feature an interactive dashboard that visually represents the status of doctor registrations.

Key Features:

• Dynamic Cards: Each card represents a doctor registration request. Cards will visually flip when tapped, revealing detailed information about the doctor.
• Approval Workflow Animation: When an admin approves or rejects a registration, the card will slide into a "Completed" or "Rejected" section with a smooth transition animation.
• Search and Filter: A floating search bar with real-time filtering allows admins to quickly locate doctors by name, specialty, or location.
• Progress Indicator: A circular progress bar at the top of the dashboard shows the percentage of completed registrations.
• Selective Re-run Button: A dedicated button allows admins to regenerate specific SRD sections based on updated requirements, with a visual confirmation animation.

Visual Impact:
Admins will feel empowered by the intuitive and visually engaging interface, making the process of managing registrations efficient and enjoyable. The selective re-run feature adds a layer of control and adaptability to the system.

7. Non-Functional Requirements

• Performance: The app should load within 2 seconds on both Android and iOS devices.
• Scalability: The system should support up to 10,000 doctor profiles without performance degradation.
• Security: Data must be encrypted both in transit and at rest, adhering to healthcare data protection standards.
• Usability: The app must be intuitive and require minimal training for admins to use effectively.
• Cross-Platform Compatibility: The app must function seamlessly on both Android and iOS devices.
• Selective Re-run Capability: The system must allow admins to trigger specific SRD regeneration processes without affecting other sections.

8. Tech Stack

Frontend:

• Flutter

Backend:

• Python
• FastAPI

Database:

• MySQL (preferred for structured data storage)
• Alembic for database migrations

AI Tools (if applicable):

• GPT 5.2 for user-friendly responses

Local Orchestration:

• Docker
• docker-compose

Server-Side Orchestration:

• Kubernetes

9. Assumptions and Constraints

Assumptions:

• Admins will primarily use the app during business hours (IST timezone).
• The app will be used by clinics and healthcare facilities in India, adhering to local healthcare regulations.
• Internet connectivity will be available for data synchronization.

Constraints:

• The app must comply with healthcare data protection laws in India.
• Flutter will be the sole framework for development, limiting native platform-specific features.

10. Glossary

• Admin: A user responsible for managing doctor registrations.
• Doctor Profile: A collection of data about a healthcare professional, including name, specialty, and location.
• Flutter: A cross-platform UI toolkit for building natively compiled applications.
• FastAPI: A modern web framework for building APIs with Python.
• Alembic: A database migration tool for Python.
• Selective Re-run Capability: A feature that allows admins to regenerate specific sections of the SRD based on updated requirements.

This document serves as the foundation for the development of the magic-mobile project, ensuring alignment with Yash's vision and requirements.