Метрики требований — это набор измеримых показателей, которые помогают понять, насколько требования в проектной документации полные, понятные, проверяемые и реально покрывают цели бизнеса: от «ничего не забыли» до «это можно тестировать и разрабатывать без гаданий на кофейной гуще».

Если вы меняете профессию на IT или уже джун и устали от требований вида «сделать удобно», то вот неприятная правда: большинство фейлов проектов случается не потому, что «программисты плохие», а потому что требования — туман. Туман красиво смотрится в презентации, но в разработке превращается в переработки, баги и взаимное «я не это имел в виду».

Я видел проекты в российских компаниях, где один абзац в Confluence (или в Битрикс24, не суть) стоил месячной переделки в 1С или веб‑системе. И наоборот: нормальная метрика требований иногда спасает бюджет лучше любого «строгого контроля сроков». Потому что сроки — это следствие.

Зачем вообще нужны метрики требований (и почему это не бюрократия)

Тезис: метрики проектной документации нужны не ради отчётов, а чтобы управлять риском «дорогой ошибки» до начала разработки.

Обоснование: цена исправления ошибки растёт по мере движения вправо по жизненному циклу (идея → требования → разработка → тестирование → прод). В российских реалиях это особенно больно, когда релиз завязан на интеграции с 1С, Госуслугами, ЕПГУ/СМЭВ, платежами (ЮKassa/СБП) или внутренними шинами — любое «ой» становится цепной реакцией.

Практический вывод: метрики требований — ваш способ доказать, что «мы готовы к разработке», а не просто «мы что-то написали».

Подводный камень: люди начинают мерить то, что легко мерить (количество страниц), а не то, что снижает риск (проверяемость, однозначность, покрытие сценариев).

Какие бывают метрики требований: качество и покрытие — это разные звери

1) Метрики качества требований (насколько требование “хорошее”)

Тезис: качество — это про однозначность, атомарность и тестируемость. По сути, «можно ли по этому тексту сделать задачу разработчику и тест-кейс QA».

Обоснование: требование, которое нельзя проверить, на практике означает: критериев приёмки нет, значит спор неизбежен.

• Процент требований с критериями приёмки (Acceptance Criteria, AC): сколько требований имеют чёткое «готово, когда…».
• Тестируемость (verifiability): можно ли подтвердить выполнение без “мне кажется”.
• Однозначность: количество “слов-туманов” на страницу/на требование (удобно, быстро, интуитивно, по возможности, желательно) и число разных трактовок на ревью.
• Атомарность: одно требование = одна мысль. Если там «и», «а также», «плюс ещё» — часто это уже 3 требования в плаще.
• Полнота атрибутов: есть ли у требования ID, источник (стейкхолдер), приоритет, статус, версия, ссылка на макет (Figma), ссылка на задачу (Jira/YouTrack), готовность данных.

Практический вывод: если вы не знаете, как оценивать требования — начните с «AC coverage»: доля требований с критериями приёмки обычно лучше всего коррелирует с предсказуемостью разработки.

Подводный камень: «критерии приёмки» превращают в пересказ требования другими словами. AC должны быть проверяемыми, а не литературными.

2) Метрики покрытия требований (не забыли ли мы важное)

Тезис: покрытие — это про то, что система решает все нужные бизнес-задачи и учитывает сценарии, а не только “счастливый путь”.

Обоснование: 80% конфликтов «мы сделали, а вы недовольны» возникают из-за непокрытых исключений: права доступа, ошибки интеграций, частичный отказ сервиса, отсутствие данных.

• Покрытие бизнес-целей: доля целей/OKR, для которых есть явные требования и сценарии.
• Покрытие пользовательских ролей: для каждой роли есть свои сценарии и ограничения (например: оператор, руководитель, админ).
• Покрытие сценариев: happy path + минимум N альтернативных/ошибочных сценариев на ключевой процесс.
• Покрытие НФТ (нефункциональных требований): производительность, безопасность, отказоустойчивость, аудит, хранение данных (особенно если персональные данные и 152‑ФЗ рядом).
• Traceability coverage (покрытие трассируемости): требования связаны с задачами разработки, тестами и релизами.

Практический вывод: заведите простую матрицу трассируемости «Цель → Требования → Тесты». Даже в Excel. Это скучно, но экономит недели.

Подводный камень: нельзя «закрыть покрытие» количеством требований. Можно написать 200 требований и забыть ключевую роль — и привет.

Минимальный набор метрик, который реально работает (и не убивает команду)

Тезис: 5 метрик выше дают 80% пользы, если измерять их регулярно (раз в спринт/итерацию) и обсуждать на груминге/планировании.

Подводный камень: метрики не заменяют разговор. Они подсвечивают, куда смотреть.

Как оценивать требования на практике: короткий процесс на 30–60 минут

1. Выберите срез: 10–20 требований, которые идут в ближайшую разработку.
2. Проверьте качество: есть ли AC, нет ли тумана, одно ли это требование.
3. Проверьте покрытие: роли, исключения, НФТ, интеграции (1С, СБП, почта, СМС, шина).
4. Проставьте связи: требование → задача в трекере (YouTrack/Jira) → тест (TestRail/любая таблица).
5. Заведите “долг требований”: список того, что надо уточнить до старта, иначе будет “платно” и позже.

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

Подводный камень: пытаться “додокументировать вселенную”. Важно покрыть то, что реально идёт в работу.

Два кейса из жизни: как метрики спасают (или не спасают)

Кейс удачный: AC coverage спас релиз

Проект: внутренний сервис заявок (типичный для российской компании: роли, согласования, интеграция с 1С). Команда спорила про «готово», бизнес постоянно приносил правки.

Что сделали: ввели правило — в разработку не уходит ни одно требование без 3–7 критериев приёмки и без описания хотя бы одного негативного сценария (ошибка интеграции/нет прав).

Результат: количество возвратов задач с тестирования упало заметно уже на второй итерации. Не магия — просто стало понятно, что именно проверять.

Кейс провальный: “страниц много — значит хорошо”

Проект: клиентский кабинет. Документации — 120 страниц в Confluence, схемы, диаграммы, всё как любят. Метрик нет, трассируемости нет.

Что пошло не так: забыли НФТ на пиковую нагрузку и логику деградации при падении внешнего сервиса. На проде — тормоза, ручной разбор инцидентов, репутационный урон.

Вывод: метрики проектной документации должны мерить не объём, а готовность к разработке и тестированию.

Экспертный вердикт и инструмент: чек‑лист “требования готовы к разработке?”

• Есть критерии приёмки? Не “должно быть удобно”, а проверяемые условия.
• Требование однозначно? Два разработчика прочитают одинаково.
• Требование атомарно? Одна функция/правило, а не «комбайн».
• Покрыты роли и исключения? Что будет при ошибке, отсутствии данных, нехватке прав.
• Есть НФТ там, где больно? Скорость, безопасность, аудит, хранение, доступность.
• Есть трассируемость? Связь цель → требование → задача → тест → релиз.
• Понятна “цена изменения”? Что сломается, если бизнес передумает.

Если хочется углубиться в смежные практики (процесс, роли, типичные грабли аналитика и PO), на https://itokno.ru регулярно выходят статьи в той же логике: меньше мистики, больше измеримости.

Частые вопросы