Оно должно быть понятно тому, кто будет его реализовывать, тестировать и принимать. Поэтому перед тем, как сказать «требование готово», можно прогнать его через небольшой чек-лист. 1. Понятно ли, зачем это нужно? Если убрать контекст и оставить только «система должна…», иногда становится непонятно, какую проблему вообще решаем. Хорошее требование отвечает не только на «что сделать?», но и помогает понять «зачем?» 2. Нет ли в нём двусмысленности? «Быстро», «удобно», «при необходимости», «корректные данные», «актуальная информация» — звучит понятно, пока не нужно это реализовать или протестировать. Вопрос для аналитика: 👉 А два разных человека одинаково поймут эту формулировку? 3. Можно ли это проверить? Если QA не может однозначно определить, выполнено требование или нет, то скорее всего, его стоит уточнить. Например: ❌ «Система должна быстро отправлять уведомление». ✅ «Система должна отправить уведомление не позднее 1 минуты после изменения статуса». 4. Описаны ли исключения? Основной сценарий обычно написать легко. Гораздо интереснее спросить: - А если данных нет? - А если пользователь сделал это повторно? - А если действие выполнить нельзя? - А если внешняя система недоступна? Именно здесь часто прячется половина требований. 5. Не спрятано ли решение внутри требования? «Добавить кнопку справа в верхнем углу» - это уже решение. А возможно, бизнес-задача вообще была в другом: дать пользователю возможность быстро выполнить действие. Иногда полезно сначала зафиксировать что нужно получить, а уже потом обсуждать как именно это реализовать.

И мой любимый финальный тест: Если разработчик задаёт вопрос «А что должно произойти, если…?» — ответ уже есть в требованиях или мы сейчас будем придумывать его на ходу? Если второе — требования, скорее всего, ещё не готовы 🙂

Каким своим вопросом вы проверяете качество требований перед передачей в разработку?