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

Мы просто смотрим с разных точек зрения. Моя точка зрения - точка зрения разработчика, ты - в данном случае скорее всего владелец бизнеса. Вот и вся разница:)

Я надеялся, что я выражаю точку зрения Бизнес\Системного Аналитика, который "переплавляет" бизнес - "хотелки" заказчика в конкретную постановку для разработчика

Не уверен, что прав, но.

Бизнес-требования - это функциональные требования достаточного высокого уровня.

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

Очевидно, нельзя говорить, что бизнес-требования = бизнес-правила. Но не следует их и противопоставлять. Имхо они в ортогональных плоскостях.

Действительно задача аналитика перевести с языка бизнеса на язык системы.

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

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

Коллеги,

Чтобы не путать сокращение бизнес-процессов и бизнес-правил, давайте первое сокращать БП, а второе - БПр.

Коллеги,

Чтобы не путать сокращение бизнес-процессов и бизнес-правил, давайте первое сокращать БП, а второе - БПр.

Принято, будем использовать БПр или 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 в нашем случае - это не самый лучший вариант. Наиболее прниемлеммый вариант - это хранение в едином репозитории, там же, где хранятся и вещи, их поддерживающие, т.е. факты и термины.
Когда я открывал эту тему, я как раз был озадачен поиском подходящей софтины для сбора и хранения всего этого добра.
Как я уже писал в одном из ответов, сейчас сообществом людей, занимающихся вопросами бизнес правил, разработаны стандарты, в соотвествии с которыми приянято формулировать эти самые правила. Поэтому, для меня также актуальным был вопрос, есть ли у кого-то опыт следования этим правилам формулирования.