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

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

Это один из самых практичных вопросов в работе BA. Собрать "все" требования невозможно (всегда найдется что-то новое), но можно определить "достаточно". Вот критерии и методы проверки.

Основные признаки полноты требований

Согласие стейкхолдеров — все ключевые стороны (менеджмент, бизнес-пользователи, IT-лидеры) согласны, что требования описаны полно

Нет противоречий — требования не конфликтуют друг с другом, нет двусмысленностей

Тестируемость — каждое требование можно проверить (есть критерии приёмки, четкие условия)

Связность с целями — каждое требование можно связать с бизнес-целью проекта

Практическое применение — команда разработки может приступить к проектированию без дополнительных уточнений

Методы проверки полноты

1. Чек-лист требований

Функциональные требования:
☑ Описаны все основные сценарии (happy path)
☑ Описаны альтернативные сценарии (happy path variations)
☑ Описаны сценарии ошибок (error handling)
☑ Определены все интеграции с другими системами
☑ Описаны все отчёты и экспорты

Нефункциональные требования:
☑ Определены требования к производительности
☑ Определены требования к безопасности и доступу
☑ Определены требования к масштабируемости
☑ Определены требования к надежности/доступности (SLA, uptime)
☑ Определены требования к совместимости (браузеры, ОС, устройства)

Процессные требования:
☑ Определены все участники (роли, их действия, права)
☑ Определены сроки (дедлайны, таймауты)
☑ Определены уведомления и алерты
☑ Определены бизнес-правила (валидация, ограничения)
☑ Определены требования к миграции данных (если модиф система)

2. Review с заинтересованными лицами

Техническое review:

• Архитектор: "Это реалистично реализовать? Нужны ли какие-то уточнения?"
• Разработчики: "Есть ли блокирующие вопросы? Что не ясно?"
• QA: "Можно ли это протестировать? Хватает ли информации для тест-кейсов?"

Бизнес-review:

• Менеджер проекта: "Это соответствует видению? Ничего не забыли?"
• Бизнес-пользователи: "Это решает вашу проблему? Что ещё нужно?"
• Стейкхолдеры: "Это бизнес-ценность? Согласны ли вы с приоритизацией?"

3. Прототипирование и валидация

Wireframes/макеты — нарисуйте UI и покажите пользователям

• "Это то, что вы имели в виду?"
• Обычно выявляет 20-30% упущенных требований

Демо-прототип — создайте интерактивный прототип (Figma, proto.io)

• Пользователи видят реальный flow
• Всплывают вопросы: "А что если...?" или "А почему бы не...?"

User Story Mapping — выстройте все сценарии визуально

• Видны пробелы и пересечения
• Помогает выявить упущенные edge cases

4. Анализ критериев приёмки

Если для каждого требования есть четкие критерии приёмки (AC — Acceptance Criteria), значит вы глубоко разобрались:

Story: "Авторизованный пользователь может оформить заказ"

AC 1: При клике на кнопку "Оформить заказ" система валидирует корзину
      ✓ Если товар недоступен → показать ошибку "Товар недоступен"
      ✓ Если товар закончился → показать ошибку "Товар закончился"

AC 2: Система проверяет наличие адреса доставки
      ✓ Если адреса нет → показать форму ввода адреса
      ✓ Если есть сохранённые адреса → дать выбрать из списка

AC 3: После подтверждения системе заказ → создаётся в БД
      ✓ Заказ имеет статус "Новый"
      ✓ Отправляется письмо клиенту

Если AC есть, требование полно.

5. Анализ граничных случаев (Edge Cases)

Требование полно, если вы описали:

• Минимальные значения (0, "", null)
• Максимальные значения (максимальный заказ, максимальный размер файла)
• Граничные условия (сегодня / завтра, текущий месяц / прошлый)
• Невалидные данные (неправильный формат, спецсимволы)
• Параллельные действия (два пользователя одновременно)
• Отказы (интернет упал, сервер недоступен)

6. Матрица требований (Traceability Matrix)

Постройте таблицу:

Если есть требование без источника или без тест-кейсов → требование недоопределено.

7. Time-box для сбора требований

На практике нужна остановка:

• Малые проекты (1-2 месяца): 2-3 недели сбора требований
• Средние проекты (3-6 месяцев): 4-6 недель
• Крупные проекты (6+ месяцев): 6-8 недель

Если выбегаете из time-box → требования будут собираться во время разработки (agile подход).

Красные флаги (что-то не собрано)

• Разработчики задают одинаковые вопросы разным людям и получают разные ответы
• На каждой планёрке появляются новые требования (не уточнения, а новые)
• Стейкхолдеры спорят о том, что должно быть (значит требования не согласованы)
• QA не может написать тест-кейсы (требования не ясны / не тестируемы)
• Прототип вызывает большие изменения в дизайне (требования вводили в заблуждение)

Практический совет

Требования "полны", когда:

1. Статус изменений → Стабилизация

   • Первые 2 недели: много новых требований
   • Недели 3-4: только уточнения и небольшие добавления
   • Неделя 5: уточнения прекращаются

2. Команда может начинать разработку без блокирующих вопросов

3. Нет противоречий в документации и у стейкхолдеров

4. Все подписали документ (BRD / SRS)

Важный момент

Требования никогда не "полны" на 100% — это нормально. В agile-методологии требования собираются итеративно, по спринтам. BA должен убедиться, что для текущей итерации/спринта требования достаточны для начала разработки.

Определить полноту требований — это искусство, основанное на опыте. С каждым проектом вы будете лучше чувствовать, когда "хватит".