How do requirements relate to acceptance criteria?

Although requirements and acceptance criteria provide the information to test and develop new application features, they provide that information in different ways and for distinct reasons. Requirements and acceptance criteria often seem to be essentially the same thing, but that's not true.

Requirements represent functionality definitions. Requirements are documented functional needs that a code feature or application design must perform to meet contractual needs or customer expectations. In Agile, requirements often change throughout the development of a feature. They are typically developed by a business analyst or product owner with direct input from the customer or end user.

Design conversations are highly important in agile, and acceptance criteria should always be part of the team conversation. Acceptance criteria are team-driven, agreed upon measures to call a project "done." In other words, acceptance criteria determine whether the code meets the requirements and can be moved into a release.

Acceptance criteria rarely change once they are defined. However, if a requirement changes and the changes fundamentally alter the feature design, the acceptance criteria within a project are reviewed by the development team and updated as needed.

In Agile Scrum, acceptance criteria are more important to application design than the overall functional requirement, because they function as the small, incremental building blocks that form the base of the design. From a design perspective, acceptance criteria are the atomic units of each requirement. They represent the individual steps for each individual user project that the development team must accomplish before a project is completed, and include it in an upcoming release to customers.

It is important for a team to spend as much time crafting quality, accurate acceptance criteria as is spent gathering and generating feature requirements.