Have you ever wondered about the difference between Acceptance criteria and Requirements?
Have you ever thought why they need to be documented separately?
Requirements and acceptance criteria seem to be the same, but it’s not correct.
Requirements are at a higher level while acceptance criteria at a lower level, more towards the delivery point. Requirements and acceptance criteria would seem to be the same. In an ideal world acceptance criteria may be equivalent to requirements. But in the real world a lot of changes happen during the course of time.
Requirements are what you are supposed to do. Acceptance criteria are agreed upon measures to call a project “done.” Acceptance Criteria are a set of statements, each with a clear pass/fail result. Testability has a close connection with acceptance criteria.
Let us work out a simple example.
I wish to buy a new watch by this month end. It should have a broad silver strap with a round face. Also it needs to be an alarm watch with multiple time zones. Its cost should be less than 100$. And finally it should suit my style. These are my specifications or requirements pertaining to the watch.
Now what are my acceptance criteria? Do I need to consider all of those requirements as acceptance criteria? Or is there anything more that I need to consider while choosing my acceptance criteria?
I define my acceptance criteria as
‘I have to go to a watch store (not online) and purchase the watch. I need it, if and only if I could purchase it before this month end.’
Here, the above stated acceptance criteria are independent of requirements. If I add below more statements to the above, then the acceptance criteria becomes related to requirements.
‘It should have broad silver strap with a round face. There should be a provision to set alarm. It should be possible to alter time zones. And its prize needs to be less than 100$’
So what are the acceptance criteria?
It could vary based on how the user defines it. It is possible for a developer to complete only a few of the requirements, and still meet the acceptance criteria to finish the project. Basically it is a set of agreements which needs to be satisfied for a user to accept the product. These agreements are not static. It varies whenever there is a change in condition. Below are some examples of change in conditions which leads to the change in acceptance criteria over the course of time.
- Budget changes
- Requirements change
- Schedule changes
- Competency changes
In short, it is not necessary to have all the requirements in acceptance criteria. In some case some requirements (the so called “nice to have” requirements) may be cut down and be considered in next iteration. Sometimes acceptance criteria may be totally independent of requirements.