A software project is not complete simply because a developer says the feature is finished.

It is not complete because the application opens without an error.

It is not complete because the design looks correct.

And it is not complete because someone says, "It works."

A software project is complete when the agreed requirements have been implemented and the defined conditions for acceptance have been satisfied.

Those conditions are called acceptance criteria.

Acceptance criteria define what must be true for a feature, workflow, module, milestone or project to be accepted as complete.

They create a common answer to one of the most important questions in software development:

How do we know that this work is actually done?

Without clearly defined acceptance criteria, software projects can reach the testing or delivery stage only to discover that the client, developer and QA team have different ideas about what completion means.

A client may expect a workflow to support several edge cases.

A developer may consider the primary workflow finished.

A tester may identify behaviours that were never documented.

A project manager may consider the milestone complete based on the original estimate.

The software exists, but the definition of done does not.

Good acceptance criteria solve that problem by turning expectations into observable conditions.

This is the seventh guide in our pre-development documentation series, following the documentation checklist, technical documentation, the architecture document, the requirement document, the scope document, and the comparison of requirements, scope, specifications and SOW. Acceptance criteria are where all of that planning finally gets tested against reality: not "did we write it down," but "can we prove it was built correctly."

---

Quick Answer: What Should Software Project Acceptance Criteria Include?

A strong acceptance criteria definition should generally establish:

Acceptance Area	What It Defines
Feature or Deliverable	What is being accepted
Preconditions	What must be true before testing begins
User Action	What the user or system does
Expected Behaviour	What the software should do
Business Rules	Conditions the software must enforce
Success Conditions	What must happen for the feature to pass
Failure Conditions	What should happen when something goes wrong
Validation	How the result will be verified
Edge Cases	Important unusual scenarios
Permissions	Which users can perform the action
Data Conditions	Required input and expected output
Integration Behaviour	What happens when external systems are involved
Performance Expectations	Relevant response or processing requirements
Security Conditions	Security requirements that must be satisfied
Compatibility	Supported platforms or environments
Defect Threshold	Which outstanding issues prevent acceptance
Evidence	What demonstrates that the requirement has been satisfied
Approval	Who is responsible for acceptance

Not every feature requires every category.

A simple button interaction may need only a few criteria.

A payment workflow, enterprise integration or AI feature may require significantly more.

The objective is to make completion objectively understandable.

---

What Are Acceptance Criteria?

Acceptance criteria are specific conditions that a software feature, requirement or deliverable must satisfy before it can be considered accepted.

They answer:

What must happen for this requirement to be considered complete?

For example, the requirement might be:

Customers can reset their password.

The acceptance criteria could state:

• A registered user can request a password reset.
• The system sends the reset mechanism to the registered contact method.
• The reset mechanism expires according to the defined security policy.
• An expired reset request cannot be used.
• A valid reset request allows the user to create a new password.
• The system confirms successful completion.
• The user can authenticate using the new password.

Now the requirement has a measurable finish line.

---

Why Acceptance Criteria Matter

Without acceptance criteria, the word complete becomes subjective.

That is dangerous in software development.

Imagine a project requirement says:

Build a customer dashboard.

A developer creates:

• Revenue summary
• Recent orders
• Customer profile
• Activity history

The developer says:

Dashboard completed.

The client responds:

Where are the filters?

The developer says:

Filters weren't mentioned.

The client responds:

I assumed the dashboard would have filters.

Neither side necessarily intended to create a problem.

The problem is that the completion conditions were never defined.

Acceptance criteria force the team to answer those questions before the work is considered complete.

---

Acceptance Criteria vs Requirements

These two are related but different.

Requirement

Describes what is needed.

Customers can cancel an eligible order.

Acceptance criteria

Defines what must be true for that requirement to be accepted.

For example:

• Customer can cancel an eligible order.
• Cancellation is unavailable once the order reaches the defined fulfillment stage.
• Customer receives a confirmation after successful cancellation.
• Order status changes to the defined cancelled state.
• Refund behaviour follows the agreed payment rules.
• The cancellation action is recorded where required.

The requirement defines the capability.

Acceptance criteria define the conditions that prove the capability has been delivered correctly.

---

Acceptance Criteria vs Test Cases

Acceptance criteria and test cases are also different.

Acceptance criteria

Define what needs to be true.

Test cases

Define how the team will test whether it is true.

For example:

Acceptance criterion

Users cannot submit a registration form without entering a valid email address.

Test case

1. Open registration.
2. Leave the email field empty.
3. Enter valid information in all other required fields.
4. Submit the form.
5. Verify the application prevents submission.
6. Verify the appropriate validation message appears.

Acceptance criteria establish the expected result.

Test cases provide the procedural method for verifying it.

---

Acceptance Criteria vs Definition of Done

These terms are sometimes treated as identical.

They are not necessarily the same.

Acceptance criteria

Usually apply to a particular feature, requirement or deliverable.

Definition of Done

Usually establishes broader conditions that work must satisfy before being considered complete within a team or project.

For example, a team's Definition of Done might require:

• Code completed
• Code reviewed
• Automated tests passed
• QA completed
• Critical defects resolved
• Documentation updated

A feature's acceptance criteria might say:

• Customer can create an order.
• Order total is calculated correctly.
• Payment status is recorded.
• Confirmation is generated.

Both can exist together.

---

What Makes Good Acceptance Criteria?

Good acceptance criteria should ideally be:

Clear

Everyone should understand what the criterion means.

Specific

Avoid vague language such as "works properly."

Testable

There should be a way to determine whether it passed.

Relevant

The criterion should relate directly to the requirement.

Observable

The result should be visible through the application, system behaviour or appropriate evidence.

Unambiguous

Two reasonable people should be unlikely to interpret it differently.

Achievable

The criterion should reflect realistic project expectations.

---

1. Identify What Is Being Accepted

Start by naming the feature, requirement or deliverable.

For example:

Customer Registration

or:

Payment Processing

or:

Administrator User Management

This prevents acceptance criteria from becoming detached from the actual requirement.

---

2. Define Preconditions

Some functionality requires a specific starting state.

For example:

The user must have an active account.

or:

The product must be available for purchase.

or:

The payment provider must be configured.

Preconditions help make testing and acceptance repeatable.

---

3. Define the User or System Action

Acceptance criteria should identify what triggers the expected behaviour.

For example:

When an authenticated customer submits a valid order...

or:

When an administrator attempts to suspend a user...

or:

When the external payment service confirms a successful transaction...

This establishes the event that should cause the expected result.

---

4. Define the Expected Result

This is the core of the acceptance criterion.

For example:

The system creates the order and displays the order confirmation.

The expected result should be observable.

---

5. Define Business Rules

Acceptance criteria should capture rules that affect whether a feature succeeds.

For example:

A customer cannot cancel an order after it enters the defined fulfillment stage.

or:

Only administrators can change another user's role.

These rules are important because they are part of the actual expected behaviour.

---

6. Define Failure Behaviour

A mature acceptance criterion does not describe only success.

It also establishes what happens when something fails.

For example:

If payment authorization fails, the order must not be marked as paid and the customer must receive an appropriate failure message.

This prevents the development team from treating error handling as optional.

---

7. Define Edge Cases

Not every unusual scenario needs to become an acceptance criterion.

However, important edge cases should be included.

Examples:

• Duplicate submission
• Expired session
• Missing information
• Invalid input
• External API timeout
• Network interruption
• Resource no longer available
• Concurrent changes
• Permission changes
• File size exceeded

These scenarios can make the difference between a feature that works in a demonstration and software that behaves correctly in production.

---

8. Define User Permissions

Acceptance criteria should reflect authorization requirements where access differs by user.

For example:

Administrator

Can create and suspend users.

Manager

Can view users but cannot change account roles.

Customer

Can view only their own profile.

These are acceptance conditions because the feature is not correctly implemented if unauthorized users can perform restricted actions.

---

9. Define Data Conditions

Acceptance criteria should also address important data behaviour.

For example:

When a customer changes their delivery address, the updated address should be used for future orders but should not alter historical orders that have already been completed.

This is more than a user interface behaviour.

It is a data requirement.

Acceptance criteria should capture it because it affects whether the feature is actually correct.

---

10. Define Integration Behaviour

When a feature depends on another system, acceptance criteria should include important integration behaviour.

For example:

When payment is confirmed by the payment provider, the application updates the order status to paid.

But what happens if:

• Payment fails?
• The provider times out?
• The response is delayed?
• The same callback arrives twice?
• The application cannot reach the payment provider?

These scenarios may need their own acceptance criteria.

External dependencies should not be treated as invisible implementation details.

---

11. Define Performance Expectations Where Necessary

Not every acceptance criterion needs performance requirements.

But when performance is part of the actual requirement, it should be included.

For example:

Search results should be returned within the agreed response threshold under the defined production workload.

This is significantly better than:

Search should be fast.

The acceptance criterion should be connected to a measurable expectation.

---

12. Define Compatibility

A feature is not complete if it works only on a platform that was never approved for the project.

Acceptance criteria may specify:

• Supported browsers
• Mobile devices
• Operating systems
• Responsive layouts
• Supported application versions

For example:

The customer checkout flow must function correctly across the project's supported desktop and mobile browser environments.

---

13. Define Security Conditions

Security requirements should also be reflected in acceptance criteria.

For example:

Users without the required permission cannot access administrator functionality.

Or:

Sensitive account information must not be exposed through unauthorized API responses.

A feature can be functionally correct while still failing its security requirements.

Acceptance needs to account for both.

---

14. Define Audit Requirements

Some actions need to be traceable.

For example:

When an administrator changes a user's role, the system records the action with the relevant user, administrator and timestamp information.

This should be an acceptance criterion when auditing is part of the project's requirements.

---

Example: Acceptance Criteria for User Registration

Requirement

Users can create an account.

Acceptance criteria

Registration

• User can enter the required registration information.
• Required fields are validated.
• Invalid input prevents successful registration.
• A duplicate account is handled according to the defined business rule.
• A successfully created account receives the appropriate status.

Verification

• Verification is initiated according to the agreed flow.
• An unverified account cannot perform restricted actions.
• A valid verification action changes the account to the correct status.

Security

• Credentials are handled according to the defined security requirements.
• Sensitive information is not exposed in error responses.

Error handling

• Service failure produces an appropriate user-facing response.
• Duplicate submissions do not create unintended duplicate accounts.

This is much more useful than:

Registration works.

---

Example: Acceptance Criteria for an E-Commerce Checkout

Requirement

Customers can complete an online purchase.

Acceptance criteria

Cart

• Customer can review selected products and quantities.
• Cart total reflects the current item prices and applicable charges.

Customer information

• Required delivery information must be provided before checkout.

Inventory

• Product availability is verified according to the agreed inventory rules.
• An unavailable item cannot be successfully purchased.

Payment

• Customer can complete payment using the supported payment method.
• Failed payment does not mark the order as paid.
• Duplicate payment attempts do not create duplicate completed orders.

Order

• Successful payment results in a valid order.
• Order contains the expected products, quantities, customer information and total.
• Customer receives confirmation.

Failure handling

• Payment service failure is handled appropriately.
• Customer receives a clear status.
• Order state remains consistent.

Now the completion conditions are explicit.

---

Example: Acceptance Criteria for an API

Suppose the requirement is:

The system provides an API for retrieving customer information.

Acceptance criteria might include:

• Authorized requests return the expected customer data.
• Unauthorized requests are rejected.
• Users cannot access customers outside their permitted scope.
• Invalid customer identifiers produce the expected error response.
• The API returns the agreed response structure.
• Errors use the defined status behaviour.
• Sensitive fields are not returned unless explicitly authorized.

This demonstrates that API acceptance is not limited to:

Endpoint returns data.

Correct authorization and error behaviour are also part of acceptance.

---

Example: Acceptance Criteria for an AI Feature

AI systems require particularly careful acceptance criteria because simply receiving an answer does not mean the AI feature is working correctly.

Suppose the requirement is:

The AI assistant should answer questions using the company's internal documentation.

Acceptance criteria might include:

Relevant questions

• The assistant retrieves relevant information from approved sources.
• Responses reflect the available information.

Unsupported questions

• The assistant does not invent unsupported information.
• When sufficient information is unavailable, the defined fallback behaviour is used.

Access control

• Users cannot retrieve information they are not authorized to access.

Response behaviour

• Output follows the agreed response format.
• Responses meet the defined quality criteria.

Evaluation

• The agreed evaluation set achieves the required performance threshold.

Safety

• The system follows defined restrictions for sensitive or prohibited operations.

AI features therefore need acceptance criteria around behaviour, accuracy, access, uncertainty and failure, not simply whether a response was generated.

---

Writing Acceptance Criteria Using Given, When and Then

One practical format is:

Given

The starting condition.

When

The user or system performs an action.

Then

The expected outcome.

For example:

Given an active customer with an eligible order When the customer selects Cancel Order Then the system cancels the order and displays the defined confirmation.

For a failure:

Given an order that is no longer eligible for cancellation When the customer selects Cancel Order Then the system prevents cancellation and displays the appropriate message.

This format is useful because it forces the team to define conditions, action and outcome.

---

Acceptance Criteria Do Not Always Need to Use Given, When, Then

The format is useful.

It is not mandatory.

Simple criteria can be written as direct statements.

For example:

• Only administrators can change user roles.
• Expired verification links cannot be used.
• Deleted records cannot appear in active search results.

The best format is the one that makes the expected behaviour clear and testable.

---

How Many Acceptance Criteria Should a Feature Have?

There is no universal number.

A simple feature may need three or four criteria.

A complex workflow may require twenty or more.

The correct question is:

Have we covered the important conditions required to determine whether the feature is complete?

Do not create criteria simply to increase the number.

But do not keep criteria so short that important behaviour disappears.

---

Acceptance Criteria for Different Types of Work

UI Feature

Should address:

• Expected interaction
• Validation
• Responsive behaviour
• Error states
• Loading states
• Permissions

API

Should address:

• Authentication
• Request validation
• Response structure
• Authorization
• Error behaviour
• Data correctness

Database Change

Should address:

• Data integrity
• Migration
• Existing data compatibility
• Rollback considerations
• Application behaviour

Integration

Should address:

• Successful communication
• Authentication
• Data mapping
• Failure
• Timeout
• Retry
• Duplicate events

Infrastructure

Should address:

• Configuration
• Availability
• Monitoring
• Security
• Deployment
• Recovery

AI Feature

Should address:

• Expected capability
• Input
• Output
• Accuracy or evaluation criteria
• Unsupported situations
• Security
• Access
• Cost or usage limits where relevant

---

Acceptance Criteria for a Project Milestone

Acceptance criteria do not have to apply only to individual features.

They can also apply to project milestones.

For example:

Milestone: Production Readiness

Acceptance criteria may include:

• Approved functionality is implemented.
• Critical user journeys pass.
• Required integrations are operational.
• Critical defects are resolved.
• Production environment is configured.
• Monitoring is operational.
• Backup process is configured.
• Required documentation is complete.
• Client acceptance is recorded.

This gives the project a defined finish line for major delivery stages.

---

Project-Level Acceptance Criteria

At the end of the project, acceptance may cover broader areas:

Functionality

Approved requirements are implemented.

Quality

Defined critical defects are resolved.

Security

Required security controls are implemented.

Performance

Agreed performance requirements are satisfied.

Compatibility

Supported platforms have been validated.

Deployment

Production deployment has been completed successfully.

Documentation

Required project documentation has been delivered.

Handover

Required access, credentials and ownership materials have been transferred.

This provides a more complete definition of project completion.

---

What Should Not Be an Acceptance Criterion?

Avoid vague statements such as:

The feature should work correctly.

The application should be user-friendly.

The page should look good.

The system should be secure.

The interface should be fast.

These are goals, not sufficiently defined acceptance conditions.

They can be useful as broader expectations.

They should then be translated into observable conditions.

For example:

Instead of:

The page should be responsive.

Use:

The page should correctly adapt to the supported desktop, tablet and mobile layouts defined for the project.

The more important the requirement, the more precise the acceptance criteria should become.

---

Common Acceptance Criteria Mistakes

1. Writing criteria after development is finished

Acceptance criteria should guide development, not be invented when the feature is already complete.

2. Only testing the happy path

Real software encounters invalid input, failures and unexpected conditions.

3. Using subjective language

"Looks good" is not objectively testable.

4. Making criteria too vague

"Works correctly" does not explain what correct means.

5. Forgetting permissions

A feature that works for the wrong user is not correct.

6. Ignoring data behaviour

A UI may look correct while the underlying data is wrong.

7. Ignoring external dependencies

Integration failures are part of real system behaviour.

8. Confusing acceptance criteria with test cases

Criteria define what must be true.

Tests define how it will be verified.

9. Defining too many low-value conditions

Acceptance criteria should focus on meaningful behaviour.

10. Forgetting to update criteria when scope changes

An approved requirement change may require updated acceptance conditions.

---

What Happens When Acceptance Criteria Are Missing?

Without acceptance criteria, several problems become more likely.

Subjective acceptance

Different stakeholders interpret completion differently.

Repeated revisions

A feature is technically finished but repeatedly sent back because expectations were not documented.

Late discovery of edge cases

Important failure scenarios are identified only during final testing.

Scope disputes

People disagree about whether additional behaviour was required.

Delayed releases

The team cannot agree whether the system is ready to ship.

Payment disputes

Where delivery milestones are connected to commercial acceptance, unclear completion conditions can create unnecessary disagreements.

Good acceptance criteria reduce ambiguity around completion.

---

Who Should Define Acceptance Criteria?

Acceptance criteria should not be written exclusively by developers or exclusively by clients.

They should reflect the actual product requirements.

Depending on the project, criteria may involve:

• Product owner
• Business stakeholder
• Business analyst
• Technical lead
• Developer
• QA engineer
• Security specialist
• Client representative

The right people should contribute where their expertise matters.

For example:

A product owner may define expected business behaviour.

A developer may identify technical edge cases.

A QA engineer may identify conditions needed for effective validation.

A security team member may add access-control requirements.

---

When Should Acceptance Criteria Be Written?

Acceptance criteria should ideally be defined before implementation of the relevant feature begins.

A useful sequence is:

Requirement

↓

Scope

↓

Acceptance criteria

↓

Design

↓

Technical specification

↓

Development

↓

Testing

↓

Acceptance

The exact order can vary between teams.

The important principle is that completion conditions should be known before everyone starts arguing about whether something is finished.

---

Can Acceptance Criteria Change?

Yes.

Requirements can evolve.

The business may change a workflow.

A technical constraint may emerge.

An integration may behave differently than expected.

A user need may become clearer.

When an approved change occurs, the acceptance criteria should be updated accordingly.

Otherwise, the team may be implementing against an outdated definition of completion.

---

Acceptance Criteria and Change Requests

Suppose the original requirement says:

Customers can update their email address.

The acceptance criteria cover:

• Valid email
• Verification
• Saving the new address
• Updating the account

Later, the client requests:

Add a secondary email address too.

That is a new behaviour.

The change may affect:

• Requirement
• Scope
• UI
• Database
• API
• Authentication
• Notifications
• Testing
• Acceptance criteria

The correct process is to evaluate the change rather than simply adding another input field and pretending nothing else has changed.

---

Acceptance Criteria Should Be Traceable

For larger projects, acceptance criteria should connect back to requirements.

A simple structure might look like:

Requirement ID: REQ-014

Customer can reset their password.

Acceptance Criteria: AC-014-01

Registered user can request reset.

Acceptance Criteria: AC-014-02

Expired reset mechanism cannot be used.

Acceptance Criteria: AC-014-03

Successful reset permits authentication with the new password.

This provides traceability between requirement, implementation and testing.

---

Acceptance Criteria and QA

QA should not have to guess what the product team intended.

Acceptance criteria provide a reference point for test planning.

For each criterion, QA can determine:

• What needs to be tested?
• What input is required?
• What output is expected?
• What edge cases matter?
• What evidence demonstrates success?

This makes testing more systematic.

---

Acceptance Criteria and Client Acceptance

When clients are involved in acceptance, criteria become particularly important.

Instead of asking:

"Do you like the feature?"

the project can ask:

"Does the implemented feature satisfy the agreed acceptance conditions?"

That changes acceptance from subjective opinion to structured evaluation.

There will still be room for professional judgment.

But important delivery decisions become much clearer.

---

A Practical Acceptance Criteria Template

A reusable acceptance criteria structure can be:

Feature

Name the feature or deliverable.

Requirement

State what the feature needs to accomplish.

Preconditions

Define the starting conditions.

Primary behaviour

Describe the expected successful workflow.

Validation

Describe input validation.

Business rules

Document important conditions.

Permissions

Define who can perform the action.

Failure behaviour

Describe important failures.

Edge cases

Document significant exceptional scenarios.

Integration behaviour

Describe relevant external dependencies.

Data behaviour

Explain important data changes.

Performance

Define measurable expectations where required.

Security

Define security conditions.

Compatibility

Define supported environments.

Acceptance evidence

Identify how completion will be demonstrated.

This structure can be adapted to almost any software project.

---

Complete Example: User Profile Update

Requirement

Authenticated users can update their profile information.

Preconditions

• User has an active account.
• User is authenticated.

Acceptance criteria

Profile information

• User can view the current profile information.
• User can update permitted profile fields.
• Required fields cannot be saved when invalid.

Validation

• Email address must follow the defined validation rules.
• Required fields cannot be empty.
• Invalid input produces an appropriate validation message.

Authorization

• Users can modify only their own profile.
• Administrative fields cannot be modified through the customer profile interface.

Security

• Sensitive operations follow the defined authentication requirements.

Data

• Valid changes are persisted correctly.
• Updated information appears when the profile is reopened.

Failure

• Temporary service failure does not create a partial or inconsistent update.
• User receives an appropriate error message.

Audit

• Required profile changes are recorded according to the project requirements.

Now the development team knows what to build.

The QA team knows what to validate.

The client knows what to expect.

That is the purpose of acceptance criteria.

---

The Ortem Acceptance Readiness Framework

At Ortem Technologies, a useful way to judge whether acceptance criteria are strong enough is to ask six questions.

1. What is being accepted?

The feature or deliverable must be explicit.

2. What should happen?

The expected behaviour must be clear.

3. What should not happen?

Important invalid or restricted behaviour should be defined.

4. What happens when things go wrong?

Important failure cases need defined behaviour.

5. How will we prove it?

There must be a practical way to verify the criterion.

6. Who decides acceptance?

The responsible acceptance owner should be clear.

If these six questions can be answered, the feature is much easier to evaluate objectively.

---

Final Acceptance Checklist

Before accepting a software feature, verify:

Requirement

• Is the original requirement clearly identified?

Functionality

• Does the feature perform the intended function?

User flow

• Does the complete workflow behave correctly?

Validation

• Are invalid inputs handled?

Business rules

• Are required business conditions enforced?

Permissions

• Can only authorized users perform the action?

Data

• Is the expected information created, updated or retrieved correctly?

Integrations

• Does the feature handle external systems correctly?

Failure

• Are important failure conditions handled?

Edge cases

• Are significant unusual scenarios covered?

Performance

• Are relevant performance criteria satisfied?

Security

• Are required security conditions satisfied?

Compatibility

• Does the feature work in supported environments?

Testing

• Have the defined acceptance conditions been verified?

Defects

• Are there unresolved defects that prevent acceptance?

Documentation

• Has relevant documentation been updated?

Approval

• Has the appropriate stakeholder accepted the result?

---

Final Takeaway

Acceptance criteria are the bridge between:

What we asked for

and

What we can objectively verify was delivered.

They turn a vague statement such as:

Build a login feature.

into measurable expectations around:

Who can log in.

How authentication works.

What valid input looks like.

What invalid input does.

What happens when authentication fails.

What different users are allowed to do.

How sessions behave.

What happens when dependencies fail.

How the feature will be tested.

What conditions must be satisfied for acceptance.

Good acceptance criteria do not make software development rigid.

They make expectations visible.

They give developers a clear target.

They give QA a clear basis for testing.

They give clients a clear basis for review.

They give project managers a clearer definition of completion.

And they reduce the risk of reaching the end of a project only to discover that different people were working toward different definitions of done.

At Ortem Technologies, we believe a software feature should not be considered complete simply because someone has finished writing the code.

It should be considered complete when the agreed behaviour has been implemented, verified and accepted against clearly defined conditions.

A simple question should always have a clear answer:

What exactly must be true before we can call this feature finished?

That is what acceptance criteria are designed to answer.

Want acceptance criteria written into your project before development starts, not reverse-engineered after? That is part of every custom software development engagement we run.

Get your acceptance criteria reviewed →