Бизнес-правила и требования

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

На семинарах для выявления требований аналитик может поинтересоваться обоснованием требований и ограничений, выдвигаемых пользователями. Нередко выясняется, что они определяются бизнес-правилами. Иногда аналитику удается также выявить бизнес-правила, которые определяют прочие артефакты и модели требований (Gottes-diener, 2002). На рис. 9-2 показано несколько возможных источников правил (и в некоторых случаях — вариантов использования и функциональных требований). Кроме того, здесь перечислены некоторые вопросы, которые может задавать аналитик участникам семинара при обсуждении различных проблем и объектов. Следует задокументировать выявленные бизнес-правила, попросить компетентных людей подтвердить их правильность и предоставить недостающие данные.

Рис. 9-2. Выявление бизнес-правил с помощью разнообразных вопросов

Идентифицировав и задокументировав бизнес-правила, определите, какие из них необходимо реализовать в программном продукте. Некоторые правила определяют варианты использования и функциональные требования, которые их реализуют. Рассмотрим три правила:

· Правило № 1 (активатор операции). «Если срок хранения контейнера с химикатом истек, об этом необходимо уведомить лицо, у которого в данный момент находится контейнер»;

· Правило № 2 (вывод). «Считается, что срок хранения контейнеров с химикатами, разлагающимися на взрывоопасные составляющие, истекает через один год с даты изготовления»;

· Правило № 3 (факт). «Эфир может спонтанно образовывать взрывоопасную перекись».

Эти правила определяют вариант использования, известный, как «Известить владельца химиката об истечении срока хранения». Одно из функциональных требований для данного варианта использования таково: «Система должна по электронной почте уведомить об владельца контейнера с химикатом об истечении срока хранения химиката».

Связи между функциональным требованием и породившими его бизнес-правилами определяют двумя способами:

· используя атрибут «Источник», указывают правила в качестве источников функционального требования (подробнее — в главе 18);

· определяют связи между функциональным требованием и соответствующими бизнес-правилами в матрице связей (подробнее — в главе 20).

Правила ссылочной целостности данных зачастую реализуют в виде триггеров и хранимых процедур БД. Такие правила описывают операции по обновлению, вставке и удалению данных, которые должна выполнять система в результате наличия отношений между сущностями данных (von Halle, 2002). Например, если клиент отменил заказ, система должна удалить все пункты, касающиеся неотправленных товаров, входящих в этот заказ.

Иногда бизнес-правила и соответствующие им функциональные требования весьма похожи. Тем не менее, правила — это внешние положения политики, которые требуется реализовать в ПО, следовательно, они управляют функциональностью системы. Каждый аналитик должен решить, какие из имеющихся правил относятся к его приложению, какие необходимо реализовать в нем и как именно.

Вспомним ограничивающее правило для системы контроля химикатов, согласно которому запрос пользователя о выделении опасных химикатов удовлетворяется, только если за последние 12 месяцев пользователь прослушал курс по работе с ними. Аналитику придется определить соответствующие этому правилу функциональные требования в зависимости от того, доступна ли БД записей об обучении в интерактивном режиме или нет. Если да, система может просто просмотреть запись об обучении пользователя и решить, принять или отклонить его запрос. Если записи в интерактивном режиме недоступны, система может временно сохранить запрос на химикат и по электронной почте обратиться к руководителю курса, который, в свою очередь, подтвердит или не подтвердит запрос. Правило одинаково для обеих ситуаций, однако функциональные требования к ПО — действия, предпринимаемые системой, если бизнес-правило встречается в ходе работы — различаются в зависимости от рабочей среды системы.

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

· исчезает необходимость модифицировать и бизнес-правило, и соответствующие функциональные требования при изменении правила;

· в спецификации требований к ПО отражаются последние изменения правил, поскольку спецификация требований к ПО просто ссылается на основную копию правила;

· упрощается повторное использование одного правила в нескольких разделах спецификации требований к ПО и в нескольких проектах безо всякого риска несогласованности, поскольку правила не похоронены в документации отдельного приложения.

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

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