Представим задачу: в приложении «Сытый зайка» нужно добавить возможность оплачивать заказ баллами. История звучит так: «Как пользователь я хочу иметь возможность оплачивать заказ баллами, чтобы использовать накопленные бонусы». 📌 Описание истории по шаблону помогает понять задачу и цель, но оно не даёт ответа, как именно функция должна работать. Здесь в дело вступают критерии приёмки. 🧩 С чего начинает аналитик Аналитик задаёт себе вопрос: «Что команда должна проверить, прежде чем передать функцию клиентам?» Чтобы ответить, он формирует список вопросов заказчику, например: В каком виде пользователь видит информацию о начисленных баллах? Если баллы не были начислены, должен ли заказ отображаться в истории? Если да — то как? Что происходит с записью в истории при частичном или полном возврате заказа? Обсуждение таких нюансов помогает зафиксировать корректные критерии приёмки. 📊 Как оформлять критерии ❌ В критериях не стоит описывать все детали до мелочей (например, формат отображения даты или точное расположение кнопки). ✅ Лучше использовать принцип: «Один раз увидеть, чем сто раз услышать». Поэтому аналитик прикрепляет к истории простой пример — таблицу или мокап экрана (пусть даже черновой) — и согласовывает его с заказчиком. ⚡ Функциональные и нефункциональные критерии Критерии приёмки отражают ожидания пользователя от системы: функциональные (что должно работать), нефункциональные (как быстро или надёжно это должно работать). Например, в истории может появиться нефункциональное требование:

«Система должна обновлять историю начисления баллов в течение нескольких секунд». Тогда к карточке добавляется критерий: «История начисления баллов обновляется не дольше 2 секунд после изменения заказа». 📌 В итоге критерии приёмки помогают аналитикам и разработчикам говорить с заказчиком на одном языке и избегать двусмысленностей.