Write IT Acceptance Criteria a Public-Sector Team Can Test

An acceptance statement such as ‘the system works’ leaves the supplier and service owner to negotiate its meaning at the end of delivery. A testable requirement names the user, task, expected result, and conditions. Build the record around representative service journeys, including exceptions and accessibility needs. Separate a failed result from a test that could not be run. Confirm the responsible procurement and service reviewers before using the criteria in a delivery decision.

Start with a service result

Choose a representative transaction: submitting an application, receiving an acknowledgement, finding the submitted record, or completing an authorized staff review. State the expected result in language the service owner can evaluate. Federal performance-based service acquisition under FAR Subpart 37.6 uses measurable performance standards and assessment methods. That is a useful reference for covered federal work; state, local, grant, and other procurements need their own applicable requirements and contract review. The working method here is a proposed acceptance approach rather than a universal procurement rule.

Make the conditions explicit

Record the test environment, representative data, roles, supported channels, dependencies, and prerequisites. A journey that works only for a project administrator may fail for a member of the public. Include authorized and denied actions, error handling, and the routes people use when a service is unavailable. Agree on relevant accessibility and security assessment responsibilities with qualified owners. Avoid claiming that one successful browser test establishes accessibility compliance or that a functional demonstration covers every security requirement.

Agree on the record before the demonstration

Use a short test sheet with requirement identifier, setup, operator, expected result, observed result, evidence location, and disposition. Attach a protected screenshot, transaction record, log extract, or other suitable observation. A reviewer should be able to trace the result back to the requirement without relying on the delivery team’s narration. NIST SP 800-53A describes security and privacy control assessment; keep those assessments connected to, but distinct from, the broader functional acceptance plan. The person signing for service delivery should know which conclusions remain outside the exercise.

Decide what happens when a test fails

Agree on severity and retest authority before the acceptance meeting. Some failures stop release; others may receive a documented, time-limited disposition from the authorized customer. Name the decision-maker and the effects on payment, rollout, support, or milestones according to the actual contract. Preserve successful results as well as failures, and rerun tests affected by a correction. The handover should identify operating responsibilities, support contacts, remaining actions, and a route to the test evidence after the project team moves on.

Put the plan into practice

1. Select the journey Ask the service owner to define the outcome and representative roles.
2. Write the observation Pair each requirement with its conditions, expected result, and evidence.
3. Rehearse acceptance Have a customer reviewer execute one test without informal delivery-team help.

Worked example

What a useful outcome looks like

Accept the defined scope only through the agreed authority. Preserve the test record, open-item decisions, retest results, and the operating handover so later changes can be compared with a known baseline.

Try the criteria on one completed feature with a reviewer who did not write them. Revise any statement that still depends on an undocumented interpretation.

References

• FAR Subpart 37.6: Performance-Based Acquisition
• NIST SP 800-53A: Assessing Controls