На что обращаешь внимание при получении требований?

Критерии анализа требований при их получении

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

Ясность и конкретность

Понятность формулировок

• Избегаю расплывчатых фраз — "сделать удобнее", "оптимизировать" без конкретики
• Проверяю операциональность — могу ли я написать тест-кейс, который будет проверять выполнение этого требования?
• Абстрактные термины уточняю конкретно — что значит "быстрая система"? 1 секунда? 100мс?
• Примеры и сценарии требую при получении требований

Полнота

• Граничные случаи — что происходит при некорректных данных, пустых полях, максимальных нагрузках?
• Исключительные ситуации — как система должна вести себя при ошибках?
• Точки интеграции — с какими другими системами нужна связь?
• Масштабируемость — на сколько пользователей рассчитано решение?

Бизнес-контекст

Цели и обоснование

• Зачем это нужно бизнесу? — какую проблему решает требование?
• Метрики успеха — как мы измерим, что требование выполнено хорошо?
• Приоритезация — насколько это важно относительно других требований?
• Стратегические связи — как это требование связано с бизнес-стратегией?

Заинтересованные стороны

• Кто использует эту функцию? (конечные пользователи, админы, интеграторы)
• Кто платит — product owner, бизнес-спонсор?
• Кто затронут изменениями — support, sales, операции?
• Консенсус — согласны ли все ключевые stakeholders с требованием?

Технические аспекты

Реалистичность

• Техническая осуществимость — это реально построить за отведённое время?
• Согласованность с архитектурой — не требует ли это полного переписания системы?
• Технологические ограничения — есть ли известные ограничения платформ или интеграций?
• Зависимости — от каких других компонентов/систем это зависит?

Нефункциональные требования

• Производительность — время отклика, пропускная способность
• Безопасность — кто и когда может получить доступ?
• Надёжность — какой уровень доступности требуется? (99.9%? 99.99%?)
• Интероперабельность — стандарты, API, форматы данных
• Локализация — поддержка разных языков и регионов?

Документирование

Формат и трассируемость

• ID и версионирование — каждому требованию уникальный идентификатор
• Источник — откуда взялось требование? (интервью, баг, стратегия)
• Дата получения — когда появилось требование?
• Статус — новое, уточняется, одобрено, реализовано, отклонено
• История изменений — что менялось в требовании и почему?

Красные флаги

При получении требований я внимательно слушу и смотрю на такие признаки:

• "Это же очевидно" — если требование очевидно, почему его нужно было специально оговаривать?
• Конфликт требований — требование противоречит уже существующему
• Требование — это решение — stakeholder описывает решение вместо проблемы
• Расхождение в видении — разные люди одно и то же требование понимают по-разному
• Отсутствие commitment — никто не готов за требование отвечать
• Зависимость от внешних факторов — требование зависит от третьей стороны, которая не контролируется

Процесс уточнения

Техники сбора информации

• Пять почему (5 Whys) — копаю глубже в причины
• Интервью и фокус-группы — прямое общение с пользователями
• Наблюдение — смотрю как люди сейчас работают
• Прототипирование — быстро создаю макет и показываю stakeholders
• Анализ данных — статистика использования, боль-поинты

Заключение

Получение требований — это не одноразовое событие, а начало диалога. Я смотрю на ясность, полноту, бизнес-обоснованность и техническую реалистичность. Правильно проанализированное требование — это 50% успеха проекта.