Requirements framework for exams, gradebooks, and report cards

1. Define the requirements boundary

List subjects, cohorts, campuses, grading periods, assessments, components, attempts, users, reports, integrations, learner or family views, support windows, and archive needs.

Classify each requirement as an outcome, workflow, data definition, calculation, permission, report, integration, accessibility, privacy, safeguarding, security, records, continuity, support, cost, or exit requirement.

2. Describe the work requirements

Specify assessment setup, submission, marking, rubric, feedback, missing and late handling, moderation, approval, publication, report production, correction, resit, special consideration, withdrawal, transfer, and archive.

For each, state trigger, actor, record, decision, deadline, handoff, exception, evidence, acceptance test, and owner. Avoid requirements such as “easy to use” without a task and observable result.

3. Define the information model

Define assessment, component, attempt, submission, mark, grade, percentage, scale, weighting, rounding, boundary, comment, absence, late, missing, exempt, pending, moderated, approved, published, and corrected.

Record source, allowed values, validation, duplicate, missing, transfer, withdrawal, version, correction, report use, retention, and effective date. The U.S. Department of Education data-quality guidance connects reliable information with definitions, rules, validation, infrastructure, and learning.

4. Define calculation and moderation

Specify component relationships, weighting, rounding, grade boundaries, resits, special consideration, missing values, exceptions, moderation sample, adjustment, disagreement, approval, history, and report effect.

Require test cases for ordinary, boundary, missing, late, absent, amended, duplicate, moderated, withdrawn, and changed-period results. Record expected output, evidence, version, and approver.

5. Define control and user experience

Map view, create, mark, review, moderate, approve, publish, export, correct, archive, and delete by role, subject, cohort, campus, learner, family, supplier, and support user.

Require accessible labels, keyboard or assistive-technology support where applicable, readable dates and scales, meaningful errors, alternative formats, language support, device access, recovery, and a safe correction route.

6. Define reporting and integration

Specify report audience, population, period, source, refresh, calculation, missing values, correction window, version, finalisation, export, communication, accessibility, and reconciliation.

For integrations, define identity, subject, cohort, assessment, component, mark, grade, status, event time, effective time, retry, duplicate, rejection, conflict, replay, failure, audit, and owner.

7. Define lifecycle and governance

The U.S. Department of Education data governance checklist covers quality, access, security, lifecycle, sharing, disposal, and monitoring. Include collection, use, moderation, approval, publication, correction, export, archive, retention, disposal, backup, restoration, incident, supplier, and exit.

GOV.UK guidance emphasises accountable and secure handling of school data. Apply qualified local assessment, privacy, safeguarding, security, records, accessibility, and legal review.

8. Prioritise and review

Use hard gates for assessment integrity, calculation, privacy, safeguarding, accessibility, security, continuity, records, and data return. Rank remaining requirements by decision value, risk, effort, and evidence.

At 30, 60, and 90 days, review completeness, corrections, moderation, report confidence, staff effort, support demand, access exceptions, continuity, and outcome. Update requirements only through controlled change.

Turn the guidance into an accountable decision

Apply this guidance to one bounded part of requirements framework for school exam and gradebook software. Define the assessment or reporting decision, authoritative record, accountable owner, permitted users, correction route, evidence, and review date.

Test an ordinary assessment and meaningful exceptions such as a missing submission, late work, absent learner, moderation change, amended result, withdrawn learner, duplicate mark, grading-period change, report correction, access failure, or outage.

Keep supplier capability, school responsibility, professional judgement, local policy, legal advice, and measured outcome separate. If evidence is incomplete, narrow the claim and pilot the smallest safe change.

Review at 30, 60, and 90 days. Check completeness, timeliness, consistency, moderation, corrections, access exceptions, staff effort, support demand, reporting confidence, and the original outcome. Decide whether to expand, repair, consolidate, narrow, or hold.

Before approval, ask a reviewer who was not involved in the design to challenge the strongest assumption. Replace broad language with the exact evidence, population, date, and limitation the school can verify.

Document what was tested and what was not. A successful demonstration with a simple gradebook does not establish readiness for moderation, resits, special consideration, changed grading periods, multiple campuses, or a changed assessment policy.

Keep evidence beside the decision record so a later reviewer can distinguish observed behaviour from an assumption, estimate, or supplier statement. Name the next test where evidence remains incomplete.

Revisit the boundary when the school adds a subject, year group, campus, grading scale, role, integration, reporting period, or policy. A small change can alter permissions, definitions, calculation, timing, retention, or support demand.

Set the next review date and owner. A dependable exams and gradebook operation is maintained through clear definitions, controlled change, professional judgement, and visible accountability rather than a one-time setup.

Make the handoff readable to a teacher, administrator, leader, learner, family, and reviewer. State what passed, what remains manual, which records are authoritative, who owns unresolved conflicts, and how a correction is communicated without creating an uncontrolled copy.

Keep approved definitions beside calculation rules, moderation notes, training, support routes, and change history. New subjects, scales, integrations, or reporting windows can change the risk even when field names stay the same.