Acceptance criteria
vs. Functional requirements
by Anna Dąbrowska
User stories
1. Who?
2. What?
3. Why?
Never go into development without the story or narrative having:
• priority
• story or narrative (depending on complexity)
• acceptance criteria
• knowing what the end to end test scenario is /are
• sign off from the customer for all of the above
• an estimate from iteration based on all of the above
What are Acceptance Criteria?
Acceptance Criteria are the conditions that a software product must
satisfy to be accepted by a user, customer, or in the case of system
level functionality, the consuming system.
Acceptance Criteria are a set of statements, each with a clear pass/fail
result, that can be measured and specify both functional and nonfunctional requirements.
Why to write?
• Define the boundaries for a user story/feature
• Help the product owner answer what she needs
in order for this feature to provide value
(typically these are the minimum functional requirements)
• Help the team gain a shared understanding
of the story/feature (BEFORE development has started)
• Help developers and testers to derive tests
• Help developers know when to stop adding
more functionality to a story
*Icons are created by Nathanael Coyne (@nathanaelb).
How to write?
Good acceptance criteria:
• State an intent not a solution (e.g. “The user can choose an
account” rather than “The user can select the account from a
drop-down”)
• Are independent of implementation
• Are relatively high level (not every detail needs to be in
writing)
• Are SMART
• Have observable result
• Include actor/actions/environment/conditions/context
• Are written from user perspective
How not to write?
Watch out for
• Ambiguous language
• Subjective/Judgemental language (Better, Good, Allowable)
• Generalisations (All the time, Never, Everyone, Always)
• Observed behaviour that is not directly related to the story
currently under consideration
Methods to write
1. Scenario style approach
• Happy Path
• Alternative Path
• Bad Path
2. BDD style acceptance criteria
• Given <a condition>
• When <an event occurs>
• Then <expect this outcome>
When to write?
! Avoid is writing acceptance criteria after development has
started
What. Not How
WHAT is expected,
and not HOW the functionality will be implemented.
Functional requirements
Requirements are what you're
supposed to do in terms of given
story.
Acceptance criteria
Acceptance Criteria are the agreed upon
measures to prove you've done.
Acceptance Criteria are defined as conditions
that a User Story must satisfy to be accepted
by a user, customer or other stakeholder.
Example. Try to write
As a user I want to switch application language so that I understand app
content
Functional requirements
1.
2.
3.
4.
5.
Site language corresponds to chosen one
Language can be changed
Default language icon appears in top right corner
English is a default language
Dropdown with list of languages appears by clicking on language flag in right
top corner
6. User can select language by clicking on corresponding one in drop-down
menu
7. Site content changes to selected language after user has clicked on its
name/icon in switching drop-down
8. List of languages and translations are grabbed from admin panel
Example. Try to write
As a user I want to switch application language so that I understand
app content
Acceptance criteria
1. User can change site language
2. Site content corresponds to selected
language
3.Translation is correct and doesn’t contain
critical mistakes
4. Translated content doesn't break any specific
layout
5. No bugs of high and normal priority related to
switching languages remain open
Questions?