Write something
a product can fail.
Every product in this market claims enrolment, attendance, billing and reporting, so a requirements list built from those words produces a scorecard on which everyone scores full marks and the decision falls back to whichever demo felt nicest. A scenario is specific enough to fail: it names who does what, in what order, and what has to be true at the end.
Notice what the right-hand column does. It names the actor, so you find out whether the parent can do it or whether someone at the school has to. It includes an outcome, so "we support instalments" has to be demonstrated as an invoice a parent would understand. And it sets a bar — under a minute, within the response window — which turns a yes-or-no into a measurement. Six to twelve scenarios is usually enough; more than twenty and nobody will run them.
Seven systems,
so nothing is discovered later.
Write at least one scenario against each of the seven systems a school runs: enrolment and admissions; scheduling and attendance; teaching and coursework; the website and public pages; fees and payments; reporting; and data protection. The point of the coverage is not completeness for its own sake — it is that the systems a school forgets to evaluate are the ones it discovers in month six, and they are nearly always the last three. Schools evaluate teaching tools carefully and payments casually, then spend two years with a payments problem.
Add an eighth line that is not a system: the change scenario. Something moves — a class time, a student between groups, a price — and you write down everyone who must find out. That single scenario reveals more about a product's architecture than the other seven combined, because it exposes whether the student exists once or once per module.
A must is something
you would reject over.
The discipline that matters is the number of musts. A list with thirty musts has no musts, because when the leading product fails four of them the school will quietly downgrade those four rather than start again. Force the list under ten by asking, for each one: if everything else were perfect, would we really walk away over this? Most items survive that question as shoulds, which is where they belong and where they do their real work — shoulds are what separate two adequate products.
Score after each demo rather than at the end of all of them. Memory flattens: by the third demo, the first product's specifics have blurred into a general impression, and general impressions favour whoever presented most recently. Ten minutes of scoring immediately after each session is worth more than an hour of comparison a fortnight later.
Eight scenarios
to edit rather than adopt.
Rewrite each in your own school's vocabulary — your class names, your levels, your term structure — because a scenario written in your language is one your administrator can judge instantly, and one written in generic language invites the vendor to interpret it generously.
Where requirement lists
go wrong.
Describing your current workaround. A school that has spent three years reconciling two spreadsheets will write a requirement about reconciling two spreadsheets more easily, rather than about not needing to. Write the outcome the school wants, not the process it currently runs.
Requirements for the school you were. If you are planning a second site, teaching online, or moving from one-to-one to groups, write scenarios for that school rather than for this term's. Software is a three-to-five year decision and most schools evaluate against a snapshot of the week they happened to be in.
Omitting the exit. "We can export every student, enrolment, payment and attendance record, in a documented format, without a support ticket" belongs on the must list of every school, and it is the requirement most often left off because it feels pessimistic at the start of a relationship. It is the one that determines whether the next decision is yours to make.