Software Requirement Specification (SRS)
1. Introduction
1.1 Purpose
Defines the software requirements for SkoolyHub, a school management system covering academics, admissions, people, attendance, fees, assessment and communication, with a public website and REST APIs for parent, teacher and student mobile apps.
1.2 Scope
One deployment serves one school. Multi-school operators run one deployment per school.
1.3 Definitions
| Term | Meaning |
|---|---|
| Academic year | The scoping key for classes, timetables, fees, exams and enrolment |
| Class | A year group |
| Section | A division of a class, with capacity and a class teacher |
| Guardian | A parent or carer with a portal/app account |
| Day register | Attendance with no period — the whole-day record |
| Minor units | Integer cents; every monetary value |
public_id |
The opaque identifier exposed in URLs |
| Add-on | A pluggable channel: payments, storage, email, SMS |
2. Overall description
2.1 Product perspective
A single Next.js application serving five surfaces (public site, admin, and three portals) plus a versioned REST API, over one PostgreSQL database.
2.2 User classes
| Class | Technical skill | Frequency |
|---|---|---|
| Office staff | Low | Daily, heavy |
| Principal | Low | Weekly |
| Accountant | Medium | Daily during collection |
| Teacher | Low | Daily, brief |
| Guardian | Low, mobile-only | Weekly |
| Student | Low, mobile-only | Weekly |
| Administrator | High | At install and upgrade |
2.3 Operating environment
- Server: Node.js 20+, PostgreSQL 14+
- Admin/portal browsers: current Chrome, Safari, Firefox, Edge
- Apps: iOS and Android clients over HTTPS
- Assumed: intermittent, low-bandwidth connectivity at the school
2.4 Constraints
- One school per deployment; no tenant column exists.
- Money is integer minor units throughout.
- Schema is provisioned idempotently; there are no ordered migrations.
- Integration credentials live encrypted in the database, not in environment variables.
3. Functional requirements
Enumerated in the Functional Requirement Document. Summarised by subsystem:
| Subsystem | Requirements |
|---|---|
| Authentication | Role-scoped JWTs; OTP activation and reset for guardians and staff; non-enumerable failures |
| Academic setup | Years, terms, classes, sections, subjects, allocation, bell schedule, clash-checked timetable, calendar |
| Admissions | Nine-stage pipeline, waiting list, idempotent conversion to a student |
| People | Students, guardians, staff, enrolment history, documents, bulk import, ID cards, promotion |
| Attendance | Day and period registers, five statuses, roll-wide default, guardian notification, staff attendance |
| Fees | Heads, structures, concessions, invoicing, counter collection, add-on driven online payment |
| Assessment | Exams, papers, marks, grade scale, computed report cards, explicit publication |
| Homework | Assignment, submission, grading |
| Communication | Targeted circulars, read receipts, leave, per-recipient notifications |
| Parent feed | One merged chronological stream, cursor-paged, deep-linked |
| Reports | Nine reports with CSV export |
4. External interfaces
4.1 REST API
/api/v1/{parent,teacher,student}/*, documented at /api/docs/v1 from a spec generated out of the route handlers. JSON in and out; Authorization: Bearer <jwt> for mobile, httpOnly cookies for web.
4.2 Payment gateways
Twenty gateways ship as add-ons behind one driver contract (method / create / verify). A gateway is offered only when it has an active connection and a registered driver.
4.3 Storage
Cloudflare R2, Amazon S3, DigitalOcean Spaces and Google Cloud Storage, all through the S3 API. Images are resized server-side into WebP variants.
4.4 Messaging
Email through SMTP or a provider add-on; SMS and push through their channels; templates editable in the admin.
5. Non-functional requirements
5.1 Performance
| # | Requirement |
|---|---|
| P1 | App home screens complete in one round trip |
| P2 | Badge refresh has its own minimal endpoint, separate from the home screen |
| P3 | Feed cost is bounded by page size × source count, not table size |
| P4 | Every list query is served by an index on its filter and sort |
5.2 Security
| # | Requirement |
|---|---|
| S1 | Passwords are bcrypt hashed; hashes are never returned by any endpoint |
| S2 | Tokens carry their role; cross-role replay is rejected |
| S3 | Object-level authorization on every read and write |
| S4 | URLs expose opaque ids only |
| S5 | Auth and public write endpoints are rate-limited per IP and per handle |
| S6 | Integration credentials are encrypted at rest |
| S7 | All SQL is parameterised |
| S8 | Fee payment requires a verified guardian |
| S9 | Monetary amounts are never taken from a request |
5.3 Usability
| # | Requirement |
|---|---|
| U1 | Layout-shaped skeletons while loading, never a bare spinner |
| U2 | Forms use shared components with inline validation |
| U3 | Every screen is responsive; tables scroll horizontally |
| U4 | Every user-facing string is translatable |
| U5 | Error messages state what to do, not what failed internally |
| U6 | Overlays animate in and out, honouring reduced-motion preferences |
5.4 Reliability
| # | Requirement |
|---|---|
| R1 | Schema provisioning is idempotent and safe to re-run |
| R2 | Payment settlement is idempotent — a retried callback cannot double-credit |
| R3 | Re-taking a register overwrites rather than duplicating |
| R4 | Re-running payroll skips anyone already paid |
| R5 | Admission conversion is idempotent |
| R6 | A student with financial history cannot be deleted |
5.5 Maintainability
| # | Requirement |
|---|---|
| M1 | Business rules live in the domain layer, not in routes |
| M2 | One spec drives both a table's API and its admin screen |
| M3 | The API reference is generated from the handlers |
| M4 | Structural enums are types; editable labels are data |