Business Requirement Document (BRD)
1. Purpose
SkoolyHub replaces the spreadsheets, paper registers, WhatsApp groups and cash books a small-to-medium school runs on, with one system covering academics, admissions, people, attendance, fees, assessment and communication — and gives families a mobile app instead of a folder of paper notes.
2. Scope
In scope
- One school per deployment, across all its year groups and sections
- Admissions from first enquiry through to an enrolled student
- The student roll, guardians, and staff records
- Daily and per-period attendance
- Fee structures, invoicing, collection at the counter and online
- Exams, marks, grades, report cards
- Homework set and submitted
- Circulars, notifications and leave
- A public school website
- REST APIs for parent, teacher and student mobile apps
Out of scope
- Multi-school / district administration
- Course content delivery, video lessons, online quizzes
- General-ledger accounting and statutory tax filing
- Payroll statutory compliance beyond payslip generation
3. Business objectives
| # | Objective | How SkoolyHub meets it |
|---|---|---|
| B1 | Cut the office's manual data entry | One record per person, reused across modules; CSV bulk import; admission converts straight into a student |
| B2 | Get fees collected sooner | Invoices visible in the parent app the moment they are raised, payable in-app through the school's own gateway |
| B3 | Reach every family reliably | Circulars with audience targeting plus per-recipient notifications and push, instead of a message group |
| B4 | Make attendance a two-minute task | Roll-wide default with exceptions; absence notifies guardians automatically |
| B5 | Publish results without chaos | Marks entered per paper, report cards computed with rank, released on an explicit publish action |
| B6 | Keep a defensible record | Receipts are a ledger, payslips are frozen, enrolment history is retained per year |
| B7 | Give the school a public presence | The public site is part of the same install, edited from the same admin |
4. Stakeholders
| Stakeholder | Primary interest |
|---|---|
| Principal / head | Oversight, reports, approving and publishing |
| Office / registrar | Admissions, the roll, records, circulars |
| Accountant | Fee structures, collections, dues, payroll |
| Teachers | Registers, homework, marks, timetable |
| Guardians | Their child's day, money owed, results |
| Students | Timetable, homework, results |
| IT / vendor | Install, upgrade, backups, integrations |
5. Business rules
- BR1 — A student belongs to exactly one section within an academic year.
- BR2 — Admission numbers are unique and allocated server-side when left blank, so two clerks admitting at once cannot collide.
- BR3 — A student with fee history cannot be deleted; their status changes to transferred or withdrawn. Receipts already in a parent's hands cannot be un-issued.
- BR4 — A payment can never exceed an invoice's outstanding balance; the invoice's paid total is recomputed from the payment ledger.
- BR5 — Marks cannot exceed the paper's maximum; grades come from the grade scale, never from a request.
- BR6 — Results are visible to families only when the report card and its exam are published.
- BR7 — A timetable slot cannot double-book a teacher or a room.
- BR8 — A guardian account is created by the school and activated by the parent proving control of the contact detail on file. Staff never set a parent's password.
- BR9 — Fee payment requires a verified guardian, because money movement should not be possible on a guessed password alone.
- BR10 — One payslip per staff member per month; a paid payslip cannot return to draft.
- BR11 — Section capacity is enforced at admission and at promotion.
6. Success measures
| Measure | Target |
|---|---|
| Time to take a class register | Under 30 seconds |
| Fee invoices visible to parents | Immediately on generation |
| Admission enquiry → enrolled student | No re-keying of any field |
| Result publication | One action per exam, after review |
| Guardian app activation | Self-service, no office involvement |
7. Assumptions
- The school has one academic calendar and one timezone.
- Every family has at least a phone number; email is common but not universal — which is why sign-in accepts either.
- Internet at the school may be slow or intermittent, so screens fetch in as few round trips as possible.
- The school holds its own payment-gateway account; SkoolyHub never takes a cut and holds no funds.
8. Constraints
- One school per deployment.
- PostgreSQL is required.
- Storage and payment credentials live in the database, not in environment variables, so they travel with a database dump.
- Currency and timezone are set once at install and apply school-wide.