A business analyst should formalize the acceptance criteria for each requirement so that they are clear and unambiguous for all project stakeholders: clients, developers, and testers. Techniques such as formulating criteria in Gherkin notation (Given-When-Then), checklists, and use cases are used for this purpose. The analyst documents the criteria in requirement artifacts and ensures that each requirement has a set of objective conditions through which the completion of the task can be clearly confirmed.
Key features:
Can user stories be used alone to describe requirements without additional acceptance criteria?
No, user stories without explicit acceptance criteria are too abstract and can be interpreted differently. Criteria are needed to understand that the requirement has been implemented correctly.
Should non-functional requirements (e.g., performance) be included in acceptance criteria?
Yes, non-functional requirements should also be formalized in the criteria, otherwise, there is a risk of forgetting them or not fully implementing them.
Who should approve the acceptance criteria: only the business analyst?
No, criteria should always be aligned with the client and, if possible, the development team to minimize misunderstandings.
Negative case: The business analyst did not agree on acceptance criteria with the client, and the developers understood the requirements in their own way. Pros: Fast development, no calls delayed the process. Cons: After the release, 70% of the functionality did not meet real expectations, leading to conflict.
Positive case: The analyst outlined formal acceptance criteria, agreed on them with both parties, and attached them to the user stories. Pros: Understanding between the client and the team, minimum bugs after the release. Cons: A bit more time spent on approvals at the start.