1️⃣ Проверяем КАЖДОЕ требование ➖Полнота — вся нужная инфа на месте, пробелы помечаем TBD (to be determined пометка, которая используется для обозначения пробелов в данных). ➖Корректность — есть связь с источником: история, бизнес-цель, use-case. ➖Осуществимость — реально сделать за деньги, время, техстек. При сомнении ― прототип / POC (Proof of Concept). ➖Необходимость — приносит бизнес-ценность или  закрывает регуляторные требования, а не просто идея. ➖Недвусмысленность — простой язык, одно толкование, убираем "предоставляет возможность".

2️⃣ Проверяем НАБОР требований ➖Полнота -> нет TBD и скрытых предположений . ➖Согласованность -> пункты не спорят друг с другом и с верхним уровнем. ➖Модифицируемость -> уникальные ID, история изменений, связи.

3️⃣ Пиши просто и понятно ➖Начинай с глагола в форме: Система ДОЛЖНА…. ➖Убирай лишние официальные слова: должна вместо должна предоставлять возможность. ➖Каждое предложение ≤ 15 слов, один абзац — одна мысль.

4️⃣ Закрывай логические дыры ➖Если есть два бинарных выбора, получаем 4 комбинации — опиши все. ➖Например: в требованиях сказано, что у тарифа Премиум есть страховка, но не описано, что делать, если пользователь сменит тариф. Команда додумает логику сама, и на проде всплывёт баг: страховка то остаётся, то пропадает хаотично. ➖Всегда добавляй требование - пару на исключения: если не смог сохранить файл, то…

5️⃣ Как довести документ до идеала ➖Пометь TBD, где нет данных. ➖Собери 3–6 стейкхолдеров на совместную сессию, пройдись по чек-листу качеств и убери конфликтные или лишние пункты. ➖Перепиши слабые формулировки — пока не станет ясно что тестировать.

Итог: идеальное требование не про красоту, а про ясность, полноту и проверяемость. Стисни текст, вычисти двусмысленность, свяжи с бизнес-целью — команда скажет спасибо, а продукт выйдет без сюрпризов.

#it #аналитик #навыкАналитика #требования