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

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

Это один из критических вопросов в работе BA, потому что неполные требования приводят к переделкам, срывам сроков и конфликтам. Дать точный ответ сложно, но есть признаки, которые помогают убедиться в полноте.

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

1. Прохождение критериев приёмки (Acceptance Criteria)

• Каждый requirement имеет измеримые AC
• Разработчик может спросить: «как я узнаю, что это сделано?» — на это есть ответ
• Тестировщик может написать тест-кейсы на основе AC
• Product Owner согласен с AC

2. Покрытие сценариев и граничных случаев

• Нормальный путь (happy path)
• Путь ошибки (error path)
• Граничные случаи (edge cases)
• Исключительные ситуации (exceptions)

Примеры вопросов, на которые должны быть ответы:

• Что если пользователь оставит поле пустым?
• Как система ведёт себя при большом объёме данных?
• Что делать при потере соединения?

3. Понимание зависимостей и взаимодействий

• Какие другие функции будут затронуты?
• Какие данные нужны из других систем?
• Как это интегрируется с существующей архитектурой?
• Есть ли конфликты с текущей функциональностью?

4. Ясность по приоритету и скопу

• Что входит в MVP, а что на потом?
• Какие требования обязательны, какие желательны?
• Какие можно отложить без ущерба бизнесу?

Практические методы проверки

Встреча трёх мушкетёров Созвать Product Owner, разработчика и тестировщика. Прочитать требования вслух. Если возникают вопросы — требования неполные.

Вопросы, которые должны задать разработчик:

• На какой БД это хранить?
• Какую библиотеку использовать?
• Как это тестировать?

Вопросы, которые должны задать тестировщик:

• По какому признаку это работает правильно?
• Что такое "быстро" в требовании «система должна работать быстро»?
• Как воспроизвести баг, если он возникнет?

Если вопросов нет — требования готовы.

Прототипирование или моки

• Нарисовать UI (если это веб)
• Показать бизнесу и техническим людям
• Собрать фидбек
• Уточнить требования на основе фидбека

Техническое планирование (Technical Planning)

• Может ли архитектор спроектировать решение на основе требований?
• Есть ли технические риски или вопросы?
• Реалистична ли оценка сроков?

Если архитектор говорит «не понимаю, как это реализовать» — требования неполные.

Признаки неполноты (красные флаги)

• Много слов из категории "может быть", "возможно", "примерно"
• Требование одно предложение, а должно быть несколько абзацев
• Нет примеров или контрпримеров
• Разные люди интерпретируют одно требование по-разному
• Тестировщик не может написать тест-кейс
• Разработчик просит уточнения уже во время разработки
• Нет описания, кто пользователь и для чего ему это нужно

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

Хороший BA документирует не только требования, но и:

• Что НЕ входит в скоп (out-of-scope)
• Какие предположения были сделаны
• Кто согласовал требования (sign-off)
• Дата утверждения
• Версию документа

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

Золотой стандарт полноты

Значит требования собраны правильно, если:

1. Разработчик может начать писать код без вопросов
2. Тестировщик может написать полный набор тест-кейсов
3. Product Owner согласен и подписал документ
4. Пользователь может объяснить, как это улучшит его работу
5. Архитектор видит, как это встраивается в систему
6. Операционник знает, как это поддерживать в продакшене

Если хотя бы одна из этих групп скажет «хм, непонятно» — надо ещё работать над требованиями.