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

Спасибо!
 

Александр,

В свое время Николай Войнов занимался активно изучением и применением БПр, вот его блог:
http://nvoynov.blogspot.com/2008/04/blog-post_6495.html

З.Ы. Я отдельно БПр не веду.

Александр, спасибо за ответ!

Бизнес-правила это одна из разновидностей требований.
Следовательно их вполне может собирать тот же, кто собирает требования

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

Кроме того в иностранной литературе встречаются книги, посвященные этому вопросу, т.е. разработка на основе бизнес правил. На pdfchm.com такие книги встречались

Существуют средства моделирования и описания бизнес правил, например: http://www.visual-rules.com/business-rules-platform-management.html?utm_source=GoogleAd&utm_medium=PPC&utm_content=G_Exo_BRMS&utm_campaign=G_Exo&gclid=CM3Ep8m92aMCFQ8FZgodWVf58Q

Enterprise Architect также имеет инструменты построения бизнес правил: http://www.sparxsystems.com/enterprise_architect_user_guide/modeling_languages/compose_business_rules.html
а здесь демонстрация http://www.sparxsystems.com/resources/demos/75_overview/index.html

Бизнес-правила это одна из разновидностей требований.

С этим абсолютно не согласен, поэтому и уточнил в своем вопросе. Есть достаточно большое количество работ, посвященных описанию разницы между Business Requirements и Business Rules. Вот например, самый простой и забавный образчик: http://www.brcommunity.com/b290.php

Следовательно их вполне может собирать тот же, кто собирает требования

С этим сложно спорить, тем более, что это уже, наверное, решается в каждой конкретной компании - кто будет заниматься сбором и управлением правилами. Очевидно, что Бизнес-Аналитик - это лучшая кандидатура на эту работу.
Но, это не является предметом моего интереса. Мне интересно, именно, КАК а не КТО
Спасибо!

Александр по поводу бизнес-правил есть информация ...

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

Мне интересно, именно, КАК а не КТО

Александр, Вы не противоречите сами себе? Тема носит название Кто занимается сбором Бизнес Правил (Business Rules).

Александр, Вы не противоречите сами себе? Тема носит название Кто занимается сбором Бизнес Правил (Business Rules).

Пардон!!!
Имелось в виду: "Кто из присутствующих на форуме... сейчас (или ранее) занимается (занимался) сбором... У кого есть опыт в этой области?"
Это не означает, Кто должен. Это означает: Кто сейчас этим реально занимается
Прошу прощения за неточную формулировку вопроса

Александр, я лично никогда не позиционировал свою деятельность по формированию требований, как поиск, формулировка бизнес правил. Однако, после Вашего поста, прочтения данной Вами ссылки, ловлю себя на мысли, что оказывается большая часть моих требований как заказчика решения формулируются именно как бизнес правила. Правда не делаю это осознаваемо, систематически и структурировано. Хотя надо бы наверное. Ведь по сути они пронизывают все аспекты предметной области.

большая часть моих требований как заказчика решения формулируются именно как бизнес правила.

согласен с каждым словом.
Ведь, смотрите, простейший пример: система пропуска на территорию компании, мы все каждый день сталкиваемся с необходимостью прикладывать карточку к ридеру.
Простейший Use Case, описывающий операцию авторизации сотрудника, можно описать двумя-тремя фразами:
 1 сотрудник прикладывает карточку к ридеру;
 2 система считывает информацию с карточки;
 3 система проверяет валидность учетной записи;
 4 в случае валидности система открывает дверь (вертушку)...
Пункты 2-4 прямые кандидаты на формулировку функциональных требований.
Но!
Но, существует и другая информация, например:
 1 сотрудники данной категории не имеют право работать в нерабочие дни
 2 срок действия электронной карты ограничивается 1 годом
 и т.д.
Очевидно, что игнорировать данную информацию мы не можем - это обязательно должно быть учтено в реализации.
Включать это в Use Case? Мне кажется это не очень корректно. Включать это в требования, но эти правила могут относиться к общекорпоративным правилам и могут одновременно распространяться и на другие системы авторизации, например учетная запись пользователя рабочей станции тоже должна подчиняться данным правилам.
Очевидно, что все подобные вещи должны быть вынесены в отдельные категории знаний, но иметь четкое указание, где они используются.
Я сейчас не затрагиваю вопросов описания фактов, которые просто содержат нужную информацию об автоматизируемом бизнесе, но напрямую в требованиях могут быть не задействованы. И я не говорю о такой важной вещи, как фиксации "терминов", т.е. определении основных бизнес понятий для того, что бы с заказчиком разговаривать на одном "бизнес" языке.
Тема, на самом деле очень интересная и, как мне кажется, немного недооцененная. Очень хочу ошибиться в этом суждении!

1 сотрудники данной категории не имеют право работать в нерабочие дни
 2 срок действия электронной карты ограничивается 1 годом
 и т.д.

Типичные функциональные требования низкого уровня.
Примерные названия use cases:
1 проверить права доступа
2 проверить срок действия электронной карты

@alex6565

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

По отнологии понятия "бизнес-правила"
Согласно тому же Вигерсу, бизнес-правила являются подмножеством нефункциональных требований уровня пользователя (см. главу 1 книги "Sofware Requirements", раздел Levels of Requirements). Ваших аргументов почему это не так не увидел.

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

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

Типичные функциональные требования низкого уровня.
Примерные названия use cases:
1 проверить права доступа
2 проверить срок действия электронной карты

Денис, спасибо, что откликнулся!
Я не соглашусь с тобой, что бизнес правила, даже описанные мной в примере, - это требования.  Первая и главная разница: БП - это положение, знание о бизнесе. Правило, принятое в конкретной организации. Оно существует независимо от того, автоматизирован их бизнес, или они работают на счетах, а на входе сидит бабушка - вахтерша.
Требование - это: "Функциональность, необходимая пользователю для решения проблемы или достижения цели" (IEEE, выдержка взята из твоей книги "Моделирование на UML, теория, практика, видеокурс", которую я сейчас с огоромным интересом "грызу"). Т.е. требование (функциональное) - это описание функционала в автоматизированной системе.
Эти вещи связаны? Безусловно! Это одно и то же? Нет!
Очень наглядно разница между БП и требованием показана в статье: http://www.brcommunity.com/b290.php (я уже давал на нее ссылочку ранее).
Там приведен набор вопросов, позволяющих понять, что БП и требования - это не одно и то же:

Here are some questions for the readers:
Do the rules exist even when you can't implement the requirement?  Absolutely.
Will implementing the requirement mean all the rules will be complied with?  Not for sure.
Is this the ONLY feasible requirement to enable compliance with this set of rules?  No.

Более того, формулирование БП подчиняется особым законам, описанным в Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/PDF
Есть еще аргументы, касающиеся работы с фактами и терминами, но, мне кажется, пост и так уже перегружен.
Денис, еще раз спасибо за отклик. Хочу отдельно сказать спасибо за очень полезную книгу!  Книга действительно - Must Have!

Денис, привествую! Спасибо за за участие в теме!
Постараюсь ответить по порядку:

@alex6565

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

О Хлебникове пока не слышал, обязательно ознакомлюсь. Что касается Вигерса, не хочу выглядеть его бездумным аппологетом  , но этот его подход мне тоже близок.

По отнологии понятия "бизнес-правила"
Согласно тому же Вигерсу, бизнес-правила являются подмножеством нефункциональных требований уровня пользователя (см. главу 1 книги "Sofware Requirements", раздел Levels of Requirements). Ваших аргументов почему это не так не увидел.

Сложно спорить с таким корифеем, как Вигерс! В моем понимании, "бизнес-правила являются подмножеством нефункциональных требований уровня пользователя" озаначает лишь то, что эта информация приходит от пользователя и должна быть так или иначе учтена в разработке. Но, требованием, идущим непосредственно в разработку, или функциональным требованием, это не может являться. Аргументы я привел в предыдущем ответе.

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

Подписываюсь под каждым словом!

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

Также, абсолютно согласен! Скажу более, в предыдущем проекте я настаивал, и это было отражено в моем докладе на семинаре, что каждый сценарий использования (Use Case) должен соотвествовать одной задаче пользователя (User Goal, оно же User Requirement), естественно возможна ситуация, когда одна, достаточно сложная, задача пользователя раскрыта несколькими сценариями использования. Т.е., сценарий использования должен описывать последовательность действия оператора системы (и отклики системы), для достижения конкретной задачи пользователя (печать месячного отчета, создание платежного документа и т.д.)