Как писать качественные требования

1 Хорошее требование отвечает на вопросы
⚙️ Что?
Какое действие выполняется
👤 Кто?
Какая роль участвует
🗓️ Когда?
При каком условии
📊 Какие данные?
Какие поля, форматы, источники
🚩 Какой результат?
Что получится в итоге
🔍 Как проверить?
Критерий выполнено / не выполнено
⭐ Хорошее требование понятно, однозначно и проверяемо.
Плохое — заставляет команду додумывать.
2 Основные характеристики качественного требования
🎯
Однозначность
📋
Полнота
🔗
Согласованность
Корректность
🔧
Реализуемость
🔬
Проверяемость
🔹
Атомарность
(одна мысль)
🔀
Трассируемость
Требование должно быть понятным всем участникам:
бизнесу, разработке и тестированию.
3 Признаки плохого требования
  • Размытые слова: «быстро», «удобно», «актуально», «при необходимости» и т.п.
  • Неясная роль: «пользователь может…»
  • Неполный список данных, «и т.д.»
  • Нет условий, ошибок и исключений
  • Нельзя написать проверку
  • Несколько действий в одном требовании
  • Ссылка на другую систему без уточнения
✗  Плохое требование = разные трактовки, переделки и лишние затраты.
4 Примеры: было плохо → стало хорошо
Было плохо Стало хорошо
Система должна быстро загружать документы. Система должна отображать первые 50 документов не более чем за 2 секунды при количестве документов до 100 000.
Пользователь может удалять документ. Пользователь с ролью «Администратор документов» может удалить документ только в статусе «Черновик».
Система показывает актуальные документы. В разделе «Актуальные документы» отображаются документы со статусом «Опубликован», у которых дата окончания действия не заполнена или больше текущей даты.
Сделайте карточку как в Кадровом портале. Используем такой же порядок блоков: «Основная информация», «Файл для документа», «История изменений», «Согласование», «Права доступа». Состав полей и действия описаны в текущих требованиях.
5 Стоп-слова
Стоп-слово Почему опасно Как уточнить
актуальныйнепонятно, что именноуказать статус и даты
быстронельзя проверитьуказать время, нагрузку
удобносубъективноуказать сценарий и критерий
при необходимостинепонятно, при решаетуказать конкретное условие
и т.д.список открытперечислить все значения
в разумный срокнет точного срокауказать срок (часы/дни)
популярные форматынепонятно, какиеуказать конкретные форматы
⚠️ Каждое стоп-слово — повод уточнить смысл!
6 Описывай не только успешный сценарий
✗ Плохо

Пользователь загружает документ.

✔ Хорошо

Пользователь загружает файл в формате PDF, DOCX или XLSX размером не более 20 МБ. Если формат не поддерживается — сообщение. Если размер превышает 20 МБ — сообщение. Пользователь может повторить загрузку.

ℹ️ Опиши ошибки, альтернативные сценарии, значения по умолчанию, поведение при изменении связанных данных.
7 Почему плохие требования дорого стоят
Этап Что приводит к мести
📝 Требованияточное требование
🎨 Проектированиетребования, макеты, правила отображения
💻 Разработкатребования, макеты, данные, код
🧪 Тестированиетребования, код, тесты
🚀 После запускакод, тесты, инструкции, поддержка пользователей
💰 Чем позже нашли ошибку — тем дороже исправлять.
8 Роли и проверка требований
👤 Бизнес-аналитик
  • знает нужды бизнеса
  • ясно формулирует цели
  • кто участвует в процессе
  • соответствует ли правилам бизнеса
  • не детали и лишнего
Зачем пользователю нужна эта функция?
⚙️ Системный аналитик
  • какие данные нужны
  • откуда берутся данные
  • статусы и переходы
  • ошибки и исключения
  • влияние на БД, интеграции, интерфейсы
  • реализуемость и проверяемость
Откуда берутся данные и что делать, если их нет?
9 Мини-чек-лист перед передачей требования в работу
  • Понятно, кто и что делает?
  • Описаны условия и данные?
  • Есть ошибки и исключения?
  • Нет размытых слов «и т.д.»?
  • Нет противоречий?
  • Можно написать проверку?
  • Одна мысль в требовании?
  • Если есть пример из другой системы — уточнено, что берём?
10 Формула хорошего требования
👤
КТО
выполняет
+
⚙️
ЧТО ДЕЛАЕТ
какое действие
выполняется
+
🔽
ПРИ КАКОМ
УСЛОВИИ
и когда
+
💾
С КАКИМИ
ДАННЫМИ
+
🚩
КАКОЙ
РЕЗУЛЬТАТ
+
🔍
КАК
ПРОВЕРИТЬ
критерий
=
ХОРОШЕЕ
ТРЕБОВАНИЕ