A Practical Guide To Writing Acceptance Criteria For Government Software

Government software succeeds when it works for real people, under real conditions, with evidence that can withstand review. Acceptance criteria turn a broad requirement such as “make applications easier” into observable statements that a delivery team, business owner and tester can assess in the same way.

This matters in Australia, where a digital service may serve a city resident in Melbourne, a remote community in the Northern Territory, a small business in regional Queensland and an internal officer in Canberra. Each group can face different connectivity, accessibility, language and service-channel needs. Well-written criteria make those differences visible before they become production problems.

Define The Public Outcome First

Start with the result the service must provide, rather than the screen, database field or software component a supplier intends to build. A useful outcome might be that an eligible person can submit a grant application online, receive a clear acknowledgement and check its progress without calling an agency.

This keeps acceptance criteria connected to public value. A requirement for “a dashboard with five widgets” says little about whether an officer can identify overdue cases. A criterion such as “an authorised case officer can filter open applications by due date and export the results in a readable format” describes behaviour that can be tested.

Write the outcome in plain English before adding technical detail. Public-sector teams often work across policy, operations, legal, procurement and technology. Clear language helps each group recognise what it is agreeing to, rather than leaving the meaning to a vendor’s interpretation.

Turn Policy Into Observable Behaviour

Legislation, ministerial directions, security rules and agency policy are essential sources, but they are rarely acceptance criteria in their original form. Translate each obligation into an action, condition and expected result. The reader should be able to decide whether the requirement has passed by examining the system and its evidence.

For example, “protect personal information” is too broad to test. A stronger version might state: “When a user without the case-access permission attempts to open a record, the system denies access, records the event with the user ID and timestamp, and displays a non-disclosing error message.” This gives developers, testers and auditors something concrete to verify.

Avoid hiding several outcomes inside one long sentence. Privacy, accessibility, audit logging and performance may belong to the same feature, but they should generally have separate criteria. Splitting them reduces arguments during user acceptance testing and makes defects easier to trace back to a source requirement.

Acceptance criteria should also identify exceptions. What happens when an applicant submits an incomplete form, a payment service times out or an identity provider is unavailable? Government systems need safe and understandable failure behaviour, not just a successful “happy path”.

Include Australian Service And Delivery Realities

A government service may need to work with myGov, state or territory identity services, payment gateways, records systems and agency-specific registers. These dependencies should appear in the criteria where they affect user outcomes. If a service relies on an external identity provider, state what the user sees when authentication succeeds, fails or is temporarily unavailable.

Accessibility needs practical treatment. Criteria can require keyboard operation, meaningful focus order, text alternatives, readable error messages and compatibility with common assistive technologies. They should also cover mobile use, because many people access services through a phone rather than a desktop computer. A form that technically loads but loses entered data on a small screen has not delivered a reliable service.

Connectivity is another local consideration. A person in regional Western Australia or a remote Northern Territory community may experience intermittent mobile coverage. A sensible criterion might require draft data to remain available after a temporary connection loss, with clear status information and no duplicate submission when the connection returns.

Procurement and governance also shape delivery. A state department, local council and Commonwealth agency may use different approval gates, hosting arrangements and records policies. Refer to the relevant authority, such as the Australian Signals Directorate’s Essential Eight guidance or an agency security standard, where applicable, instead of assuming a supplier will infer the requirement.

Acceptance style	Example	Evidence of passing	Common weakness
Outcome-based	An applicant can submit a complete permit application and receive a reference number	Demonstrated journey, saved record and notification	May need extra detail about exceptions
Rule-based	Applications over the delegated limit are routed to a senior approver	Test record, workflow log and approval history	Can become rigid if policy changes
Scenario-based	Given a connection loss during submission, when the user reconnects, then no duplicate application is created	Automated or observed scenario test	Often misses accessibility and security
Non-functional	Ninety-five per cent of dashboard searches return within three seconds under agreed load	Performance test report	Requires a defined environment and measurement method
Evidence-based	Every privileged record change is attributable to a named account	Audit-log inspection and access review	Evidence may be difficult to retrieve later

Use A Consistent Criteria Pattern

A practical format is “Given, When, Then”. “Given” establishes the starting condition, “When” describes the action or event, and “Then” states the observable result. For example: “Given an approved supplier record, when an authorised officer changes the bank account, then the system requires step-up authentication and records the old and new values.”

The pattern is helpful because it separates assumptions from behaviour. It also supports automated testing when appropriate, although criteria do not need to become code. A manual check, a records inspection, a security assessment or a demonstration can all provide suitable evidence.

Use precise terms such as “must”, “may” and “must not” consistently. Avoid words such as “quickly”, “user-friendly” and “appropriate” unless they have a measurable definition. Replace “the page loads quickly” with “the search results display within three seconds for the agreed test volume and network profile”.

Keep each criterion focused on one decision. If a single criterion contains login, notification, reporting and retention rules, it will be difficult to tell which part failed. A small set of precise statements is usually stronger than a large paragraph of general expectations.

Separate Functional And Quality Conditions

Functional criteria describe what the service does: create an application, calculate a fee, route a request, issue a notice or permit a caseworker to update a record. Quality criteria describe how reliably and safely it must do that work. Both are required for a government release.

Security criteria should cover identity, permissions, session handling, secrets, logging and incident-relevant events. A role-based access rule might state that a contractor can view assigned cases but cannot bulk-export personal information. A separate criterion can require access changes to take effect within a defined period after an account is disabled.

Performance needs a clear workload and measurement point. “The system must scale” cannot be accepted without agreed transaction volumes, response targets and test conditions. Include peak periods, such as grant openings, licence renewals or disaster-relief applications, if those events are foreseeable.

Retention and records management deserve equal attention. A criterion can specify that a decision record, its supporting documents and the approval history are retained according to the agency schedule, while temporary drafts are removed under a separate rule. This prevents a new application from creating uncontrolled copies of sensitive information.

Build Useful Lists For Review

A short review list helps the product owner and delivery team identify gaps before the criteria reach development.

• Is every statement observable, testable and linked to a real user or policy outcome?
• Does each criterion define the expected result, including important error paths?
• Are privacy, security, accessibility, records and performance addressed where relevant?
• Is the evidence required for acceptance clear to both the agency and supplier?

A second list can support the final walkthrough with business representatives, testers and operational staff.

• Can a person with the required role complete the task without hidden manual intervention?
• Can the team reproduce a failure and confirm the system’s recovery behaviour?
• Can the agency retrieve logs, reports or screenshots needed for assurance?
• Has the criterion been checked against the agreed scope and change-control process?

These checks are especially useful in large programs where a criterion may be copied into a contract, sprint backlog, test script and release decision. Consistent wording reduces the risk that each document develops a different interpretation.

Connect Criteria To Evidence And Sign-Off

Every important criterion should have an evidence path. The evidence might be a test result, screen recording, audit-log extract, accessibility report, penetration-test finding, performance report or signed business demonstration. Decide who reviews it and where it will be stored before acceptance begins.

Traceability is valuable when a program faces a defect, audit query or scope dispute. A requirement ID can connect a policy source to a user story, acceptance criterion, test case and release decision. This does not require a complicated tool; a well-managed register or delivery platform can provide the link.

Business users should participate early, especially staff who understand unusual cases. A Centrelink-style service interaction, a council permit workflow and a national licensing platform can have very different operational pressures. Asking frontline staff to review scenarios often reveals missing delegation rules, confusing messages or unnecessary data collection.

Do not treat sign-off as a ceremonial tick. Acceptance means the agreed conditions have been demonstrated, exceptions have been recorded and any remaining risk has an owner and a decision. If a criterion is changed after testing starts, document the reason, impact and approval rather than quietly rewriting the target.

Clear acceptance criteria give government teams a shared definition of “done” before money is spent and public users are affected. For broader reference on digital governance, ICT management and related public-sector technology topics, consult the E-Pragati resource hub alongside your agency’s official standards and policies.

Use the same discipline for content and external links within a public website. If a publishing workflow permits a page about entertainment or gaming, for example, its criteria should verify approved destinations, link labels, accessibility and content ownership; a Coin Master spins page should not appear in an official service area merely because it was pasted into a draft.

Write criteria while the requirement is still being shaped, then test them with the people who will build, operate and use the service. When each statement describes an outcome, a condition and credible evidence, acceptance becomes a practical control for quality rather than a last-minute argument. Use this approach on the next government software initiative, and make every release decision easier to explain, verify and defend.