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.


CMMI Version 1.3 was released on November 1, 2010. All the three constellations of CMMI – SVC, ACQ and Dev, got released in the same period, considering the similarities across them.

How good it would be, if all the three constellations were combined into a single model..? Definitely it would have eased the process of CMMI compliance as well as appraisal.

Yes, the realization is not far ahead. CMMI institute has started to redefine and rewrite the CMMI. ’CMMi NextGen’ is the project currently underway at the CMMI institute. ‘Next Gen will be combining ACQ, DEV, SVC, P-CMM and DMM into a single model. NextGen won’t be a simple upgrade like v1.1 to v1.2, or v1.2 to v1.3. It is a “re-molding” of the entire model.

A set of working groups has been formed under this project to define the future of CMMI.  They work on

  • Architecture
  • Current needs
  • Implementation
  • Performance
  • Plain language
  • Simplify model and appraisal method
  • System
  • Trainings

Each working group consists of “authors” and “reviewers.” Refer more on working groups at http://partners.clearmodel.com/volunteer-cmmi-next-generation-working-group/. CMMI institute is collecting requirements and recommendations. Since the change being major, we will have to wait for a couple of years to have the next generation in place.

Next Generation Project Information Portal is now available on Partner Resource Centre.  All Partner BPOCs(Business Point Of Contacts) and Certified Individuals will have access to the information about the project through this portal.