Классификация бизнес-правил

Главные идеи#

Что такое бизнес-правило#

К бизнес-правилам (business rules) относятся корпоративные политики, государственные нормативные акты, отраслевые стандарты и методы расчёта. Они действуют, даже если процесс полностью ручной. Правило — это не бизнес-процесс (последовательность шагов) и не бизнес-требование (цель). Оно формирует процессы: определяет словарь, вводит ограничения, запускает действия и управляет расчётами.

Одно правило — много видов требований#

Правило может порождать требования любого уровня. Новый нормативный акт может задать бизнес-цель целого проекта. Политика конфиденциальности может определять, каким пользователям что разрешено. Правило может требовать конкретной функции системы. Нормы безопасности могут превратиться в атрибуты качества.

Типы#

1. Факты — утверждения, верные для бизнеса на определённый момент; обычно они связывают между собой термины: «у каждого контейнера есть уникальный штрихкод». Фактов у компании бесконечно много; собирайте только те, что связаны с границами вашего проекта.
2. Ограничения — что система или её пользователи должны или не должны делать; ищите слова «должен», «не должен», «только». Отделяйте их от ограничений проекта (бюджет, сроки) и ограничений дизайна. Матрица ролей и прав (роли × операции) компактно фиксирует ограничения, связанные с ролями.
3. Активаторы действий — «если такое-то условие или событие, то выполнить такое-то действие». Сложные сочетания условий выносите в таблицу или дерево решений.
4. Логические выводы — тоже «если… то…», но результат — новый факт, а не действие: «если оплата не поступила в течение 30 дней, счёт считается просроченным».
5. Вычисления — формулы или алгоритмы, которые порождают новую информацию. Ступенчатые расчёты оформляйте таблицей и следите, чтобы диапазоны не пересекались (если диапазоны 1–5 и 5–10, куда отнести 5?).

Рядом с ними стоят термины — ключевые бизнес-слова, словосочетания и сокращения; их лучше всего вести в глоссарии или словаре данных.

Атомарные правила#

Не упаковывайте несколько правил в одно предложение. Вигерс и Битти приводят рекомендацию фон Халле (von Halle): никаких ИЛИ в левой части правила «если… то…» и никаких И в правой. Атомарные правила меняются независимо друг от друга. Давайте им иерархические идентификаторы, например Booking.Cancel.FreeWindow, — это заодно упрощает трассировку.

Каталог правил#

Ведите как минимум такие столбцы: ID, текст правила, тип, статическое или динамическое, источник. Деление на статические и динамические правила важно для разработчиков: правила, которые, скорее всего, изменятся, должны жить в конфигурации или данных, а не в коде. В книге рассказана история системы управления воздушным движением, где интервалы эшелонирования ошибочно сочли статическими и зашили в код, что привело к дорогой переделке. Ведите каталог на уровне предприятия, во владении бизнеса, а не в документах одного проекта, иначе каждая система реализует одно и то же правило по-своему.

Где искать правила#

Опытные сотрудники, унаследованные системы (восстановите по ним требования или разберите код), модели процессов (ищите правило на каждом шаге), документы (старые спецификации, нормативные акты, договоры), данные (состояния объектов и то, что запускает переходы между ними) и подразделения, отвечающие за соблюдение нормативных требований (комплаенс). Вопрос «Какие у вас бизнес-правила?» не работает. Задавайте прицельные вопросы: от чего меняется этот статус? Как рассчитывается это значение? Чего требуют регуляторы? Что пользователь может сделать дальше?

Ссылайтесь, а не копируйте#

Свяжите требование с его правилом через атрибут «источник» в инструменте управления требованиями, через матрицу трассировки или гиперссылки между идентификаторами (они ломаются, когда документы перемещают). Спецификация указывает на эталонную копию в каталоге, поэтому при изменении правила вы найдёте все требования, которые от него зависят. Когда одно правило порождает несколько похожих требований, оформите их таблицей с суффиксами в ID.