Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Requirements  Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria
Previous Previous
Next Next
New Post 5/1/2019 1:31 AM
User is offline MadiMo
10 posts
10th Level Poster

Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria 


I am having a confusion between the practical definition of a Requirement, Requirement Acceptance Criteria and the Testing Acceptance Criteria.

I understand what each definition means, however, an acceptance criteria to me re-states the workflow that must be followed to consider a user story done, for example:

This is a user story that says

As a content editor, I would like to update the content of my product, so that I keep the customers aware of the latest special offers.

The Requirement Acceptance Criteria could be:

Ensure the content owner is able to :

  1. Log in to the Content Management System
  2. Edit the current price
  3. Set up the offer timeframe

However, such acceptance criteria does re-instate the Functionality Workflow, does not it? In that case what is the difference between this and a Requirement?

Other people would say that an acceptance criteria for this feature is simply as this:

Ensure that 8 out of 10 users are capable to edit the product details in less 4 click interaction.

So which one is the best written acceptance criteria? Do you write it based on the Testing View or the Requirement View?


Many Thanks for your kind advice

New Post 5/24/2019 10:13 PM
User is offline Krishna 02
2 posts
No Ranking

Re: Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria 


Thanks for raising this question. Keeps coming up multiple times in my mind and maybe others too - when we actually apply tools like user stories / acceptance criteria in real life assignments.

I feel as a BA, its our constant attempt to present requirements / solutions in ways that can be understood by both the user and developer. Tools / templates facilitate this sync up.

Maybe there is no single way of using these tools. Guess its fine to use them in our own way, to suit our situation - so long as overall objective of clear communication is met.

In given example, i like the way user story and acceptance criteria is written. If i read it wearing both User & Developer hats - the User story is giving me the context (what this requirement is about) and Acceptance criteria is giving me next level of details (what does "update the content" relate to).

Maybe User also expects the 8 out of 10 and < 4 click requirements. I would believe these are non-functional in nature, but a BA should tie these up and can add it to the above Acceptance criteria.

Just sharing my thought process, would like to hear views from you and others too !

Thanks and Best regards


New Post 7/17/2019 12:44 AM
User is offline Stewart F
39 posts
9th Level Poster

Re: Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria 


Hi MadiMo, it slightly depends on what methodology you use, but to be as simplistic as I can:

Requirement Acceptance Criteria

This tells your developers (if it is a system requirement) what the least that is expected is. So the 3 parts that you stated could indeed be the minimum that is required in order to meet the requirement. 

Why do you need a minimum level to meet a requirement? Well, typically Developers or for that matter anyone else who is responsible for making the requirement happen, will probably interpret your requirement slightly differently to how you intended. Developers are especially good at doing this. So your Requirement Acceptance Criteria is just that - "What must a User be able to do in order that this requirement can be signed off?" Normally, you wouldn't write this separately to the overall requirement in a User Story or Business Requirements Document, however, I tend to get my team to separate them out so that you end up with sub-titles:

(The following is if I am writing a User Story in Agile, but it applies to the more traditional Waterfall)

The basic thread "As a User, I want....."

*Business Requirements

*Technical Requirements

*Further Information

*Requirement Acceptance Criteria 

Testing Acceptance Criteria 

This follows the same as the above, with the exception that at this stage the requirement should have been built. The TAC basically just states what the bare minimum the Testers should test for, should be. So in your example a Tester should test that:

  1. That a User  can log in to the Content Management System
  2. That a User can edit the current price
  3. That the system/User can set up the offer timeframe
The Testers will also test other things as well, but they should derive that list from the Developers as well as their own experience of what to test. 

Again, the TAC is described as a part of the User Story or Business Requirements Document (Both usually have a separate section for writing the TAC. 

Why would you want to have either? Well, in short it helps you to make sure that you get the requirement signed off by the Stakeholder when development is complete.

Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Difference between a Testing Acceptance Criteria and Requirement Acceptance Criteria

Community Blog - Latest Posts

Dan Tasker
Dan Tasker
  In Part 1 of this series it was stated that the overall objective of these articles is to improve the quality of requirements produced by business analysts. Following the adage that “Context is Everything” it established that a number of different contexts...
7 Responses
Alice Bolingeryn
Alice Bolingeryn
Clearly, the most important step in getting a job is being selected for an interview, and a key part in that process is having a resume that stands out from others.   For many people, creating a good enough resume is an obstacle in achieving this, and so one way to address this problem may be to get a professional to create one for you. J...
0 Responses
It may sound routine, but the importance of operational decisions cannot be underestimated. After all, not a day goes by without even the smallest business making dozens, if not hundreds of operational decisions that may affect the bottom line. Elevate these to large scale companies and we are talking thousands, if not millions of actions that impa...
0 Responses

Upcoming Live Webinars

Latest Articles

Ninety Percent Done
Jul 21, 2019
The fact that software projects and tasks are reported to be “90 percent done” for a long time has become something of an industry joke. (...
Copyright 2006-2019 by Modern Analyst Media LLC