Hello,

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

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

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.