В требовании объединены условие, действие и ограничение. Как определить, что его нужно разделить на несколько требований?
Требование следует разделить, если его части имеют независимые условия приёмки, могут изменяться отдельно или относятся к разным ответственным компонентам. Само наличие условия, действия и ограничения ещё не означает, что нужны три требования: их можно оставить вместе, если они описывают одну неделимую проверяемую потребность.
Практики декомпозиции требований появились как ответ на неоднозначные спецификации, в которых несколько утверждений скрывались под одной формулировкой. Такие требования было трудно согласовать, оценить, связать с реализацией и проверить тестами.
Декомпозиция не означает механического дробления каждого предложения. Её цель — сделать отдельные утверждения управляемыми: каждое должно иметь понятный смысл, способ проверки и историю изменений.
Например, фраза может требовать: при превышении лимита система отклоняет платеж, записывает причину в журнал и уведомляет оператора. Если все эти части оформлены как одно требование, изменение формата уведомления может выглядеть как изменение всего поведения платежа.
Это создаёт несколько рисков: неполное тестирование, неясную оценку трудоёмкости, сложный анализ влияния и споры о том, какая часть требования не выполнена. Особенно опасно, когда одна часть обязательна, а другая допускает варианты.
Сначала нужно выделить отдельные атомарные утверждения и проверить их по четырём признакам:
Если хотя бы один из этих признаков выражен явно, разделение обычно повышает управляемость. Условие при этом не обязательно превращать в отдельное требование: чаще оно становится предусловием или частью критерия применимости основного требования.
Ограничение также не всегда выделяется отдельно. Например, требование о времени ответа может оставаться частью операции, если без этого ограничения операция теряет смысл и они всегда изменяются совместно. Но если ограничение распространяется на несколько функций, его разумнее оформить как отдельное нефункциональное требование с указанием области действия.
После декомпозиции нужно проверить исходный смысл. Новые требования должны сохранять связи между условием, действием и ограничением; нельзя превратить одно условное поведение в безусловное или потерять обязательность части правила.
Полезный результат — набор требований, каждое из которых имеет собственный идентификатор, источник, критерии приёмки и связи с бизнес-целью. При этом дробление не должно создавать искусственные микротребования, которые нельзя понять или проверить отдельно.
В проекте было требование: «При просрочке договора система блокирует доступ пользователя, отправляет письмо менеджеру и хранит запись о причине блокировки не менее пяти лет». Команда рассматривала два варианта.
Первый — оставить одну формулировку. Это сохраняло связь событий, но затрудняло оценку: блокировка, уведомление и хранение имели разных владельцев и разные риски. Второй — разделить требование на три связанных утверждения, сохранив просрочку как общее условие и добавив ссылку на исходное бизнес-правило.
Выбрали второй вариант. Блокировка получила функциональные критерии приёмки, письмо — отдельные требования к получателю и содержанию, хранение — проверяемый срок и область данных. В результате изменение шаблона письма не требовало пересмотра логики блокировки, а анализ влияния стал локальным.
Не обязательно. Несколько критериев могут проверять одну целостную возможность. Разделение оправдано, когда критерии описывают независимые результаты, имеют разные жизненные циклы или могут быть приняты отдельно. Простое количество критериев само по себе не является достаточным основанием.
Нет, по одному союзу это определить нельзя. Фраза «система проверяет реквизиты и отклоняет платёж» может описывать одну неделимую бизнес-операцию. Нужно оценить независимость изменений, проверки и ответственности, а не искать конкретное слово в тексте.
Их можно оставить в одном функциональном требовании, но явно разделить внутреннюю структуру: предусловие, основное поведение, ограничения и критерии приёмки. Если части всегда реализуются и изменяются совместно, искусственное разделение ухудшит трассировку и понимание. При этом связанные нефункциональные ограничения можно дополнительно вынести в отдельные требования с явной ссылкой на функцию.