Here is the System Requirements Document (SRD) for the Hollow-Montessori project, updated with all the details provided. This document is structured to guide the development of your SaaS-based Montessori Management System.

System Requirements Document (SRD)

Project Name: Hollow-Montessori

1. Introduction

The Hollow-Montessori project is a SaaS-based Montessori Management System designed to serve multiple schools with isolated data environments. This platform will provide a comprehensive solution for managing school operations, including user authentication, role-based access, automated user creation, secure communication, and more.

The system is tailored for schools in Nepal (NP) and includes support for local payment gateways like Khalti, multi-language functionality (English and Nepali), and timezone considerations for Nepal Standard Time (NST).

This document outlines the system requirements, functional and non-functional specifications, and design concepts to ensure the successful development of the platform.

2. System Overview

The Hollow-Montessori platform will operate as a multi-tenant SaaS solution, allowing multiple schools to register and manage their operations independently. Key features include:

• Multi-School Support: Each school will have its own isolated database to ensure data privacy and security.
• Role-Based Access Control: Different user roles (e.g., Super Admin, School Admin, Teacher, Student, Parent, Accountant, Staff, Exam Department) will have specific permissions and access levels.
• Comprehensive Dashboards: Tailored dashboards for each user role to manage tasks efficiently.
• Secure Authentication: JWT-based authentication, OTP recovery, and password hashing for secure user access.
• Payment Integration: Support for local (Khalti) and global (Stripe) payment gateways.
• Multi-Language Support: English and Nepali language options for better accessibility.
• Automated User Creation: Streamlined processes for creating and managing users, including students, parents, teachers, and staff.

The system will be scalable, mobile-responsive, and production-ready, ensuring a seamless experience for all users.

3. Functional Requirements

As User Stories:

• As a Super Admin, I should be able to manage all schools, view analytics, and oversee platform-wide operations.
• As a School Admin, I should be able to manage users, classes, attendance, and payments for my school.
• As a Teacher, I should be able to manage attendance, assignments, and student marks.
• As a Parent, I should be able to view my child’s progress, attendance, fees, and homework.
• As a Student, I should be able to access my results, homework, attendance, and class routine.
• As an Accountant, I should be able to manage billing, payments, and fee tracking.
• As a Staff member, I should be able to manage my assigned tasks and attendance.
• As an Exam Department member, I should be able to create exam routines, publish results, and generate report cards.
• As a user, I should be able to reset my password using an OTP system.
• As a School Admin, I should be able to bulk upload user data via Excel.
• As a School Admin, I should be able to generate ID cards for students and staff.
• As a user, I should be able to switch between light and dark mode.
• As a user, I should be able to select my preferred language (English or Nepali).
• As a user, I should be able to receive login credentials via email or SMS after account creation.
• As a user, I should be forced to change my password on first login.

4. User Personas

1. Super Admin

• Manages all schools on the platform.
• Oversees platform-wide analytics and revenue.
• Handles platform settings and configurations.

2. School Admin

• Manages users, classes, attendance, and payments for their school.
• Oversees school-specific analytics and operations.

3. Teacher

• Manages student attendance, assignments, and marks.

4. Student

• Accesses results, homework, attendance, and class routines.

5. Parent

• Monitors their child’s progress, attendance, fees, and homework.

6. Accountant

• Manages billing, payments, and fee tracking.

7. Staff

• Handles assigned tasks and attendance.

8. Exam Department

• Creates exam routines, publishes results, and generates report cards.

5. Visuals Colors and Theme

Unique Color Palette for Hollow-Montessori:

• Background: #F4F1E9 (Warm Ivory)
• Surface: #FFFFFF (Pure White)
• Text: #333333 (Deep Charcoal)
• Accent: #FF7A59 (Bright Coral)
• Muted Tones: #B5B5B5 (Soft Gray)

This palette reflects a warm, inviting, and professional Montessori aesthetic, ensuring a user-friendly and visually appealing interface.

6. Signature Design Concept

Interactive Montessori Universe

The homepage will feature an interactive galaxy map that represents the Montessori ecosystem.

• Design: A dynamic galaxy with stars representing different sections of the platform (e.g., Students, Teachers, Parents, etc.).
• Interaction: Users can hover over or click on stars to navigate to the corresponding section. Stars will pulse gently, and constellations will form as users interact with the map.
• Color Dynamics: The galaxy will shift colors based on the time of day (e.g., soft blues and purples at night, warm oranges and yellows during the day).
• Micro-Animations: Shooting stars will occasionally streak across the screen, and constellations will glow softly.
• Sound Design: Subtle ambient space sounds, like soft hums and twinkling, will enhance the immersive experience.

This unique design will make the platform memorable and engaging, aligning with the Montessori ethos of exploration and discovery.

7. Non-Functional Requirements

• Scalability: The system must support up to 1,000 schools and 100,000 users.
• Performance: Page load times should not exceed 3 seconds under normal load conditions.
• Security: Implement robust security measures, including JWT authentication, password hashing, and data encryption.
• Availability: Ensure 99.9% uptime with proper server monitoring and failover mechanisms.
• Localization: Support English and Nepali languages, with the ability to add more languages in the future.

8. Tech Stack

Frontend:

• React.js with Tailwind CSS for web application.
• Axios for API requests.
• React Router for navigation.

Backend:

• Node.js with Express.js for API development.

Database:

• MongoDB with Mongoose for NoSQL data.

Authentication:

• JWT for secure authentication.
• bcrypt for password hashing.

Payments:

• Khalti for local payments in Nepal.
• Stripe for global payments.

Notifications:

• Nodemailer for email notifications.
• Sparrow SMS or Twilio for SMS notifications.

9. Assumptions and Constraints

• Each school operates independently with no data sharing between schools.
• The system will primarily serve schools in Nepal, with potential for global expansion.
• Payment gateways will include Khalti and Stripe.
• The platform will be mobile-responsive and support both web and mobile applications.
• Default passwords will be the same as the user ID and must be changed upon first login.

10. Glossary

• JWT: JSON Web Token, used for secure authentication.
• SaaS: Software as a Service, a cloud-based software delivery model.
• NoSQL: Non-relational database system.
• OTP: One-Time Password, used for secure authentication.
• Montessori: An educational approach emphasizing independence and hands-on learning.

This concludes the System Requirements Document for Hollow-Montessori. Let me know if you need any additional details or adjustments, Ramesh!