How to Define Acceptance Criteria in a Software Development Specification

Acceptance criteria in a software development specification should be written so that each requirement can be checked unambiguously and produce a result of either “compliant” or “non-compliant.” To achieve this, a criterion should describe the initial conditions, the action or event, the expected result, and, where relevant, a measurable threshold such as time, volume, accuracy, an acceptable number of errors, or another verifiable value.

What Should Be Defined Before Writing Acceptance Criteria

First, define the acceptance object. This may be an individual feature, a user scenario, an API, an integration, a report, an interface, a data migration, or the entire release. A common mistake is to write a single general criterion such as “the system works according to the specification”: this wording does not define how the result should be verified and does not make it possible to identify where a non-conformity occurred.

For each acceptance object, it is useful to have:

• an identifier or reference to the requirement;
• a description of the required behavior;
• the conditions required for verification;
• test data or rules for preparing it;
• the expected result;
• acceptable deviations, if any;
• a method for recording the verification result.

If some of this information is defined in other sections of the specification, the criterion may refer to them. However, the reference should point to a specific section, requirement, or identifier rather than to the document as a whole.

Step 1. Link the Criterion to a Specific Requirement

An acceptance criterion should not exist separately from a requirement. It is useful to assign identifiers to requirements, for example FR-01 for functional requirements and NFR-01 for non-functional requirements, or to use a single continuous numbering scheme.

For example, the original requirement:

FR-12. An authenticated user can change the email address in their profile.

Separate verifiable criteria should then be added for the successful scenario and significant error cases. There is no need to list every conceivable input variation: it is sufficient to cover behavior that is actually part of the requirements.

Step 2. Specify the Initial Conditions

The person performing the verification should understand the state of the system before the action is performed. Depending on the feature, this may include the user role, the existence of a database record, the order status, access permissions, the connection of an external system, or preconfigured data.

Poor wording:

“The user can change the email address.”

Verifiable wording:

“Provided that the user is authenticated and the profile editing section is open, the user can enter a new valid email address and save the changes.”

Conditions should be included only when they affect the result. There is no need to turn every criterion into a complete description of the test infrastructure.

Step 3. Describe One Verifiable Action

A criterion is easier to verify when it is centered on a single user action or a single system event. The wording “the user creates an order, pays for it, receives an email, and the administrator sees the order in the dashboard” actually contains several separate checks.

Split such a scenario, for example, into the following criteria:

• the order is created after a correctly completed form is submitted;
• after confirmed payment, the order receives the status specified by the requirements;
• after the specified event occurs, a notification is generated;
• the created order is available in the administrative interface to a user with the appropriate permissions.

This makes it clear which specific criterion has failed if one component does not work as expected.

Step 4. Define an Observable Result

The expected result must be available for verification. Terms such as “correctly,” “conveniently,” “quickly,” “with high quality,” or “displays normally” are not verifiable on their own.

Instead of:

“After saving, the system correctly updates the profile”

write:

“After a valid new email address is saved, the value in the profile field is replaced with the entered value and remains saved after the profile page is reopened.”

This criterion defines an observable effect and a way to verify that the change did not remain only in the current interface state.

Do not include an assumed implementation in an acceptance criterion unless that implementation is itself a requirement. The wording should verify the required outcome rather than force the contractor to use a specific database table, library, algorithm, or internal component without a separate technical justification.

Step 5. Replace Subjective Terms with Measurable Conditions

If a requirement concerns performance, volume, accuracy, or constraints, the value and the conditions under which it is measured must be defined in advance. For example, the phrase “the page should load quickly” does not establish a boundary between an accepted and a rejected result.

A measurable criterion can use the following structure:

“Under conditions X, operation Y must complete within no more than Z, measured using method M.”

The values of X, Z, and M must come from the project requirements. They should not be assigned arbitrarily merely to make the criterion formally measurable. If the customer has not yet defined an acceptable response time or load, this should be recorded as an unresolved requirement and agreed upon before acceptance testing.

The same principle applies to file size limits, record counts, calculation accuracy, acceptable error rates, and other numerical metrics.

Step 6. Describe Negative Scenarios That Affect Acceptance

For features involving user input, authentication, external integrations, or data modification, a single positive scenario is usually insufficient. Expected behavior should also be defined for at least those errors that follow directly from the requirements.

For example, the criteria for changing an email address may be separated as follows:

1. A valid value is saved.
2. A value that does not comply with the defined format rules is not saved, and the user receives the specified error message.
3. A user without the required authorization cannot access the data modification operation.

Do not invent message text, HTTP status codes, or a format validation mechanism if these are not defined by the requirements. Acceptance criteria should clarify agreed behavior rather than silently expand the scope of development.

Step 7. Remove Ambiguous Dependencies

The wording should make it possible to prepare a verification procedure without guesswork. Pay attention to phrases such as “if necessary,” “usually,” “preferably,” “where possible,” “and so on,” “appropriate,” and “correct.” If the text does not make it possible to determine a specific condition, replace such wording with a reference to a rule or an explicit description.

For example:

“The administrator receives a notification if necessary”

does not define when the notification should be sent. If a rule exists, it should be named:

“When the request transitions to the status specified in requirement FR-24, a notification is generated for a user with the administrator role.”

If the triggering event has not yet been defined, the problem lies in the requirement itself and should be resolved before the final acceptance criterion is written.

Step 8. Choose a Consistent Recording Format

For a small specification, a numbered list is sufficient. For a project with dozens of requirements, a table is more convenient because it preserves traceability between requirements and verification checks.

Example entries not tied to any specific project:

Step 9. Separate Acceptance Criteria from the Acceptance Procedure

An acceptance criterion answers the question, “What result is considered compliant with the requirement?” The acceptance procedure answers questions such as “Who performs the verification?”, “In what environment?”, “Using what tools?”, “How are issues recorded?”, and “What happens after a non-conformity is found?”

This information can be placed in a separate section of the specification or in an appendix. For example, it may define:

• the contents of the delivered version;
• requirements for the test environment and data;
• responsible parties;
• the format of the verification report;
• rules for recording defects and performing retests;
• the procedure for documenting the final acceptance result.

This separation prevents functional requirements from being mixed with organizational conditions of the contract or project.

Step 10. Review the Criteria Before Approving the Specification

A useful editorial review method is to mentally execute each criterion exactly as written in the document. If verification requires asking the specification author an additional question, the criterion or the related requirement probably lacks an essential condition.

For each criterion, check the following in sequence:

1. Is it clear which requirement the criterion relates to?
2. Is the initial state defined where it affects the result?
3. Is the action or event to be performed clear?
4. Is there an observable expected result?
5. Can compliance be determined unambiguously?
6. Are numerical limits specified where the result would otherwise remain subjective?
7. Has the criterion introduced a new requirement that is not part of the agreed scope of work?
8. Does the criterion unnecessarily prescribe an internal implementation instead of an external outcome?

Practical Acceptance Criterion Template

For most functional requirements, the following structure can be used:

Criterion ID: AC-XX.Y

Related requirement: requirement identifier.

Preconditions: system state, user role, and required data.

Action: one specific user action or system event.

Expected result: the observable state that must occur after the action.

Constraints: measurable limits and acceptable deviations, if defined by the requirements.

Verification method: actions sufficient to confirm the result, if they are not obvious from the criterion.

The template does not require every field to be completed formally. For example, a separate constraints field may not be necessary for simple interface behavior. What matters is that the fields as a whole eliminate significant guesswork during verification.

Common Mistakes

• “The function should work correctly.” The required result is not defined.
• “The interface should be user-friendly.” There is no verifiable measure of usability.
• “The response should arrive quickly.” The acceptable threshold and measurement conditions are not defined.
• “All errors should be handled.” It is not defined which situations are mandatory scenarios or what behavior is expected.
• One criterion for a large business process. It becomes impossible to identify the exact point of non-conformity.
• The criterion contains a new feature. The scope of work is expanded through the acceptance section instead of by changing the requirements.
• The criterion prescribes internal architecture. The implementation is unnecessarily constrained even though the acceptance object is the resulting behavior.

Final Checklist

• Each significant criterion is linked to a specific requirement.
• The criterion describes a verifiable result rather than a subjective assessment.
• Preconditions are specified for important initial states.
• Each criterion corresponds to one clear action or event.
• Numerical constraints are specified only where they have been agreed in the requirements.
• Expected behavior is defined for significant error scenarios.
• The text contains no undefined wording that could affect the acceptance decision.
• The criteria do not introduce hidden features or unjustified technical constraints.
• The organizational acceptance procedure is separated from compliance criteria.
• Each criterion can produce an unambiguous result of either “compliant” or “non-compliant” without additional agreements.

If, after this review, two independent project participants can interpret the conditions in the same way, perform the verification, and reach the same result, the acceptance criteria are defined precisely enough for practical use in a software development specification.