Presentation is loading. Please wait.

Presentation is loading. Please wait.

Acceptance criteria vs. Functional requirements by Anna Dąbrowska.

Similar presentations


Presentation on theme: "Acceptance criteria vs. Functional requirements by Anna Dąbrowska."— Presentation transcript:

1 Acceptance criteria vs. Functional requirements by Anna Dąbrowska

2 1.Who? 2.What? 3.Why? User stories 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

3 What are Acceptance Criteria? Acceptance Criteria are a set of statements, each with a clear pass/fail result, that can be measured and specify both functional and non- functional requirements. 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.

4 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).

5 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

6 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

7 Methods to write 1.Scenario style approach Happy Path Alternative Path Bad Path 2.BDD style acceptance criteria Given When Then

8 When to write? ! Avoid is writing acceptance criteria after development has started

9 WHAT is expected, and not HOW the functionality will be implemented. What. Not How Functional requirementsAcceptance criteria Requirements are what you're supposed to do in terms of given story. 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.

10 Example. Try to write Functional requirements 1.Site language corresponds to chosen one 2.Language can be changed 3.Default language icon appears in top right corner 4.English is a default language 5.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 As a user I want to switch application language so that I understand app content

11 Example. Try to write 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 Acceptance criteria As a user I want to switch application language so that I understand app content

12 Questions?


Download ppt "Acceptance criteria vs. Functional requirements by Anna Dąbrowska."

Similar presentations


Ads by Google