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.
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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.
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:
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 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.
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.
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.
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.