а одно бизнес-требование может покрывать сразу несколько бизнес-целей?

свое собственное сообщение не могу редактировать...
поэтому уточню в этом:
Или если такая ситуация возникает, то надо дробить бизнес-требование либо укрупнять цель (сливать две)?

свое собственное сообщение не могу редактировать...
поэтому уточню в этом:
Или если такая ситуация возникает, то надо дробить бизнес-требование либо укрупнять цель (сливать две)?

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

свое собственное сообщение не могу редактировать...
поэтому уточню в этом:
Или если такая ситуация возникает, то надо дробить бизнес-требование либо укрупнять цель (сливать две)?

Не совсем понятно как укрупнять цель. Например есть цель увеличить безопасность в компании и сделать операции в компании более прозрачными (кто за что отвечает и что делает). Для достижения обоих целей, может быть сформулировано одно БТ, например аутентификация пользователя (как в примере выше). А при укрупнении, цель превращается В Сделать компанию безопаснее и прозрачнее. Теряется весь смысл выделения целей. Цель должны быть понятной и осязаемой, а не абстрактным выражением "Хочу что-бы все было хорошо".

а одно бизнес-требование может покрывать сразу несколько бизнес-целей?

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

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

> Например есть цель увеличить безопасность в компании и сделать операции в компании более прозрачными
Во-первых это не цель, т.к. нет критериев проверки. Т.е. это некая муть, которую очень любят писать в документах, дабы не нести ответственности за плохо сделанную работу.

Во вторых, как вы это и указали, это две мути. Проверку делаем по союзу "и".

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


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

Подскажите ПО, в котором можно построить диаграмму бизнес-вариантов использования (кроме Rational Rose, VP, EA). Пробовал вот в StarUML найти такую функцию, но, к сожалению, нет её.

А чем просто функционал рисования  ДВИ не подходит?

Из FAQ
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и  внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.

Подскажите ПО, в котором можно построить диаграмму бизнес-вариантов использования (кроме Rational Rose, VP, EA).

Cейчас в линейке Rational можно использовать 3 продкута для ДВИ, у каждого из которых есть еще свои дополнительные преимущества:
Requirements Composer - кроме ДВИ есть возможность рисовать бизнес-процессы
Software Architect - ну здесь основные преимущества скорее уже не в области анализа, а в реализации
System Architect - (бывший Тelelogic) - нотации можно модифицировать под себя - можете сделать нотацию для ДБВИ в дополнении к ДВИ
конечно все 3 продукта расчитаны на совметное использование как минимум в команде с выходом на масштаб организации.
проще, наверное, начать с Requirements Composer
все можно скачать в полнофункциональном триале на сайте IBM

Подскажите ПО, в котором можно построить диаграмму бизнес-вариантов использования (кроме Rational Rose, VP, EA).

Любой иструмент, позволяющий строить диагаммы ВИ + имеющий возможность управлять дизайном графических примитивов.
Любой графический инструмент достаточного класса, в котором можно сделать эти графические примитивы

Это если выше названных недостаточно почему-то.

Можно задать вопрос? Если Вы обращаетесь с таким запросом, то, вероятно, Вам это нужно, можно поинтересоваться какова причина?

Любой иструмент, позволяющий строить диагаммы ВИ + имеющий возможность управлять дизайном графических примитивов.
Любой графический инструмент достаточного класса, в котором можно сделать эти графические примитивы
Это если выше названных недостаточно почему-то.
Можно задать вопрос? Если Вы обращаетесь с таким запросом, то, вероятно, Вам это нужно, можно поинтересоваться какова причина?

Необходимо бесплатное средство для создания диаграммы БВИ. В StarUML такой возможности к сожалению нет. В Визио если нарисовать панель инструментов - вариант, но не особо приемлемый...

А чем просто функционал рисования  ДВИ не подходит?

Из FAQ
На Бизнес Диаграмме ВИ (БДВИ) отображается, как взаимодействуют внешние пользователи с вашей организацией для достижения бизнес целей. На ней обычно показывают внешних по отношению к вашей организации актеров, например, клиентов и  внешние организации. Старайтесь на этом этапе избегать связей <include> и <extend>. Данная диаграмма используется на этапе Бизнес Моделирования. Очень важно на этом этапе показать диаграмму Бизнес Объектов, которая отображает основные бизнес-сущности (и их свойства) и взаимосвязи между ними.

Это всё я уже читал, и не раз. Мне нужна такая нотация ДБВИ, как в Розе. Но необходимо, чтоб она была реализована в бесплатном средстве.

БВИ - это всего лишь стереотип от собственно ВИ. Лично я в StarUML для БВИ просто определял стереотип. Да, графический примитив не менял (честно говоря не помню даже есть ли такая возможность именно в StarUML)

БВИ - это всего лишь стереотип от собственно ВИ. Лично я в StarUML для БВИ просто определял стереотип. Да, графический примитив не менял (честно говоря не помню даже есть ли такая возможность именно в StarUML)

Возможности изменения графического примитива в StarUML точно нет. А вот стереотип определить новый (что-то вроде <<business actor>>, <<business use case>>) можно. Спасибо за ответ.
В StarUML привлекает то, что это средство очень похоже (в плане использования и изображения диаграмм) на Rational Rose.

Необходимо бесплатное средство для создания диаграммы БВИ.

То что нужно бесплатное средство- тут я не сомневался. Почему нужно средство для построения именно БВИ - не понятно. Впрочем ниже(выше) ответ дан. Есть такое чудо <<стереотип>> - один из стандартных средств расширения семантики языка UML