Ответ.

История вопроса:

С ростом масштабов и сложности ИТ-проектов неоднократно возникала ситуация, когда от бизнес-заказчика требования поступали в виде абстрактных пожеланий, которые при передаче в команду разработки превращались в нечто иное. Причиной выступает разрыв в терминологии, ожиданиях и уровне абстракции между бизнесом и ИТ.

Проблема:

Если не продумать этап декомпозиции, требования либо становятся неполными (упущены критические детали), либо избыточно размыты (невозможно оценить и реализовать), либо вообще искажаются из-за лексических ловушек, неучтенной терминологии и разночтений.

Решение:

Системный аналитик последовательно декомпозирует каждое требование: формализует бизнес-термины, переводит бизнес-цели в функции и задачи, описывает сценарии пользователя и системное поведение, привязывает к критериям приемки/тест-кейсам. Важно использовать модели (UML, BPMN), глоссарии, чек-листы и непосредственное ревью между командами.

Ключевые особенности:

Построение глоссария терминов совместно с заказчиком
Использование диаграмм и атомарных формулировок требований
Перевод требований на язык критериев приемки и тест-кейсов

Вопросы с подвохом.

Можно ли оставить бизнес-пожелания в свободной форме с дальнейшей доработкой на этапе разработки?

Нет, высок риск недопонимания и ошибок реализации.

Нужно ли доводить до деталей реализации (например, как хранить данные) на этапе анализа?

Нет, анализ — про "что" и "зачем", а не "как". Технические детали — зона ответственности архитектуры и разработки.

Всегда ли одна запись требования = один модуль/фича?

Нет, часто требуется декомпозиция — крупные требования делятся на под-функции и user stories с отдельными критериями приемки.

Типовые ошибки и анти-паттерны

Смешивание бизнес-языка и технических терминов без глоссария
Описание требований в виде "размытых желаний"
Нарушение атомарности — одно требование содержит множество разных сущностей

Пример из жизни

Негативный кейс: Заказчик передал перечень пожеланий "Пользователь должен видеть всю аналитику по продажам", в ТЗ скопировали в неизменном виде.

Плюсы:

Быстрота подготовки документации

Минусы:

Неясно, какие именно метрики и в каком разрезе нужны
Постоянные доработки

Положительный кейс: Аналитик расспросил заказчика, составил список необходимых метрик, определил роли пользователей, разработал прототипы отчетов, согласовал глоссарий терминов.