I am trying to understand the difference a little better as it seem like they are the same thing.

I have work in projects with no use of the requirements and everything is an acceptance criteria, and on projects that have both.

migrated from stackoverflow.com Nov 14 '13 at 14:04

This question came from our site for professional and enthusiast programmers.


The acceptance criteria defines when the application is finished. Or to put it another way, when you can ship it. It includes list of requirements that it has to fulfill. This means that some requirements (usually "nice to have" requirements) may fall off, and be implemented in next version.

To expand it even further (taken from here) :

Microsoft Press defines Acceptance Criteria as “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Google defines them as “Pre-established standards or requirements a product or project must meet.”


Acceptance Criteria are a set of statements, each with a clear pass/fail result, that specify both functional (e.g., minimal marketable functionality) and non-functional (e.g., minimal quality) requirements applicable at the current stage of project integration. These requirements represent “conditions of satisfaction.” There is no partial acceptance: either a criterion is met or it is not.

A requirement describes a certain functionality of the application.

Or, as wiki nicely stated :

a requirement is a singular documented physical and functional need that a particular design, product or process must be able to perform.

What is the difference between the acceptance criteria and the application requirements?

With above definitions, the difference is quite clear.

  • -1 I find this text quite confusing given the use of 'fulfil' in both places, even though the first refers to the second. Suggest you edit, remove all the mentioned of requirements in the acceptance criteria section and I will upvote instead. – Michael Durrant Nov 14 '13 at 14:27
  • 1
    @MichaelDurrant After some thinking, I realized you were right. The definition of the requirements was indeed confusing. Anyway, not only I reworded it, I added additional information. Hope it is ok :) – BЈовић Nov 14 '13 at 14:51
  • +1 I like it. fulfil vs. perform. downvote reverted and upvote applied. Even for a competing answer to mine ;) – Michael Durrant Nov 14 '13 at 15:35
  • 3
    I disagree that this answer makes the difference clear. It's not clear at all to me from this answer. – Robin Green Sep 26 '14 at 5:37

Requirements are what you're supposed to do.

Acceptance Criteria are the agreed upon measures to prove you've done them.

  • Downvoter care to elaborate on what they think needs to be improved here? – Telastyn Nov 14 '13 at 14:59

Requirements are what the client / customer have asked for.

Acceptance Criteria, often expressed as tests, are used to illustrate Requirements and to indicate, when the tests pass, that the Requirements have been met.


It's often a matter of timing

Requirement are ahead of time. Acceptance criteria are at the software delivery point.
This is as others have answered...

There is a deeper issue though and perhaps you are seeing it:

In an 'ideal' world these would just match. However in the real world a lot happens between these two events, often including some of the following:

  • as the software is developed the requirements change.
  • the software is built with Agile processes
  • the budget changes
  • the timetable changes
  • the availability of technical talent is not 100% and changes over time
  • the determination that not all functionality is needed for go-live.
  • the business is affected by external factors that change what is needed.

It is frequently a matter of 'level of detail', with the requirements at a high level, e.g. "a refund processing module" and the acceptance criteria at a more low level and more detailed such as "a refund requested should be completed within 3 days and a notice emailed to the customer"


Requirements fall under verification which answers the question:

Was the product built correctly? (bottom-up as per the requirements)

Acceptance Criteria fall under validation which answers the question:

Was the correct product built? (top-down as evidenced by passing acceptance tests)


Requirements are often driven by the client. In a waterfall development pattern these are the list of expected results from the completion of a project. In it's most basic description requirements are nothing more than a to-do for a project.

Acceptance criteria are often driven by the relationship between two parties. They can be independant from the requirements, and/or related to the requirements. That doesn't make them the same thing, but just related. Unlike requirements acceptance criteria is not a to-do list. It's a list of conditions that must be met for the agreement to be considered finished.

Some answers have stated unit tests, budgeting, and project management as examples but those are just examples of conditions placed upon the agreement as an acceptance criteria.

It is possible for a developer to complete none of the requirements, and still meet the acceptance criteria to finish the project.

For example;

Requirement to update point of sales system with new tax law changes. Acceptance criteria between the developer and client states developer agrees to complete 40 hours work to perform the update. If the work is not completed in that time no updates for the system will be published as this is the clients budget limit.

The developer enters into the agreement, and after 40 hours of work he reports that the change is significant resulting in more than 40 hours to finish. The client accepts this result, pays the developer their wages and their agreement is finished.

  • 1
    While I think the accepted answer is better from a technical standpoint, I prefer your answer's focus on how acceptance criteria actually get created and evaluated. I wish the 2 were combined. – CLW Jun 8 '15 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy