Бизнес-аналитик должен формализовать критерии приёмки (acceptance criteria) для каждого требования так, чтобы они были понятны и однозначны для всех участников проекта: заказчика, разработчиков и тестировщиков. Для этого применяются техники спецификации, такие как формулировка критериев в нотациях Gherkin (Given-When-Then), чек-листы и примеры использования (use cases). Аналитик документирует критерии в артефактах требований и заботится, чтобы к каждому требованию был набор объективных условий, посредством которых можно однозначно подтвердить выполнение задачи.
Ключевые особенности:
Можно ли использовать только пользовательские истории для описания требований, без дополнительных критериев приёмки?
Нет, пользовательские истории без явных критериев приёмки слишком абстрактны и могут быть интерпретированы по-разному. Критерии нужны, чтобы понять, что требование реализовано правильно.
Нужно ли включать нефункциональные требования (например, производительность) в критерии приёмки?
Да, нефункциональные требования тоже следует формализовать в критериях, иначе их риск незаметно забыть или реализовать не в полной мере.
Кто должен утверждать критерии приёмки: только бизнес-аналитик?
Нет, всегда необходимо согласование критериев с заказчиком и, по возможности, командой разработки, чтобы минимизировать недопонимание.
Негативный кейс: Бизнес-аналитик не согласовал критерии приёмки с заказчиком, а разработчики поняли требования по-своему. Плюсы: Быстрая разработка, никакие созвоны не задерживали процесс. Минусы: После релиза 70% функциональности не соответствовало реальным ожиданиям, возник конфликт.
Положительный кейс: Аналитик расписал формальные критерии приёмки, согласовал их с обеими сторонами и приложил к пользовательским историям. Плюсы: Понимание между заказчиком и командой, минимум багов после релиза. Минусы: На старте ушло немного больше времени на согласования.