School management software requirements framework

Start with a requirement sentence

Write each requirement as an observable behavior: “The admissions team can review an application, record a decision, and hand the accepted student to enrollment without retyping the identity.” This is stronger than “Admissions module required” because it tells the vendor and the school what must be demonstrated.

Category 1: workflow requirements

Map the trigger, actor, record, action, approval, exception, output, and next owner. Cross-functional workflows should be tested end to end. A module-by-module list can miss the handoff where the actual operational risk lives.

• Admissions and enrollment
• Student and guardian records
• Academic setup and calendar
• Attendance, assessment, and publishing
• Fees, payments, receipts, and reconciliation
• Staff, leave, and payroll boundaries
• Family communication and portal visibility

Category 2: data-quality requirements

Specify required fields, validation, duplicate detection, correction ownership, imports, exports, history, retention, and reporting definitions. The U.S. Department of Education’s data quality guidance emphasizes business rules, validation processes, infrastructure, and professional learning as part of dependable data—not just a technical upload.

Ask how the system signals an exception. A clean-looking dashboard is not proof that the underlying data is complete or accurate.

Category 3: access, privacy, and security requirements

Define access by role and scenario. Include least-privilege expectations, staff changes, family boundaries, sensitive fields, audit records, exports, incident handling, and vendor responsibilities. Local law and the school’s data protection officer determine the final requirements.

GOV.UK procurement guidance recommends reviewing security, subprocessors, data return or deletion, breach notification, and staff access control before signing. Treat these items as requirements with evidence, not assurances.

Category 4: implementation and support requirements

Require named responsibilities for data mapping, migration, training, testing, configuration, integrations, support, and go-live. Include response expectations, escalation, documentation, and what happens when a critical acceptance test fails.

Tie dates to the academic calendar and define a rollback or hold decision. A plan that ignores term dates is incomplete even if its task list looks thorough.

Score evidence, not enthusiasm

Use a scorecard with columns for requirement, priority, demonstration evidence, source or recording, owner, risk, and decision. Mark native behavior, configuration, integration, manual workaround, roadmap, and unknown separately.

Review the scorecard with the people who own the work. Procurement can coordinate the decision, but admissions, academics, finance, families, IT, and leadership must validate their own critical workflows.

Set the scoring rule before demonstrations begin. For example, make must-have requirements a pass-or-risk decision and use weighted scores only for trade-offs among requirements that are already proven. A high average should never hide one unresolved identity, access, payment, or publishing failure.

Make the requirements reusable

Store the framework with the requirements, evidence register, test data assumptions, and approval record. When the school adds a campus or changes its calendar, the team can update the affected scenarios instead of starting a new vendor conversation from scratch.

Review requirements after the first phase. Some requests will become less important when a workflow is clarified; other needs will emerge from real use. The framework should support learning rather than freeze the school into its original assumptions.

Use versioned requirement IDs so a changed definition does not silently overwrite the evidence for an earlier decision. Keep the old wording, the reason for change, and the owner who approved the new interpretation.

Link each requirement to an acceptance test and a named owner. When a requirement is challenged later, the team can inspect the evidence and decide whether the behavior changed, the requirement changed, or the original assumption was incomplete.