LMS operations
How to Write LMS Requirements Before Development Starts
Turn academy routines into a clear LMS requirements document covering users, classes, attendance, finance, reports, permissions, and support.
- Direct answer
- Full process
- Real example
- Clear checks
The short answer
A useful requirements document lets an academy owner, administrator, designer, and developer read the same page and picture the same system. Start by documenting the present situation, then make one decision at a time. A tool should support the workflow; it should not be used to avoid deciding how the workflow works.
A custom LMS usually becomes expensive for one boring reason: nobody wrote down how the academy actually works before development began. Everyone talks about dashboards and features, but the small operational rules stay inside somebody’s head.
I would pause the design conversation for a day and map the real working week. What happens when a student joins late? Who can change attendance? When is a teacher payment approved? Those answers are the requirements.
A useful requirements document lets an academy owner, administrator, designer, and developer read the same page and picture the same system. If a step does not change what somebody knows, decides, or does, it probably does not belong in the process.
The complete process
Work through these stages in order. It is tempting to jump to the visible part, but most expensive revisions begin in an earlier decision that nobody finished.
Start with roles, not screens
List every person who will use the portal: owner, administrator, finance staff, teacher, student, and parent if parents need access. For each role, write what they may view, create, change, approve, export, and delete. Permissions are business rules, not decoration.
Ready to move on when: A role table exists and no role has vague access such as “can manage everything”.Map one student from enquiry to leaving
Write the complete student journey: enquiry, trial, admission, class assignment, attendance, progress, invoice, payment, pause, transfer, and withdrawal. Add the exceptions too. A system that only handles the happy path will create manual work the first week it is used.
Ready to move on when: Every stage has an owner, a status, and a next action.Define class and scheduling rules
Record lesson duration, time zones, teacher availability, group limits, recurring schedules, rescheduling rules, holidays, makeup classes, and cancellation notices. Decide which changes need approval and which should notify students automatically.
Ready to move on when: A scheduler can answer “what happens if…” without guessing.Describe finance in plain language
Write when invoices are created, whether fees are monthly or per lesson, accepted currencies, discounts, overdue rules, refunds, teacher salary calculations, and the reports finance needs. Include sample calculations using realistic numbers.
Ready to move on when: A sample month can be calculated by hand and matches the intended portal result.Rank the first release
Mark each requirement Must Have, Should Have, Later, or Not Needed. The first release should run the core operation well. Saving every possible idea for launch creates a long build and a confusing portal.
Ready to move on when: The Must Have list can be tested in one end-to-end academy scenario.Turn statements into acceptance checks
Replace “easy attendance” with a testable sentence such as: a teacher opens today’s class, marks each learner present, absent, or excused, adds a note, and the admin sees the update immediately. This is how everyone agrees what “finished” means.
Ready to move on when: Every important feature has a visible result that can be demonstrated.A realistic example
Imagine an academy with eight teachers and learners across three time zones. A student misses Tuesday, the teacher marks the absence, the parent receives a notice, the class appears in the admin follow-up list, and finance still knows whether that lesson is billable. That one scenario touches schedule, attendance, communication, permissions, and finance. It is a better requirement test than a list of colourful dashboard widgets.
Where people usually make the wrong turn
Copying a feature list from another LMS without checking whether your academy uses the same workflow
Copying a feature list from another LMS without checking whether your academy uses the same workflow. Stop, identify the decision that is missing, and correct the source of the problem before adding more tools or content.
Leaving time zones, cancellations, discounts, and permissions until development is nearly finished
Leaving time zones, cancellations, discounts, and permissions until development is nearly finished. Stop, identify the decision that is missing, and correct the source of the problem before adding more tools or content.
Writing requirements as visual requests such as “make a modern dashboard” instead of operational outcomes
Writing requirements as visual requests such as “make a modern dashboard” instead of operational outcomes. Stop, identify the decision that is missing, and correct the source of the problem before adding more tools or content.
How to know the work is improving
Do not collect numbers simply because a dashboard can show them. Pick a small set that reflects the outcome and review it on a schedule long enough to make a sensible decision.
- Fewer questions and reversals during development
- Every core workflow passes a written acceptance test
- Staff can complete daily work without parallel spreadsheets
We can review the current setup, clarify the workflow, design the customer-facing experience, build the required system, and support the work after launch.
Before you call it finished
- The main decision and responsible owner are written down.
- The mobile journey has been completed from beginning to end.
- Claims, prices, dates, links, and permissions have been checked by the right person.
- Tracking measures the intended outcome rather than activity alone.
- Someone owns maintenance, review, and follow-up after launch.
Questions people ask before starting
How long should an LMS requirements document be?
Long enough to remove operational guesswork. A focused academy may need 10 to 20 well-structured pages plus role and workflow tables; complexity matters more than page count.
Should a developer write the requirements?
The developer can structure and challenge them, but academy staff must explain the real rules. Good requirements are created together.
Can requirements change later?
Yes. Keep a controlled change list, note the effect on budget and schedule, and protect the first release from endless additions.
References and further reading
Policies and platform features change. Use these sources to verify requirements that affect your implementation, then apply them to the real business context.