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