School management system requirements, and the ten to ignore

A requirements list for a school system tends to arrive as a spreadsheet with sixty rows, all marked essential, assembled by asking every department what they would like. That document cannot be costed and cannot be built, because it contains no information about what matters. Nobody is lying. It is just that asking people what they want produces a wish list, and asking what they do every day produces requirements.

Three things carry almost all of the daily load in a school: attendance, fees, and communication with parents. Get those right and the system is used. Get them wrong and no amount of timetabling sophistication rescues it, because staff go back to the spreadsheet that works.

Attendance, because everything else depends on it

Attendance looks like the simplest module and is the one most often rebuilt after launch. The reason is that it is not a record of who was present. It is a legal record, a safeguarding trigger, and in many systems the input to fee calculation and to reporting sent upward to a ministry or an inspectorate.

The requirements that matter are unglamorous. Can a teacher mark a register in under thirty seconds on a phone with poor connectivity, and does it hold if the connection drops halfway. Can a mark be corrected afterwards, by whom, and does the system keep the original. Can it distinguish absent from late from authorised, because those three have different consequences and a single boolean cannot carry them.

The offline question is the one that gets skipped in procurement and decides adoption. A register that fails on a weak signal is a register that gets kept on paper and typed in at the end of the week, which destroys every downstream use it was built for.

Fees, and the reconciliation nobody scopes

Fee management is where school systems get genuinely hard, and the difficulty is not the invoice. It is that real fee structures are full of exceptions: sibling discounts, staff children, scholarships, part-term joiners, transport charged separately, instalment plans agreed individually by a bursar who remembers the arrangement.

A system that models fees as a price per student per term will be defeated within a month, and the workaround is always the same: someone maintains a parallel spreadsheet of adjustments, and the system stops being the source of truth. The requirement to write down is not invoicing. It is whether an arbitrary per-student adjustment can be recorded with a reason and an approver, and whether the resulting figure reconciles against what actually arrived in the bank.

Reconciliation is the part that is almost never in the original scope and is always needed, because payments arrive by transfer with unhelpful references. The same pattern shows up in every billing build, and it is covered in the three places invoice automation breaks.

Parent communication, and what sending actually costs

Parent communication is usually specified as send notifications and is priced as if it were free. It is not, and in Egypt and the Gulf most of it now travels over WhatsApp rather than SMS or email, which has a specific billing model worth understanding before the requirement is written.

Meta moved the WhatsApp Business Platform to per-message pricing on 1 July 2025, with template messages charged by category and recipient country. The detail that matters for a school is that utility templates delivered inside an open customer service window are free, and all non-template messages inside that window are free too. Service conversations became free for all businesses on 1 November 2024.

Read practically, that means a school broadcasting an absence alert to two thousand parents who have not messaged recently is sending paid template messages, while a school replying inside an open conversation is not. The cost difference between a well-designed notification flow and a naive one is large, and it is a design decision rather than a vendor rate. We went through the mechanics in automating WhatsApp notifications and the billing behind it.

The ten requirements that pad a proposal

These appear in nearly every school system proposal. Some are genuinely useful later. None of them should decide the purchase, and a vendor leading with them is selling a feature count.

• A mobile app for parents, when a web page and a WhatsApp message reach more of them with less to maintain.
• Timetable auto-generation, which works for simple cases and gets overridden by a human for the constraints that actually bind.
• A built-in learning platform, competing with whatever the school already uses and losing.
• Biometric attendance hardware, which solves a problem most schools do not have and adds a failure point that does.
• Library management, real but small, and usually better served by something dedicated.
• Transport and route tracking, worth building only where the school runs its own fleet.
• An alumni portal, which nobody maintains after year one.
• Inventory and asset tracking, a separate system wearing a school badge.
• Custom report builders, which produce reports nobody reads while the three that matter stay hard-coded.
• AI analytics dashboards, predicting outcomes from data the school has not yet collected reliably.

The common thread is that each of these is defensible in isolation and none of them is what makes staff open the system on a Monday morning.

The requirement that actually decides the project

It is not a module. It is whether the system can exchange data with everything else the school already runs, and it is the requirement most likely to be discovered late and expensively.

There is a real standard for this. 1EdTech maintains OneRoster, which defines how student, teacher, organisation, course and enrolment information moves between a school information system and its teaching tools, alongside a gradebook service covering results and line items and a resource service for allocating materials to classes. Version 1.2 supports both CSV and REST modes.

Asking a vendor whether they support OneRoster is a better question than any feature on the list, for a reason that has nothing to do with the standard itself: it is a question about whether the school's data can leave. A system that can export a conformant roster is a system you can migrate away from. One that cannot has made the next decision for you.

How to write it down

A requirements document for a school system is more useful at two pages than at sixty. For each of the three core areas, describe the worst realistic case rather than the happy path: the teacher with no signal, the parent on an individually agreed instalment plan, the fee paid by transfer with the wrong reference on it.

A vendor who answers those three well is worth continuing with. One who returns to the module list has told you something useful. The general method, including why the happy path is the wrong thing to specify, is in how to write a software requirements document, and the build-versus-buy question that sits underneath all of this is in custom software versus off the shelf.

An honest limit

Most schools should not commission a custom system. The established products are mature, the domain is well understood, and a school with fewer than a few thousand students is rarely doing anything a product cannot handle. The case for building is narrow: an unusual fee model, a regulatory reporting obligation no product covers, or an existing set of systems that the school cannot replace and the product will not talk to.

If a product fits, buy it and spend the saved budget on the integration and the data migration, which is where these projects actually fail. The scoping approach we use for a comparable domain is in a clinic management system, scoped to what a clinic runs on, and the same logic applied to a smaller education setting is in a training centre management system.

One note on procurement timelines, which surprise people. Education buying is slow for structural reasons rather than obstructive ones, and understanding the other side of the table helps a school plan its own year. bdg-labs covers it from the seller's perspective in what decides a sale into the education sector, which is a useful read precisely because it is not written for buyers.