Форум Сообщества Аналитиков
Дисциплины => Бизнес-анализ и Целеполагание => Тема начата: alex6565 от 27 Августа 2010, 13:30:31
-
Коллеги, мне очень важна информация, кто-нибудь имеет опыт работы с бизнес правилами (BR). Я имею в виду сбор, формулирование правил, формирование глоссария бизнес терминов, и т.д.
Рискую получить канделябром по голове за очевидные вещи, но на всякий случай все-таки уточню - речь идет не о бизнес требованиях, а именно от правилах.
Если таковой опыт имеется, поделитесь пожалуйста, какими методами вы пользуетесь при формулировании правил, какие вообще типы правил регистрируете, как в дальнейшем используете при работе с требованиями, какие тулзы используете для сбора, хранения и управления терминами и правилами.
Спасибо!
-
Александр,
В свое время Николай Войнов (http://www.uml2.ru/forum/index.php?action=profile;u=202) занимался активно изучением и применением БПр, вот его блог:
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
По методам работы с бизнес-правилами
Мне в основном попадались системы, где число бизнес-правил было невелико, поэтому я их текст размещал в так называемых "слотах" описаний способов применения, как это рекомендует Хлебников (http://www.training-labs.ru/rapporteurs/detail/231/). Также мне кажется полезным приём, который пропагандирует Вигерс в своих примерах (http://processimpact.com/process_assets/sample_requirements_documents.zip), когда перечень бизнес-правил идёт отдельным разделом документа, а из текстов способов применения идут ссылки на идентификаторы бизнес-правил.
По отнологии понятия "бизнес-правила"
Согласно тому же Вигерсу, бизнес-правила являются подмножеством нефункциональных требований уровня пользователя (см. главу 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
По методам работы с бизнес-правилами
Мне в основном попадались системы, где число бизнес-правил было невелико, поэтому я их текст размещал в так называемых "слотах" описаний способов применения, как это рекомендует Хлебников (http://www.training-labs.ru/rapporteurs/detail/231/). Также мне кажется полезным приём, который пропагандирует Вигерс в своих примерах (http://processimpact.com/process_assets/sample_requirements_documents.zip), когда перечень бизнес-правил идёт отдельным разделом документа, а из текстов способов применения идут ссылки на идентификаторы бизнес-правил.
О Хлебникове пока не слышал, обязательно ознакомлюсь. Что касается Вигерса, не хочу выглядеть его бездумным аппологетом :) , но этот его подход мне тоже близок.
По отнологии понятия "бизнес-правила"
Согласно тому же Вигерсу, бизнес-правила являются подмножеством нефункциональных требований уровня пользователя (см. главу 1 книги "Sofware Requirements", раздел Levels of Requirements). Ваших аргументов почему это не так не увидел.
Сложно спорить с таким корифеем, как Вигерс! :) В моем понимании, "бизнес-правила являются подмножеством нефункциональных требований уровня пользователя" озаначает лишь то, что эта информация приходит от пользователя и должна быть так или иначе учтена в разработке. Но, требованием, идущим непосредственно в разработку, или функциональным требованием, это не может являться. Аргументы я привел в предыдущем ответе.
По связи с техническими требованиями
Согласен с Денисом Ивановым, что бизнес-правила могут быть покрыты определёнными техническими функциями системы. Однако считаю важным отделять одно от другого и управлять как бизнес-, так и пользовательскими и техническими требованиями. Потому что, опять же, одно бизнес-правило может быть покрыто множеством пользовательских и технических решений.
Подписываюсь под каждым словом!
По формулировкам названий и шагов способов применения
На основе своего опыта смею утверждать, что более полезно, чтобы названия способов применения и шагов его сценариев отражали логическое условие, истинность которого соответствовала интересам агента/заинтересованного лица, чьи интересы защищаются в данном способе применения. Иначе говоря, формулировки шагов и названий способов применения должны быть ориентированы не на процесс (проверить; искать), а на позитивный результат (убедиться, что; найти).
Также, абсолютно согласен! Скажу более, в предыдущем проекте я настаивал, и это было отражено в моем докладе на семинаре, что каждый сценарий использования (Use Case) должен соотвествовать одной задаче пользователя (User Goal, оно же User Requirement), естественно возможна ситуация, когда одна, достаточно сложная, задача пользователя раскрыта несколькими сценариями использования. Т.е., сценарий использования должен описывать последовательность действия оператора системы (и отклики системы), для достижения конкретной задачи пользователя (печать месячного отчета, создание платежного документа и т.д.)
-
Я не соглашусь с тобой, что бизнес правила, даже описанные мной в примере, - это требования. Первая и главная разница: БП - это положение, знание о бизнесе. Правило, принятое в конкретной организации. Оно существует независимо от того, автоматизирован их бизнес, или они работают на счетах, а на входе сидит бабушка - вахтерша.
Мы просто смотрим с разных точек зрения. Моя точка зрения - точка зрения разработчика, ты - в данном случае скорее всего владелец бизнеса. Вот и вся разница:)
-
Я надеялся, что я выражаю точку зрения Бизнес\Системного Аналитика, который "переплавляет" бизнес - "хотелки" заказчика в конкретную постановку для разработчика
-
Не уверен, что прав, но.
Бизнес-требования - это функциональные требования достаточного высокого уровня.
Бизнес-правила - специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении. Бизнес-правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл., т.е. носят нефункциональный характер.
Очевидно, нельзя говорить, что бизнес-требования = бизнес-правила. Но не следует их и противопоставлять. Имхо они в ортогональных плоскостях.
Действительно задача аналитика перевести с языка бизнеса на язык системы.
По-моему в зависимости от контекста, бизневс-правила могут действовать как на уровне всей системы, так и на уровне отдельного модуля, части такой системы.
Если БП много и ими нужно эффективно управлять, действительно лучше определять их в одном месте, например в таблице, а во всех местах ссылаться на идентификатор бизнес-правила
-
Коллеги,
Чтобы не путать сокращение бизнес-процессов и бизнес-правил, давайте первое сокращать БП, а второе - БПр.
-
Коллеги,
Чтобы не путать сокращение бизнес-процессов и бизнес-правил, давайте первое сокращать БП, а второе - БПр.
Принято, будем использовать БПр или BR.
Не уверен, что прав, но.
Бизнес-требования - это функциональные требования достаточного высокого уровня.
Эдуард, опять не согласен! Что такое функциональные требования, я уже писал об этом выше, это тот набор требований, кторые выдаются непосредственно в разработку. Это постулат, декларация о необходимости реализации конкретного функционала. Каждое из таких требований должно быть:
- правильно, т.е. понятно для команды разработчиков сформулировано
- разработано
- протестировано
Подчеркиваю, каждое.
Что такое "функциональные требования достаточного высокого уровня". Это должно разрабатываться или нет?! Разве возможен подобный диалог между аналитиком (А) и девелопером (Д):
Д - это что такое?! Как это реализовывать?!!!
А - А, не парься, это высокоуровневые концептуальные функциональные требования!
Д - И чего?!!! Мне это разрабатывать или нет?!!!
А - А, хрен его знает!
:)
В моем понимании, высокоуровневыми, концептуальными могут Бизнес Требования - это то, что определяет цели и границы системы. То, что определяется в начале проекта, и очень желательно в последствии не менять, иначе проект никогда не закончится.
Бизнес-правила - специализированный вид логики, описывающей ограничения на образ действий, которые система или люди должны учитывать в своем поведении. Бизнес-правила определяются целым рядом факторов, включая директивы распорядительных органов, промышленные стандарты, деловую хватку и простой здравый смысл., т.е. носят нефункциональный характер.
прошу прощения, если цепляюсь к словам, но просто хочется ясного понимания. "Функциональные" требования носят "нефункциональный характер"?!
Мое убеждение, БПр существуют объективно независимо от того, есть ли по этому поводу требование, реализовано ли это требование, вообще возможно ли это требование реализовать.
Очевидно, нельзя говорить, что бизнес-требования = бизнес-правила. Но не следует их и противопоставлять. Имхо они в ортогональных плоскостях.
Мне больше близка картина, когда Бизнес Требования являются некоторой большой фигурой, которой можно накрыть множество точек отдельных БПр. Объективно, существует бесконечное количество БПр за пределами этой фигуры (за рамками проекта), но нам они не интересны.
Действительно задача аналитика перевести с языка бизнеса на язык системы.
По-моему в зависимости от контекста, бизневс-правила могут действовать как на уровне всей системы, так и на уровне отдельного модуля, части такой системы.
Если БП много и ими нужно эффективно управлять, действительно лучше определять их в одном месте, например в таблице, а во всех местах ссылаться на идентификатор бизнес-правила
С этим абсолютно согласен
Эдуард, спасибо! :)
-
прошу прощения, если цепляюсь к словам, но просто хочется ясного понимания. "Функциональные" требования носят "нефункциональный характер"?!
Интересно в каком месте определения (не моего взятого из словаря) сказано, что Бпр - это функциональное требование. Там говориться, что это ОГРАНИЧЕНИЕ, которое традиционно относят к нефункциональным требованиям, поскольку бизнес правило накладывает ОГРАНИЧЕНИЕ на какое-то функционирование.
Нельзя принять человека на работу, если его возраст скажем не достиг полных 18 лет.
и т.д.
-
Бизнес-требования - это функциональные требования достаточного высокого уровня.
Да, Эдуард, прошу прощения!
Вот эту фразу я прочитал как "Бизнес-правила - это функциональные требования достаточного высокого уровня"
Виноват! Стар стал, глаза уже не те! :)
-
Да, Эдуард, прошу прощения!
Александр! Вы прощены! :)
-
С этим абсолютно не согласен, поэтому и уточнил в своем вопросе. Есть достаточно большое количество работ, посвященных описанию разницы между Business Requirements и Business Rules.
Вы не понимаете разницу между требованиями, бизнес-требованиями и бизнес-правилами?
Эх, жаль я больше семинары не веду :)
-
Нда... только аналитики могут две страницы обсуждать такие мелкие детали :)
Привожу простой пример.
Занимаясь несколько лет автоматизацией различных аспектов банковской деятельности в роли аналитика (бизнес-аналитика, системного аналитика, аналитика требований, технического писателя и системного архитектора - детализирую во избежание еще серии вопросов :)), я часто сталкивалась с необходимостью извлечения бизнес-правил, и в моем случае их основными источниками были:
- законодательство, и даже в большей степени - различные указявки регулятора (которые статуса закона не имеют, но обязательны к исполнению банками, при этом сами банковские работники о них не упоминают, т.к. для их предметной области это нечто естественное и подразумевается по умолчанию);
- бизнесюки заказчика;
- внутренняя документация заказчика (содержит локальную специфику конкретной КО).
По первому вопросу использовалась правовая система и cbr.ru, по второму - интервью, по третьему - запрос и чтение соответствующих документов. Это к вопросу о КАК.
Честно говоря, придумать какие-то другие источники мне трудно - если кто-то знает, с большим удовольствием расширю свои профессиональные горизонты. :)
-
Вы не понимаете разницу между требованиями, бизнес-требованиями и бизнес-правилами?
Эх, жаль я больше семинары не веду :)
Очень серьезное обвинение! Снизойдете до более подробного объяснения?
Нда... только аналитики могут две страницы обсуждать такие мелкие детали :)
Вопрос был о практическом опыте, с конкретной детализацией вопроса. В процессе обсуждения были коментарии, напряму не относящиеся к предмету вопроса, но тем не менее, показавшие разницу в основополагающих взглядах. Мы обсудили эти разногласия.
Привожу простой пример.
Занимаясь несколько лет автоматизацией различных аспектов банковской деятельности в роли аналитика (бизнес-аналитика, системного аналитика, аналитика требований, технического писателя и системного архитектора - детализирую во избежание еще серии вопросов :)), я часто сталкивалась с необходимостью извлечения бизнес-правил, и в моем случае их основными источниками были:
- законодательство, и даже в большей степени - различные указявки регулятора (которые статуса закона не имеют, но обязательны к исполнению банками, при этом сами банковские работники о них не упоминают, т.к. для их предметной области это нечто естественное и подразумевается по умолчанию);
- бизнесюки заказчика;
- внутренняя документация заказчика (содержит локальную специфику конкретной КО).
По первому вопросу использовалась правовая система и cbr.ru, по второму - интервью, по третьему - запрос и чтение соответствующих документов. Это к вопросу о КАК.
Честно говоря, придумать какие-то другие источники мне трудно - если кто-то знает, с большим удовольствием расширю свои профессиональные горизонты. :)
Здорово, что у вас все-таки был практический опыт работы с БПр! Вероятно вам не составит труда поделиться информацией не только об источниках этих самых БПр (это, как бы, очевидно), но и о том, как вы с ними работали. Просто, на всякий случай, уточню: "КАК" не подразумевает запросить документ, открыть документ, прочитать документ и т.д.
"Как" означает:
- какие типы БПр вы собирали (классифицировали)?
- какие методы вы использовали для формулирования БПр (RuleSpeak, SBVR или что-то еще)?
- работали ли вы с фактами?
- формировали ли вы набор бизнес терминов
- какими программными средствами вы пользовались для регистрации и хранения БПр (RuleExpress, DROOLS, что-то другое...)
Мы все будем вам очень благодарны, если вы наконец-то внесете хотя бы небольшой элемент конкретики в нашу пустую болтовню!!!
Спасибо!
PS очень прошу не писать, например: "У Вигерса определены следующие типы БПр...". Не нужно, я знаю, что написано у Вигерса. Вопрос, какие типы создавали именно вы. И так далее по остальным вопросам.
-
Очень серьезное обвинение! Снизойдете до более подробного объяснения?
Возмездно - с удовольствием. Видите ли, это моя профессия, а время аналитика обходится работодателю недешево - с моей стороны будет неэтично тратить его на то, что вы мне предлагаете.
Спасибо за понимание. :)
-
to ida:
спасибо, ответ был предсказуем
Коллеги, огромное спасибо всем, кто принял конструктивное участие в этом обсуждении. Все, сказанное вами для меня очень важно, независимо от того, совпадает это с моими представлениями или нет.
Я думаю, данная тема себя исчерпала, я закрываю тему.
-
Все же отвечу по свой опыт в этой части, хотя тема уже закрыта
Бизнес правила пишу дополнениями к бизнес вариантам использования (аналогично как supplementary к use case только на уровне бизнес моделей и бизнес процессов), в основном это ограничения бизнес процесса или "факты" которые должны быть обязательно учтены в процессе
Правила особо не классифицирую, стараюсь упрощать и все требования бью по функциональным областям (в пакеты)
Возможно у меня проще, так как есть конкретные источники - договора с партнерами и регламенты работ
Как пример,
Бизнес процесс "Прием жалобы от клиента"
1. Клиент обращается в центр обслуживания с претензией (жалобой и прочим недовольством)
2. Сотрудник центра обслуживания клиентов просит заполнить Претензию
3. Клиент заполняет претензию...
Бизнес-правила:
1. Претензия должна быть рассмотрена в течении 3 дней. Результат рассмотрения должен быть сообщен клиенту по телефону или по электронной почте в течение 2 суток после рассмотрения
2. Сотрудник центра обязательно должен проверить паспортные данные клиента (претензия без предЪявления паспорта не принимается)
3. В претензии клиент обязательно должен указать ФИО, паспортные данные, описать претензию, указать действующий номер телефона или адрес электронной почты, поставить подпись
4. Сотрудник центра ставит свою подпись, дату принятия претензии, печать.
ну и тд
-
поскольку feedback продолжает идти, разблокировал тему.
Виталий спасибо!
Если я правильно понял, объем бизнес правил у вас не очень большой, они все очевидны, поэтому вполне приемлем вариант размещать их в качестве приложений к конкретным Use Cases, в качестве ограничения. Я думаю, что это вполне логично. Собственно, для ограничения функционала, описываемого в Use Cases, эти правила и собираются.
У нас несколько другая ситуация. Я очень рад тому, что сейчас вовлечен в проект, в котором просто безумное количество БПр, они обусловлены и законодательной базой, и правилами, принятыми в конктретной компании и сложившейся практикой. И размазывать их по документам с Use Cases в нашем случае - это не самый лучший вариант. Наиболее прниемлеммый вариант - это хранение в едином репозитории, там же, где хранятся и вещи, их поддерживающие, т.е. факты и термины.
Когда я открывал эту тему, я как раз был озадачен поиском подходящей софтины для сбора и хранения всего этого добра.
Как я уже писал в одном из ответов, сейчас сообществом людей, занимающихся вопросами бизнес правил, разработаны стандарты, в соотвествии с которыми приянято формулировать эти самые правила. Поэтому, для меня также актуальным был вопрос, есть ли у кого-то опыт следования этим правилам формулирования.
-
И размазывать их по документам с Use Cases в нашем случае - это не самый лучший вариант. Наиболее прниемлеммый вариант - это хранение в едином репозитории, там же, где хранятся и вещи, их поддерживающие, т.е. факты и термины.
Когда я открывал эту тему, я как раз был озадачен поиском подходящей софтины для сбора и хранения всего этого добра.
Как я уже писал в одном из ответов, сейчас сообществом людей, занимающихся вопросами бизнес правил, разработаны стандарты, в соотвествии с которыми приянято формулировать эти самые правила. Поэтому, для меня также актуальным был вопрос, есть ли у кого-то опыт следования этим правилам формулирования.
Александр, правил у нас действительно не очень много (так договоров 10 по 100 страниц :)). Я пользуюсь Sparx EA поэтому проблемы с отдельным размещением бизнес правил нет. BUC лежат в одном пакете, BR в другом (здесь их можно группировать как угодно). BR слинкованы с BUC, и при генерации документа с описанием процессов в раздел доп требований попадают все связанные BR
Почему правила пишу к BUC, а не отдельно? Потому что стараемся идти от целей и реализовывать процессы по мере их необходимости и развития (с детальной проработкой не сразу), к тому же не хватает времени на документирование требований
-
У нас несколько другая ситуация. Я очень рад тому, что сейчас вовлечен в проект, в котором просто безумное количество БПр, они обусловлены и законодательной базой, и правилами, принятыми в конктретной компании и сложившейся практикой.
Министерство обороны?
Наиболее прниемлеммый вариант - это хранение в едином репозитории, там же, где хранятся и вещи, их поддерживающие, т.е. факты и термины.
Когда я открывал эту тему, я как раз был озадачен поиском подходящей софтины для сбора и хранения всего этого добра.
Сравнение средств управления требованиями (http://www.uml2.ru/forum/index.php?topic=208.0)
Целый раздел есть на форуме на тему "хранения этого добра".
Удивительно, что всем они так или иначе подходят :)
Как я уже писал в одном из ответов, сейчас сообществом людей, занимающихся вопросами бизнес правил, разработаны стандарты, в соотвествии с которыми приянято формулировать эти самые правила. Поэтому, для меня также актуальным был вопрос, есть ли у кого-то опыт следования этим правилам формулирования.
Стандарты использования туалетной бумаги тоже требуют времени на разработку.
Это хороший способ как-то обосновать трудозатраты перед руководством. Но здесь вроде все свои - а разговоры о том же...
-
to Виталий:
Виталий, спасибо.
Я сейчас пытаюсь поставить процесс работы с БПр с помощью вот такой софтины: http://www.rulexpress.com/
Вещь специально заточенная под работу с БПр... но жутко сырая и глючная... и еще очень дорогая. Пока тестирую пробную бесплатную версию, дальше будем прининимать решение...
Министерство обороны?
Нет
Сравнение средств управления требованиями (http://www.uml2.ru/forum/index.php?topic=208.0)
Целый раздел есть на форуме на тему "хранения этого добра".
Удивительно, что всем они так или иначе подходят :)
средства управления требованиями можно использовать для работы с БПр, но меня интересовали софтины, специально разработанные для работы с БПр. Их отличие заключается в реализованной специфической логикой проверки корректности сформулированных бдизнес правил и многие другие специфические функции, присущие именно работе с БПр.
Стандарты использования туалетной бумаги тоже требуют времени на разработку.
Это хороший способ как-то обосновать трудозатраты перед руководством. Но здесь вроде все свои - а разговоры о том же...
Извините, не совсем понял о ком это?!!
На всякий случай уточню, речь шла о данном сообществе: http://www.brcommunity.com/ я уже давал ссылку в одном из своих ответов
-
Нетсредства управления требованиями можно использовать для работы с БПр, но меня интересовали софтины, специально разработанные для работы с БПр.
Бизнес-правила являются разновидностью требований к ПО.
Поэтому средства управления требованиями позволяют работать и с бизнес-правилами тоже.
Их отличие заключается в реализованной специфической логикой проверки корректности сформулированных бдизнес правил и многие другие специфические функции, присущие именно работе с БПр.
Можете перечислить эти специфические функции?
И как вы себе представляете автоматизированную логику проверки корректности сформулированных бизнес-правил?
-
to ida
ответы на все ваши вопросы уже даны выше.