When you’re defining your software or new product’s requirements, a set of criteria come into play. Acceptance criteria are one part of those criteria that are either agreed upon or come out of client/customer discussions. Unlike requirements, acceptance criteria define what must happen when a decision point such as an objective has been met.
Acceptance Criteria
Acceptance criteria refer to a set of standards that a software product needs to be accepted and appreciated by the customer, user, or any other system. They are specialized for each user story and highlight future behaviors from the end user’s perspective.
Some accurately drafted acceptance criteria help companies avoid errors at the end of a development stage and ensure that users and stakeholders love the final product they get. A company needs to define its acceptance criteria before its development team starts building a particular user story. Failure to which may cause them not to meet the expectations and needs of a client.
Purpose of Acceptance Criteria
- Describing Negative Scenarios
Acceptance criteria ensure the system detects unsafe passwords and thus hinders a user from completing his mission. An invalid password is categorized as a negative scenario, that is when a user puts an invalid password or behaves awkwardly. AC highlights this type of scenario and gives precise details on how the system should deal with them.
- Increases the Details of the Future Scope
Acceptance criteria majorly highlight the boundaries of user stories. They give accurate details on the functionality, ensuring the team understands whether they have completed the user story as they are expected.
- Streamlining Acceptance Testing
AC is the backbone of the user story acceptance testing. A team needs to test each acceptance criterion independently and get a specific pass or fail scenario. They can also apply automated tests to verify the stories.
- Setting Communication
Acceptance criteria evaluate the vision of the development team and the client. They ensure every member gets a clear understanding of the requirements. The developers know the particular feature’s behavior, and the client and stakeholders understand what’s anticipated from the element.
- Conducting Feature Evaluation
The team uses acceptance criteria to specify what they need to work on. They then split the user stories into smaller tasks to estimate once they have specific requirements. Different people have different opinions. Thus, they may have diverse views and solutions towards one problem. Therefore, they need to have a unified vision of how they should implement the functionality.
Types of Acceptance Criteria
The types of acceptance criteria include:
- Scenario Oriented Acceptance Criteria
Scenario-oriented acceptance criteria are in scenario form and highlight every criterion. It takes the sequence of Given/When/Then (GWT). It’s majorly written as follows:
- Given some precondition
- When I do some action
- Then I anticipate some results
The approach was adopted from behavior-driven development(BDD) and offered reliable structures that the testers use to estimate when to start and end testing a particular feature. It describes the behavior of the system upfront, thus helps reduce the time the team spends writing test cases.
The scenario oriented acceptance criteria format highlights the following statements:
- Scenario- the name of behavior a team has to describe
- Given – the initial state of the scenario
- When – the particular action of the user
- Then – results of the action
- And – continuation of any of the three previous statements
Example 1
User Story
A user needs to recover the password to his account to access it when he forgets the password.
Scenario: Forgot password
Given: The user heads to the login page
When: Chooses forgot password
And: Enters a valid email that gets a link for password recovery
Then: The system automatically sends the link to the email
Given: Users receive the link via email
When: The user maneuvers through the received link
Then: The system allows the user to set a new password
Example 2
User Story
A user intends to request money from his account at an ATM and receive cash into his account quickly in different areas.
Scenario: Request money from a creditworthy account
Given: Account is creditworthy
And: Valid card
And: Dispenser has enough money
When: Customer request the cash
Then: The account must be debited
And: Ensure the cash is dispensed
And: Ensure the return of the card
Example 3
User Story
A user has had an over withdrawal from his account, and he intends to rectify the mistake.
Given: The account is overdrawn
And: Valid card
When: Customer request the cash
Then: The rejection message must be displayed
And: Ensure the card isn’t dispensed
The examples show that scenario-oriented acceptance criteria are quite effective in several situations. However, they can also be regarded as a universal solution.
- Rule Oriented Acceptance Criteria
Some situations don’t implement the GWT structure, and they include:
- Working on user stories that give details on the system-level functionality and require other quality assurance methods.
- The target audience for the acceptance criteria is not Interested in specific details of the test scenarios.
- GWT isn’t appropriate for describing user experience constraints and the design of a feature
Rule-oriented AC refers to some rules that best describe the behavior of a system. From the three rules, a company can draft specific scenarios. The rule-oriented acceptance criteria format can only solve these cases.
Example 4
User Story
A user intends to apply a search field to type a street, name, or city for him to find matching hotels.
Solution
- The search field is located on the top bar
- The user clicks search, and the search starts
- The field has a placeholder that contains a grey colored text. ‘What’s your destination?’
- Placeholder goes immediately the user starts typing
- The search is accomplished once the user types the street, city, or hotel
- Allows the user to search in English, Ukrainian, or Germany
- It doesn’t allow the user to exceed 200 symbols
- The search doesn’t support special symbols, and when a user searches a particular character, it displays a warning message “search input should not have special symbols.”
Example 5
User Story
A user wants to register in an online platform to shop his products from online sellers.
Given: The user has to fill all the required fields to submit the form
And: The email the user has submitted shouldn’t be free
And: The user can only submit three times within thirty minutes if the submission is from the same IP
When: User will get a notification email after a successful registration
Requirements
Requirements are simply the function, service, or feature that a user needs. They can also be constraints, procedures, business rules, or other functionality that a company needs to meet the requirements of the intended user.
Categories of Requirements
There are two categories, and they include:
- Functionality Requirements
Functionality requirements state what’s needed and highlight a function or a feature. It doesn’t explain how a company can arrive at a physical solution.
- Non-Functionality Requirements
Non-functionality requirements describe how well or the level of solution that needs to be implemented. They define the solution attributes such as reliability, security, availability, maintainability, response times, and performance. The response time can be: Available 24 hours per day every day or responding within 5 seconds.
The non-functionality requirements may offer solution-wide or affect a group of functional needs. All customers facing functionality must have the company logo, or all customers facing functionality must respond within 5 seconds to requests.
Example 6
User Story
A user wants to buy a watch at the end of the week, and it should have a broad silver strap with a round face. It also has to be an alarm watch with multiple time zones, and the cost should be less than $50.The watch should also fit his style, be unique and durable.
Example 7
At a project level, a marketing director needs to improve the customer service to retain their customers. The services he should improve include phone, email, live chat, and onsite customer services. Enhanced services will cheer the customers and ensure they are loyal to the company.
Example 8
As a human resource manager, he/she has to find a significant way of handling employee records. That will help track the employee history records, including their career moves and training.
Example 9
Story identifier: SJK001
Story name: Customer order
Description: A customer has to place an order for the electronics to be delivered to his homestead
Functional: I am I eligible to change my order before I pay for it
Can I see the total of the items I have selected?
Can I save my order and check it later?
Non-functionality: Availability
Can I check the order anytime?
Can I place an order anytime?
Example 10
A customer wants to purchase a coach that they can sit on and also use as a bed. He wants the seat to be brown, made of durable material, and easy to carry. The seat should not exceed $100 and should be of high quality. The company thus has to meet the client’s requirements.
Differences Between Acceptance Criteria and Requirements
Requirements refer to the features and functions that you have to deal with while acceptance criteria are the features that are agreed upon measurements before a team can say they have completed a project. Requirements are at a higher level, whereas the acceptance criteria are lower towards the delivery point.
Acceptance criteria refer to a set of statements with precise fail/pass results that distinguish both functional such as minimal quality and minimal marketable functionality. In contrast, requirements are applicable at the current stage of project integration. The requirements refer to the satisfaction conditions, and there is no partial acceptance.
Requirements are categorized under verification, which answers the question: Was the product made accurately according to the requirements? Whereas acceptance criteria are categorized under validation and answer the question: Did the actual product pass the acceptance tests?
Requirements entail the features a customer asked for while acceptance criteria express tests and illustrate requirements and show when the test pass and the requirements that have been achieved.
In most cases, the requirements are driven by the client. At the same time, the acceptance criteria are guided by the relationship between the two parties and can be related or independent of the conditions.
When to Use Acceptance Criteria
The majority of the product owners and managers prefer to use acceptance criteria during the backlog grooming session. They apply the requirements to sprint planning meetings and discussions with the developers and redesign based on their feedbacks. However, there is no specific rule as to where to use the requirements.
A team needs to define the acceptance criteria before the actual development kicks off. Failure results in the loss of most of the benefits of using in the initial stage. You should write the acceptance criteria and requirements when you are sure about moving something to a product backlog. Thus you don’t need to wait for user stories that can get deprioritized.
Why Do You Need Acceptance Criteria and Requirements?
Acceptance criteria and requirements are significant for cross-functional teams.AC creates room for interpretation and clarifies the expected outcome of a user story in a concrete manner. It additionally enlightens the developers and QA on a straightforward way to determine whether a story is completed.
A company needs this criterion to develop the desired design before the actual development begins thus eliminates misunderstanding as to the project proceeds. Acceptance criteria and requirements help reduce ambiguity and establishes a defense against scope creep. If a requirement isn’t clearly defined at the start of a sprint, it becomes hectic to set it up in the midway, thus the need to use acceptance criteria.
Conclusion
If you are working with a team of other developers, project managers, stakeholders, or clients, being on the same page on a project that meets the acceptance criteria and requirement is vital. Understanding the difference between requirements and acceptance criteria can seem confusing and sometimes abstract. But it is pretty simple. When working on a specific project, the acceptance and requirements helps to define your goal. Goals can be numeric with any level of granularity from requirements, to specifications, to acceptance criteria which is what you need to achieve before you consider it done.
