Анализ бизнес-правил · Конспекты по бизнес-анализу

Что это#

Бизнес-правило — явное, проверяемое утверждение о том, как бизнес должен или не должен действовать или как он классифицирует и вычисляет те или иные вещи. Правила берутся из корпоративных политик, нормативных актов, отраслевых стандартов и согласованных методик расчёта. Вигерс и Битти подчёркивают, что правила существуют вне какой-либо программной системы: они действуют, даже если работа целиком выполняется вручную. И всё же правила — один из главных источников требований к ПО. Правило — не процесс (последовательность шагов) и не бизнес-требование (цель высокого уровня); оно формирует процессы: определяет термины, задаёт ограничения, запускает действия и управляет вычислениями.

Руководство BABOK® делит правила на два вида:

Определяющие правила (definitional rules) формируют знание: они определяют, что есть что или как это вычисляется. Их нельзя нарушить, можно лишь неправильно применить. Пример: «Ремонт является срочным, если клиент оплатил надбавку за срочность».
Поведенческие правила (behavioral rules) управляют тем, что делают люди. Их можно нарушить, и у каждого есть уровень обязательности — от строго обязательного до чисто рекомендательного.

Вигерс и Битти предлагают более подробную классификацию, удобную при написании требований:

Факты: истинные утверждения о бизнесе («у каждого контейнера есть уникальный штрихкод»).
Ограничения: что система или пользователи не могут делать; на них часто указывают слова «должен», «не должен» или «только».
Активаторы действий: «если выполнено это условие, то выполнить это действие».
Выводы: «если выполнено это условие, то верен этот новый факт» (например, счёт, не оплаченный в течение 30 дней, считается просроченным).
Вычисления: формулы или алгоритмы, преобразующие данные.
Термины ведут отдельно, часто в глоссарии или словаре данных.

Когда применять#

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

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

Как это делать#

Выявляйте правила из нескольких источников. Вигерс и Битти перечисляют давних сотрудников, существующие системы (обратное проектирование), модели процессов (ищите правило на каждом шаге), документы — политики, договоры, старые спецификации, — анализ данных (что заставляет объект менять состояние) и подразделения, отвечающие за соблюдение нормативных требований. Вопрос «Какие у вас бизнес-правила?» редко срабатывает; задавайте целевые вопросы: «Из-за чего меняется этот статус?», «Как вычисляется это значение?», «Чего требуют регуляторы?», «Что пользователю разрешено делать дальше?»
Отделяйте правила от требований и процессов. Формулируйте каждое правило декларативно, независимо от того, кто обеспечивает его соблюдение и на каком экране оно отображается.
Классифицируйте каждое правило (определяющее или поведенческое; факт, ограничение, активатор действия, вывод или вычисление).
Делайте правила атомарными. Разбивайте составные формулировки. Вигерс и Битти приводят совет фон Халле (von Halle): не используйте «или» в условной части правила «если — то» и не используйте «и» в части результата.
Сведите правила в каталог. Для каждого правила записывайте ID (иерархические ID вроде Booking.Lead-Time упрощают трассировку), формулировку, тип, признак «статичное или динамичное» и источник.
Используйте таблицы для сложной логики. Для расчётов с диапазонами используйте таблицу и следите, чтобы диапазоны не пересекались. Для множества сочетаний условий используйте таблицу или дерево решений.
Связывайте требования с правилами через ссылки — атрибут «источник», матрицу трассировки или гиперссылки. Не копируйте текст правила в требования: тогда при изменении правила вы сразу найдёте все затронутые требования.
Назначьте владельца. Вигерс и Битти рекомендуют, чтобы каталогом владел бизнес на уровне всего предприятия, а не отдельный проект или ИТ-отдел, — иначе одно и то же правило будет по-разному реализовано в разных системах.

Пример#

Часть каталога правил «Мастерской» (вымышленной сети из 12 веломастерских):

ID	Правило	Тип	Статичное или динамичное	Источник
Booking.Lead-Time	Онлайн-запись должна начинаться не раньше чем через два часа после её создания.	Ограничение (поведенческое правило)	Динамичное	Операционный менеджер
Customer.Plan-Holder	Клиент с действующим пакетом обслуживания является держателем пакета.	Факт / определение	Статичное	Условия пакетов обслуживания
Repair.Ready-Notice	Если ремонт отмечен как завершённый, клиент получает уведомление.	Активатор действия	Статичное	Политика обслуживания клиентов
Repair.Overdue	Если ремонт не завершён к обещанной дате, он считается просроченным.	Вывод (определяющее правило)	Статичное	Политика обслуживания клиентов
Price.Labour	Стоимость работ равна числу отработанных часов, умноженному на часовую ставку мастерской.	Вычисление	Динамичное	Прейскурант

Требование вроде «Система должна отправлять сообщение, когда ремонт отмечен как завершённый» ссылается на Repair.Ready-Notice, а не пересказывает правило. Поскольку минимальный срок до начала записи и ставка оплаты работ динамичны, аналитик фиксирует, что их нужно сделать настраиваемыми, а не зашивать в код. Вигерс и Битти описывают случай, когда правило по ошибке сочли статичным и жёстко прописали в коде, а позже это потребовало серьёзной переделки.

Частые ошибки#

Правила спрятаны в тексте требований или процессов → вынесите их в каталог и ссылайтесь на них.
Составные правила → разбейте их на атомарные правила с собственными ID.
Заинтересованным сторонам предлагают самим перечислить свои правила → задавайте целевые вопросы о состояниях, расчётах, правах доступа и нормативах.
Пересекающиеся диапазоны в таблицах расчёта (1–5, 5–10) → задайте границы так, чтобы каждое значение попадало ровно в один диапазон.
Динамичные правила зашиты в код → помечайте правила как статичные или динамичные и делайте динамичные настраиваемыми.
Отдельный каталог для каждого проекта → ведите один каталог, которым владеет бизнес.

Чек-лист#

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

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.9 «Анализ бизнес-правил».
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 9 (классификация правил, атомарные правила, каталог правил, источники правил, связь правил с требованиями).