How to Write Unambiguous Acceptance Criteria in a Technical Specification

Acceptance criteria in a technical specification should be written so that the customer and the contractor can independently verify the same result and reach the same conclusion: the requirement is either met or not met. Each criterion should therefore describe the object being verified, the initial conditions, the action, the expected result, and the method used to record the result.

What Counts as an Acceptance Criterion

An acceptance criterion is a verifiable condition used to accept an individual feature, a project stage, or the entire project result. It should not describe an intention, overall quality, or a subjective impression.

Poor wording:

The system must work quickly and correctly and be convenient for users.

This statement does not define what qualifies as fast performance, which actions must be tested, which errors are acceptable, or who evaluates usability. It cannot serve as the basis for an unambiguous acceptance report.

Verifiable wording:

“After submitting the registration form, the user receives a message confirming that the account has been created successfully. The entered email address appears in the user record in the administration panel. If registration is attempted again with the same address, the system rejects the request and displays the message ‘A user with this address is already registered.’”

Step 1. Separate Requirements from Verification Criteria

Do not mix the feature description with the acceptance procedure. A technical specification can conveniently use two related sections:

• Functional requirement — what the system must do or what the work result must contain.
• Acceptance criterion — how to confirm that the requirement has been implemented.

Example:

If one requirement has several scenarios, document them as separate criteria. Do not combine the success path, input errors, access restrictions, and boundary conditions into one long paragraph.

Step 2. Use a Consistent Criterion Structure

The “Given — When — Then” structure works for most tasks. It separates test preparation from the action and the expected result.

• Given — the system state, user permissions, initial data, and required settings.
• When — a specific action performed by the tester.
• Then — an observable result.

Example:

Given: the user is signed in with the “Editor” role, and the document has the “Draft” status.

When: the user clicks the “Submit for Approval” button.

Then: the document status changes to “Pending Approval,” content editing is disabled, and an entry containing the date, time, and user identifier appears in the event log.

The structure can be presented as a table, a numbered scenario, or separate subsections. The important point is to use one format consistently throughout the document.

Step 3. Describe the Exact Initial Conditions

The verification result depends on the system state. Therefore, phrases such as “open the page” or “enter data” are not sufficient. Specify everything that affects system behavior:

• the user’s role and permissions;
• the object status;
• the presence or absence of related records;
• the type and format of input data;
• required settings;
• the test environment, if it differs from the production environment;
• actions that must be completed in advance.

Poor version: “A warning appears when an order is deleted.”

Refined version: “If a user with the ‘Manager’ role opens an order with the ‘New’ status and clicks ‘Delete,’ the system displays a confirmation dialog containing the order number and the ‘Delete’ and ‘Cancel’ buttons.”

If a criterion applies only under a specific condition, state that condition explicitly. Do not rely on implied context from adjacent sections.

Step 4. Replace Subjective Terms with Measurable Conditions

Words such as “fast,” “convenient,” “high-quality,” “stable,” “modern,” “clear,” “correct,” and “error-free” cannot be used as standalone criteria. They are acceptable only when accompanied by a measurable definition.

Do not invent numerical limits. If the customer has not defined the acceptable response time, file size, calculation accuracy, or number of concurrent users, record the item as an open question instead of inserting an arbitrary value.

Step 5. Specify an Observable Result

A criterion should describe something that can be seen, retrieved from the system, or confirmed by a document. The phrase “the data is processed” is insufficient because it does not identify an external result.

Use observable indicators:

• the object status has changed;
• a record has appeared in the interface;
• a file with the specified fields has been created;
• a notification has been sent;
• access has been granted or denied;
• a specific error message has been displayed;
• the value has been saved and remains unchanged after the item is reopened;
• the event has been recorded in the designated log.

For each result, specify where it must be verified. For example, a record may be checked on the object details page, in the operation log, in an exported report, or in a received notification.

Step 6. Record the Input Data and Expected Values

If the result depends on a calculation, transformation, or format validation, add a reference example. It should contain the input data, the processing rule, and the expected result.

Example criterion for a calculation:

1. The order contains one item with a quantity of 3 and a unit price of 500 rubles.
2. No discount, tax, or delivery fee is applied.
3. After the order is saved, the value of the “Total” field is 1,500 rubles.
4. After the order is reopened, the value remains unchanged.

A reference example does not replace the general rule. If the system must process different values, the technical specification should separately describe the formula, rounding, currency, handling of empty values, and handling of invalid data.

Step 7. Add Negative and Boundary Scenarios

Acceptance based only on the success path does not confirm error handling. For significant features, add separate criteria for the following situations:

• a required field is empty;
• an invalid format is entered;
• the user does not have the required permissions;
• the object has already been deleted or modified;
• an empty data set is submitted;
• the value is at an allowed boundary;
• the value exceeds an agreed limit;
• the same request is submitted repeatedly;
• a dependent system is unavailable.

Example:

“If a user without delete permission opens a contract record, the ‘Delete’ button is not displayed. A direct attempt to perform the operation through the designated integration interface is rejected. The contract remains available, and its status and contents do not change.”

Do not specify the exact text of a system error if it has not yet been agreed upon. In that case, describe the required meaning of the message and record the wording as a separate item for approval.

Step 8. Define the Evidence of Completion

In the criterion or in the general acceptance section, specify what evidence confirms the result. The appropriate evidence depends on the subject of the technical specification:

• an entry in the acceptance test report;
• a screenshot showing the relevant data;
• a generated file;
• an event log entry;
• a received email or notification;
• the result of an agreed test scenario;
• a signed inspection report for a document or piece of equipment.

A screenshot is not always sufficient. It confirms the appearance at a specific moment, but it does not prove that the data was saved, that a calculation is correct, or that access control works properly. Such cases require additional verification steps.

Step 9. Link Criteria to Requirements

Assign unique identifiers to requirements and criteria. This simplifies approval, testing, and issue tracking.

One criterion should verify a limited number of related results. If it simultaneously describes the interface, a calculation, a notification, access permissions, and logging, it should be split into separate criteria.

Step 10. Establish Decision Rules

The technical specification should contain a separate section that answers the following questions:

• who performs the verification;
• which environment is used for acceptance testing;
• which data is used;
• how the result is documented;
• what qualifies as an issue;
• which deviations block acceptance;
• how retesting is performed after a fix;
• whether a project stage can be accepted partially.

Example wording:

“A criterion is considered satisfied if the actual result matches the expected result in every listed step. A failed step is recorded in the report with the criterion identifier, a description of the actual result, and attached evidence. After the issue is corrected, the original criterion and the related scenarios are retested.”

Do not use the phrase “the work is accepted if there are no issues” without classifying the issues. A minor difference in a button label and data loss have different effects on whether the system can be used.

Ready-to-Use Acceptance Criterion Template

Example of a Completed Criterion

ID: AC-24.2.

Related requirement: FR-24 “Export Request List.”

Preconditions: the user is signed in and has permission to view requests; the list contains records for the selected period.

Test data: the period is defined by two agreed dates; the request numbers included in the period are known in advance in the reference data set.

Actions: the user specifies the period, applies the filter, and starts the export.

Expected result: the system generates a file in the designated format; the file opens in the standard viewer; it contains only the requests from the filtered list; the set and order of columns match the appendix to the technical specification.

Evidence: the exported file and an entry recording the result in the acceptance report.

Common Wording Errors

• Implicit comparison: “the new version works no worse than the old one” without a list of the compared features and metrics.
• Undefined actor: “the user is granted access” without specifying the role and the conditions under which access is granted.
• Unknown object: “the data is saved” without listing the fields and the location where the result is stored.
• Compound requirement: one criterion verifies several independent features.
• Missing negative result: only valid input is described, while behavior in case of an error is not specified.
• Reference to a verbal agreement: the expected behavior is absent from the technical specification and its appendices.
• Verifying implementation instead of the result: the criterion requires a specific internal development approach even though acceptance depends on the observable result.
• Unverifiable absolute statement: “the system never loses data” without conditions, boundaries, and a verification procedure.

Final Checklist

1. Each criterion has a unique identifier and a reference to the related requirement.
2. The exact preconditions, user role, and initial state are specified.
3. The actions are described as a reproducible sequence.
4. The expected result can be observed or confirmed by a document.
5. Subjective terms have been replaced with measurable indicators.
6. Numerical limits have not been invented; they have either been agreed upon or recorded as open questions.
7. Reference input data and expected values are provided for calculations.
8. Negative and boundary scenarios have been added.
9. The location and method used to record the verification result are defined.
10. The person responsible for acceptance and the process for documenting deviations are established.
11. Each criterion produces an unambiguous outcome: passed, failed, or blocked for a stated reason.