Functional Requirement Document (FRD)
Each requirement names the surface it lives on: A admin, P parent app/portal, T teacher app/portal, S student app/portal, W public website.
1. Authentication & accounts
| # | Requirement | Surface |
|---|---|---|
| F1.1 | Admin signs in with email and password | A |
| F1.2 | Guardians sign in with email or phone plus a password they set themselves | P |
| F1.3 | Guardian first-time activation and password reset both work by a 6-digit code sent to the contact detail the school holds; the code is single-use and expires in 10 minutes | P |
| F1.4 | Staff sign in with their school email; password reset uses the same code flow | T |
| F1.5 | Students sign in with admission number or email | S |
| F1.6 | Tokens carry their role; a token from one portal is rejected by another | P T S |
| F1.7 | Sign-in failures are indistinguishable from unknown accounts, so the endpoints cannot enumerate the roll | P T S |
| F1.8 | Devices register for push and unregister at logout | P T |
2. Academic setup
| # | Requirement | Surface |
|---|---|---|
| F2.1 | Create academic years and mark one current | A |
| F2.2 | Create terms within a year | A |
| F2.3 | Create classes (year groups) and sections, each with a capacity and optionally a class teacher | A |
| F2.4 | Create subjects and allocate them to a class, optionally with a teacher | A |
| F2.5 | Define the bell schedule — periods with start and end times, and breaks | A |
| F2.6 | Build the timetable on a grid; teacher and room clashes are refused with the reason | A |
| F2.7 | Maintain a school calendar of events and holidays, published to families | A P S |
| F2.8 | Record syllabus units and dated lesson plans with a coverage percentage | A T |
3. Admissions
| # | Requirement | Surface |
|---|---|---|
| F3.1 | Capture an application with applicant, guardian and previous-school details, and a photo | A |
| F3.2 | Move an application through enquiry → applied → assessment → offered → accepted → enrolled, with rejected and withdrawn as exits | A |
| F3.3 | Record assessment date, score and panel notes | A |
| F3.4 | Maintain a waiting list with positions | A |
| F3.5 | Convert an accepted application into a student, creating or reusing the family's guardian account and carrying the photo across | A |
| F3.6 | Conversion is idempotent — a second attempt returns the student already created | A |
4. Students & guardians
| # | Requirement | Surface |
|---|---|---|
| F4.1 | Maintain student records with photo, placement, contact, medical notes and category | A |
| F4.2 | Allocate an admission number automatically when the field is left blank | A |
| F4.3 | Bulk-import students from CSV | A |
| F4.4 | Link multiple guardians per student, one marked primary | A |
| F4.5 | Print ID cards for a section or a selection | A |
| F4.6 | Promote a cohort to the next class at year end, keeping enrolment history per year | A |
| F4.7 | Refuse deletion of a student with fee history | A |
| F4.8 | A guardian sees only their own children, everywhere | P |
| F4.9 | Guardians edit their own profile and notification channels | P |
5. Attendance
| # | Requirement | Surface |
|---|---|---|
| F5.1 | Take a daily register per section | T A |
| F5.2 | Take a per-period register for a subject lesson | T |
| F5.3 | Statuses: present, absent, late, excused, half day | T A |
| F5.4 | Send a roll-wide default with only the exceptions listed | T |
| F5.5 | Re-taking a register overwrites rather than duplicating | T A |
| F5.6 | A day-register absence notifies the student's guardians; a per-period absence does not | T |
| F5.7 | Guardians see a day-by-day record and a percentage over recorded days | P |
| F5.8 | Staff attendance with optional check-in / check-out times, filterable by staff type and department | A |
6. Fees
| # | Requirement | Surface |
|---|---|---|
| F6.1 | Define fee heads and per-class fee structures | A |
| F6.2 | Apply concessions to a student | A |
| F6.3 | Generate invoices for a class or a student | A |
| F6.4 | Collect at the counter, recording mode and receipt | A |
| F6.5 | List available payment methods from the connected Payments add-on | P |
| F6.6 | Pay an invoice in the app through the school's gateway — redirect, in-app widget or form post | P |
| F6.7 | The charge is computed server-side from the invoice; a part payment can only ever pay less than the balance | P |
| F6.8 | The ledger is credited only once the gateway confirms; an abandoned payment leaves the invoice untouched | P |
| F6.9 | Confirming twice returns the original receipt rather than crediting twice | P |
| F6.10 | Only a verified guardian may pay | P |
| F6.11 | Show outstanding balance and receipts per child | P |
7. Examinations
| # | Requirement | Surface |
|---|---|---|
| F7.1 | Create exams with type, term, dates and weighting | A |
| F7.2 | Schedule per-subject papers with maximum and passing marks | A |
| F7.3 | Enter marks per paper, clamped to the maximum | T A |
| F7.4 | Maintain a grade scale mapping percentages to grades and points | A |
| F7.5 | Compute report cards with totals, percentage, grade and rank in section | A |
| F7.6 | Publish results as a separate, deliberate action | A |
| F7.7 | Families see results only when the report card and its exam are both published | P S |
8. Homework
| # | Requirement | Surface |
|---|---|---|
| F8.1 | Assign homework to a section with a subject, due date, attachments and optional marks | T |
| F8.2 | Submit work with text and attachments from the parent or student app | P S |
| F8.3 | Grade a submission with marks and feedback | T |
| F8.4 | Submission time is taken from the server clock, not the device | P S |
9. Communication
| # | Requirement | Surface |
|---|---|---|
| F9.1 | Write circulars targeted at everyone, parents, a class or a section | A |
| F9.2 | Schedule publication and expiry; pin important ones | A |
| F9.3 | Record read receipts per recipient | A P |
| F9.4 | Guardians apply for leave on behalf of a child; staff apply for their own | P T |
| F9.5 | Approve or reject leave with a note | A T |
| F9.6 | A per-recipient notification feed, with channel preferences | A P T S |
10. The parent app home feed
| # | Requirement | Surface |
|---|---|---|
| F10.1 | One chronological stream merging announcements, attendance exceptions, homework set and graded, exam schedules, published results, invoices, receipts, leave decisions and calendar entries | P |
| F10.2 | Each card names the screen to open and the record to open it on | P |
| F10.3 | Cards carry a tone — info, success, warning, urgent — for the app to style | P |
| F10.4 | Filter by card type, and by child | P |
| F10.5 | Paging is a timestamp cursor, so a card never duplicates while the school keeps publishing | P |
| F10.6 | Attendance appears only as an exception, never as a daily "present" card | P |
11. Reports
| # | Requirement | Surface |
|---|---|---|
| F11.1 | Attendance defaulters below a threshold | A |
| F11.2 | Fee collection and outstanding dues | A |
| F11.3 | Exam performance and subject analysis | A |
| F11.4 | Enrolment and strength by class | A |
| F11.5 | Every report exports to CSV | A |
12. Public website
| # | Requirement | Surface |
|---|---|---|
| F12.1 | Editable pages, news, gallery, FAQs and contact forms | W |
| F12.2 | Admission enquiries from the site land in the admissions pipeline | W A |
| F12.3 | Branding, logo and colours from settings — no hardcoded school name anywhere | W |
13. Non-functional
| # | Requirement |
|---|---|
| N1 | Every data-fetching screen shows a layout-shaped skeleton, never a bare spinner |
| N2 | Home screens fetch in one round trip rather than fanning out |
| N3 | All money in minor units, end to end |
| N4 | Ids in URLs are opaque, never sequential |
| N5 | Every user-facing string is translatable |
| N6 | Every list is responsive and every table scrolls horizontally on mobile |
| N7 | Auth and public write endpoints are rate-limited |
| N8 | Schema provisioning is idempotent; no migration files to run in order |