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