How to write acceptance criteria for custom software
Acceptance criteria for custom software name an outcome someone can observe, the person who owns it, and whether a demo or user acceptance will show it. The list comes before the demo, so the demo and the acceptance meeting follow one list. A sentence with no outcome and no owner stays off the acceptance list.
On this page
What one criterion has to name
Each line names three things: what someone else can see when the step is done, who owns that line, and whether a demo or user acceptance will show it. A line joins the list when all three are present.
ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering, was published as edition 2 in November 2018. The ISO catalogue page says this edition was reviewed and confirmed in 2024, so this version remains current, and that it is expected to be replaced by ISO/IEC/IEEE DIS 29148 within the coming months. The life-cycle table marks 16 February 2026 as the date the international standard moved to “to be revised”. The standard specifies the information items the requirements processes produce, and the required contents of those items, and it applies regardless of project scope, methodology, size, or complexity. The IEEE page says the standard was published on 30 November 2018, lists the status Active Standard, and says it defines the construct of a good requirement, provides attributes and characteristics of requirements, and discusses iterative and recursive application through the life cycle. This note does not copy characteristic adjectives that those official pages do not list, and it does not quote a price. When a buyer writes acceptance, each line becomes an observable outcome, an owner, and the way it will be shown.
Run the demo from the same list
Before the demo, the person running it reads the criterion number and the expected outcome, then performs the step. People in the room check whether that outcome appeared. A tour of screens with no criterion number does not stand in for the list.
A criterion the demo cannot show stays on the list, marked as not shown and why. A change to a criterion goes back into the list, and the next demo uses the new line. Editing the line on the spot so that it matches whatever just happened removes the baseline for the next round.
Run acceptance from the same list
The user-acceptance script is that same list, now run by the owner of each line, or signed by that owner in the room. A line whose owner is absent waits until the owner is present before it counts as passed.
Edge cases are their own lines: an empty input, a duplicate submit, a missing permission, a record that already exists. A list with only the smooth path can pass every line and still miss the failure the buyer cares about. Add the missing edge, then schedule the next acceptance.
How a criterion fails
“Easy to use”, “stable”, or “fast”, with no outcome someone can observe, is not yet a criterion. If you have no measurement of your own, with a date, leave seconds out of the line. Rewrite it as something a person can see: the owner finishes the named step on the named screen and leaves a record.
A line with no owner has nobody to sign it when the demo ends. A line that names a class, a package, or an algorithm is void as soon as the implementation changes while the outcome still holds. Keep the implementation in the design note. Acceptance keeps the outcome, the owner, and how it will be shown.
When a shorter list is the right list
Skip a separate line for every label, colour, and internal function. A demo cannot walk those sentences, and an owner will not sign them one by one. Keep the count to what one demo or one acceptance meeting can actually walk.
While the owner is still unnamed, leave the list short. Name the person first, then add the lines that person will sign. Edge cases belong in acceptance. The internal implementation stays in the design note.
Keep the list with the build you accept
When a criterion changes, the demo script and the acceptance script change in the same edit. The acceptance record names the software version it was checked against. Keep that version in the Git history the team already uses, or in an equivalent record, so a later reader can see which build was signed.
When the software keeps rental records, the lines have to match the record types already written down. That is covered in How to choose an equipment rental management system. The delivery scope sits under Custom software, websites, and applications.
When to postpone the meeting
When lines still say “easy to use”, edge cases are missing, or the owner will not be in the room, postpone the acceptance meeting. Fix the list, then set the time.
This note does not state a defect count, a contract term, or a service level. Those figures have to come from your own acceptance records, with the definition written down. Until that record exists, check the meeting by whether every line has an outcome, an owner, and a way to show it, and whether the demo and the acceptance walk the same list.