10

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.

Improve this question

8 Answers 8

Reset to default
12

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.”

and

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.

Improve this answer
5
  • -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, 2013 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, 2013 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, 2013 at 15:35
  • 6
    I disagree that this answer makes the difference clear. It's not clear at all to me from this answer.
    – Robin Green
    Sep 26, 2014 at 5:37
  • This means that some requirements (usually "nice to have" requirements) may fall off, and be implemented in next version. If the requirement falls off, I don't think it's a requirement at all by definition, because it is no longer required. I've usually heard such things are referred to as nice to have features instead. I furthermore think this answer could be improved by adding examples. Even if the statement I quoted were true, I don't think it's the only situation in which requirements differ from acceptance criteria.
    – Sander
    May 25, 2020 at 21:25
10

Requirements are what you're supposed to do.

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

Improve this answer
2
  • Downvoter care to elaborate on what they think needs to be improved here?
    – Telastyn
    Nov 14, 2013 at 14:59
  • Not the downvoter, but I'd call the measures to prove the requirements are met the "test plan". So not sure what you mean here really.
    – Sean Reid
    May 25, 2020 at 10:16
4

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)

Improve this answer
3

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.

Improve this answer
1
  • 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, 2015 at 20:38
2

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.

Improve this answer
2

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"

Improve this answer
0

Requirements form a specification that the engineers develop the code against. Consider that the user may accept a program that violates many requirements. For example the code may be an unmaintainable spaghetti and contain race conditions, but still deliver the business value and quality acceptable by the user.

Acceptance criteria form a checklist that the user accepts or rejects the application against. These may include both functional and non-functional requirements, such as certain behaviors or decent performance. Notice that the user doesn't care about software architecture, database schemas and code optimization. If the needs of the user are not timely and accurately captured into requirements, program may be written up to specification, but the result may be rejected by the user.

Improve this answer
0

A requirement is very board ask from the customer. For instance, the customer wants to modernize the User Interface of an application. This requirement will be broken down to multiple features and these features are further broken down to user stories. Acceptance criteria applies well for a user story which is very granular compared to the requirement and thus more accurately measurable

When my use story's acceptance criteria are met, my user story is deemed as completed. When all my user stories are delivered, my feature's acceptance criteria is met. when all my feature are completed, the requirement is met.

Improve this answer