К сожалению, дело обстоит не совсем так.  Цитата из Коберна (стр 226 из текста из библиотеки сайта)
Коберном проделана выдающаяся работа по окультуриванию практики описания
алгоритмов, и его рекомендации по текстовому описанию юзкейсов действительно важный шаг в развитии IT, но к сожалению его взгляд на использование графических средств анализа и представления результатов является шагом назад, который серьезно оппонирует попыткам создания новых средств анализа и моделирования даже в качестве дополнительных к "текстовым инструментам" .

На самом деле мне не понятно, таки почему это "дело обстоит не совсем так" ... и почему ТОЛЬКО диаграммы юзкейсов не должны вызывать скепсис?? Особенно если учесть тот факт, что практика использования только диаграмм юзкейсов фактически приводит к функциональной декомпозиции но на юзкейсах ... и запросто при этом встречаем ВИ "Отправка уведомления о регистрации на мероприятие", который в лучшем случае будет "included". Никто не отрицает, что использование диаграммы юзкейсов в качестве "оглавления", предваряющего собственно текстовые спецификации вполне полезно, более того, я сам часто использовал диаграммы ВИ в "Modern SRS", но обязательно за ними следовали и сами юзкейсы. Кроме этого еще и графически показывал связь м/у диаграммами уровня "облака" и "user goal". Так что речь тут в большей степении о том, что имеет смысл использовать диаграммы СОВМЕСТНО с текстовыми спецификациями ... Но при этом, одни текстовые спеки дают больше value, чем одни диаграммы.
[/quote]

Как я понял Коберна, он никогда не отрицал (и даже наоборот) роли контекстной диаграммы (на которой показаны границы систем, действующие лица и основные цели). В частности эта диаграмма может быть сделана с использованием UML.

Пожалуйста, не могли бы Вы дать ссылку на страницы русскоязычного издания, которые иллюстрировали бы данную трактовку Коберном роли диаграммы Use cases? 
ИМХО практически везде, где Коберн описывает применение диаграмм UC он сначала предлагает не совсем удачные решения по графическому изображению UC, а потом сам же сетует на их несовершенство, например, в разборе примера на стр. 41-46 русскоязычного издания Коберн вырабатывает более-менее приемлемое изображение UC: "Я бы предпочел нестандартную диаrpaмму варианта использования (см. рис. 3.3), чтобы показать связь двух систем".
но тут же (на стр. 46) выносит ему приговор:
 "Эта диаrрамма более наrлядна, но ее труднее сопровождать. Диаrрамма должна помоrать вам и вашим читателям лучше понимать друr друrа."
1.Непоятно - в чем нарушение стандарта на рис. 3.3? По крайней мере сравнивая с текстом UML Superstructure 2.0 (который, правда, принят после опубликования книги) нарушений пока не вижу...
2. Глубокомысленный пассаж насчет трудности сопровождения также не подкреплен конкретными аргументами.

То, что есть мнение против слишком точного рисования диаграмм Use Case с одной стороны не отрицает их применение, а с другой стороны имеет под собой веские основания.
Давайте представим себе двух аналитиков: один ИТ специалист - системный аналитик, второй - заместитель генерального директора по финансам.
Первый знает UML и все его тонкости и может даже сделать документ, описывающий сценарии с использованием средства моделирования, тогда для него жизненно важна точнось диаграмм и модели (в противном случае документ не сгенерируется правильно).
Второй не знает UML и пишет документы в MS Word - для него рисование точной диаграммы Use Case выльется в дополнтельные хлопоты.

То, что для финансового директора привычно написание документов в Word совсем не означает, что он сядет писать  UC для требуемой ему системы прилежно сверяясь с рекомендациями Коберна. Вероятнее всего ИТ специалист приведет ряд интервью с замом по финансам, они выяснят, что нужно, и это будет зафиксировано в виде, удобном как для Заказчика, так и для разработчиков системы. Диаграммы рисовать (или описывать текстовые юзкейсы) будет тот из них, кто лучше умеет это делать. Рисование диаграмм (в процессе обсуждения) существенно облегчает процесс обсуждения, даже если диаграммы недостаточно строго следуют принятым стандартам UML.  Следует специально отметить, что в данном случае мы рассматриваем именно процесс анализа деятельности подлежащей автоматизации.

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

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

Когда они вместе будут читать документ, первый будет жаловаться, что второй рисует не по стандарту UML, а первый будет говорить, что он не понимает тонкостей UML (чем, например овальчик отличается от перечеркнутого овальчика) и не собирается понимать, так как для данного конкретного документа нотация изображения роли не играет.

Эх, побольше бы таких Заказчиков, обсуждение с которыми упирается в особенности применения стандартов UML и лучших практик описания юзкейсов! По моим наблюдениям на этом этапе, как правило идет обсуждение ПО СУТИ автоматизируемых процессов и главные трудности описания Заказчиком устройства деятельности предприятия в крупных формах связаны с противоречиями и "наворотами" в собственных представлениях Зазказчика о бизнес-логике предприятия, а не в столкновении этой бизнес-логики с теми или иными особенностями стандарта их описания, будь то стандарт диаграммы UML или текстового описания юзкейса. 

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

Извините, при всем уважении к Вашему стремлению быть правильно понятым, данные утверждения представляются нелостаточно аргументированными без подкрепления данного утверждения ссылками на текст Коберна (ведь речь идет именно о точке зрения Коберна, а не Вашей собственной).
Даже если принять данное представление об использовании диаграммы UC, в качестве истинной, такая трактовка её использования несколько отличается от зафиксированной стандартом UML superstructure, поскольку как раз границы системы не являются необходимыми для отображения: "If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle." (Use Case Notation, p. 579), т.е. "если (граница отбражается) то…"

На самом деле мне не понятно, таки почему это "дело обстоит не совсем так" ... и почему ТОЛЬКО диаграммы юзкейсов не должны вызывать скепсис?? Особенно если учесть тот факт, что практика использования только диаграмм юзкейсов фактически приводит к функциональной декомпозиции но на юзкейсах ... и запросто при этом встречаем ВИ "Отправка уведомления о регистрации на мероприятие", который в лучшем случае будет "included". Никто не отрицает, что использование диаграммы юзкейсов в качестве "оглавления", предваряющего собственно текстовые спецификации вполне полезно, более того, я сам часто использовал диаграммы ВИ в "Modern SRS", но обязательно за ними следовали и сами юзкейсы. Кроме этого еще и графически показывал связь м/у диаграммами уровня "облака" и "user goal". Так что речь тут в большей степени о том, что имеет смысл использовать диаграммы СОВМЕСТНО с текстовыми спецификациями ... Но при этом, одни текстовые спеки дают больше value, чем одни диаграммы.

1. Мне в принципе близок Ваш подход к использованию диаграмм юзкейсов. Когда я писал о том что "дело обстоит не  совсем так", это относилось к Вашему утверждению о том, что никто в принципе не возражает против использования диаграмм (в частности, юзкейсов, как я понимаю) в дополнение к текстовому описанию. Я указал, что Коберн в этом отношении занимает фактически более жесткую позицию по сравнению с Вашей. Цитаты , которые  я привел, свидетельствуют о гораздо жестком оппонировании (фактически, возражении)  использованию диаграмм, даже в дополнение к текстовому описанию. Нет практически ни  одного примера использования диаграмм UML в его книге, в которых рассмотрение способов их использования не сопровождались бы впоследствии уничижительными замечаниями в адрес этих диаграмм, напрочь дезавуирующих любые утверждения об их возможной полезности, которые он делает перед этим. Цитаты в подтверждение я и привел в предыдущем посте.

2. Наряду с вопросами применения диаграмм в конкретных проектах, не менее интересным представляется применение диаграмм для формирования паттернов бизнес-уровня, которые ухватывали бы типовые модели ведения бизнеса. Бизнес-анализ в сфере менеджмента, управления предприятиями давно уже использует различные модели, также использующие диаграммные представления. Такие схемные представления широко распространены в так называемых развитых странах и нашли свое отражение и в модульных структурах  ERP-систем.  Да и в отечественном бизнесе термин "типовая схема управления"  уже стала привычной . Несмотря на то, что управленцы давно понимают друг друга с полуслова и могут оперировать такими крупноблочными схемными представлениями для организации бизнеса, описание этих схем лишено той четкости, которая обычно требуется для задач автоматизации деятельности. В то же время при внедрении автоматизированных систем (особенно типовых решений)  неизбежна встает задача выделения типовых схемы управления из всего многообразия подходов к управлению, культивируемых конкретным Заказчиком. И эта работа занимает существенную часть времени затрачиваемого на проектирование/внедрение системы.
При этом представляется важным решение двух задач:
1. Каким образом можно упорядочить системные представления о различных видах бизнеса с целью их дальнейшего применения в других проектах(ускорить, облегчить этап бизнес-анализа)?
2. Возможно ли обеспечить взаимопонимание IT и бизнес структур за счет использования близких (схемных?) представлений (ускорить, облегчить передачу информации о бизнесе разработчикам)?

Можно ли считать эффективным для целей п. 2 использование традиционных текстовых представлений?

Работа управленца - конструктора управленческих схем давно уже напоминает работу конструктора-машиностроителя и схемы (чертежи) давно уже стали неотъемлемой частью проектной документации.  И схема управления давно уже не может быть заменена текстовым перечнем (содержанием) включающих её элементом. Для достаточно больших схем именно затраты на выстраивание структуры связей, а не разработку (приобретение) отдельных компонентов вносит основной вклад в valuе этих систем.

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

Вопрос: могут ли быть
1. разработаны типовые схемные представления о бизнесе (в том числе и зарубежном), учитывающие отечественную специфику и, возможно, опыт,
2. конкурентоспособные на мировом уровне и
3. сопрягаемые как с существующими моделями как в сфере менеджмента, так и IT, в частности, с использованием UML?

Как обеспечить сопряжение схемно мыслящего бизнеса и текстово мыслящего IT сообщества?

Я не совсем понимаю тему спора.
Книга Коберна направлена на использование современных методов описания функциональных требований к системам. Хотя такое переводное название на самом деле не отражает истинное название книги, которая достаточно четко ставить область ее использования и изучение: Написание эффективных вариантов использования.

Т.е. книга посвящена НАПИСАНИЮ, но не РИСОВАНИЮ вариантов использования. И отражает личный опыт и убеждения автора.

Использовать или не использовать диаграммы. Когда их использовать и в каком виде? Я думаю, по мере развития графических средств и инструментов моделирования, создания языков формального описания и т.п. будет происходить (и происходит) взаимопроникновение идеологии и понимания как в сферу бизнеса, так и в сферу ИТ.

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

Если вспомнить начало топика, то надо признать, что мы отклонились от темы.
Разговор был о том, что структуру самого ВИ можно нарисовать в виде Class Diagram.

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

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

Обсуждение ушло в другом направлении, и у меня, по ходу его развития, возникли "крамольные" вопросы:
а может просто диаграмма ВИ сама по себе слабый инструмент?
а если её доработать, то и получится дать любителям визуальных представлений приличный инструмент для создания ЮзКейсов?

а может просто диаграмма ВИ сама по себе слабый инструмент?

давай рассуждать логически и исторически.

Сами варианты использования придуманы и введены ц употребление Якобсоном. Сначала они назывались usage case, потом превратились в брендовое название use case. Как я понимаю, исходно, это были действительно текстовые сценарии. Возможно содержащие простое описание и позволяющие структурное связывание. После объединения усилий по разработке единого стандарта объектной парадигмы, варианты использования были включены в нотацию UML. Овалы предназначены, на мой взгляд, для задания контекста и скрытия деталей на определенном уровне абстракции - классическая инкапсуляция. Детали варианта использования в зависимости от уровня представления раскрываются в текстовом описании или использовании других диаграмм: диграмм деятельности, последовательности и даже состояний.

Рамбо говорит, используйет текстовое описание там где это действительно проще и понятнее, а диаграмму деятельности лучше использовать, если ВИ имеет сложную структуру. Для отображения временной зависимости и отображения деталей используется диаграмма последовательности, которая в при проектировании классов еще добавляет и операции классов.

Диаграмма вариантов использования начинается с простого перечисления действующих лиц (лиц которые используют системы) и вариантов использования этой системы ими. Этот уровень хорош для последующих дискуссий и правильного понимания функциональности системы с разных точек зрения. Т.е. каждое действующее лицо символизирует определенную точку зрения на функциональность системы.

На уровне бизнеса или на уровне системы все это отображджает внешний взгляд на систему как черного ящика - ее устройство скрыто, внимание сосредоточено на том, что должна делать система для удоволетворения потребностей ДЛ и какие внешние связи-интерфейсы должны быть установлены.

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

Использование графических средств на ранних этапах позволяет моделировать разные слои решения в едином подходе, сокращая этап разработки и обеспечивае повторное использование ранее созданных элементов.

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

Я вот сейчас изучаю Telelogic System Architect. Он пока поддерживает версию 1.3 или 1.4 UML, но например там реализован такой инструментарий: делаешь диаграмму ВИ, входишь в редактирование самого ВИ, а там целый шаблон в виде формы ввода: шаги, предусловия, постусловия и т.п. Хорошо это или нет, удобнее такой подход или нет (по сравнению например с написанием в виде докмента док и подключения как гиперссылки) Возможно тут есть преимущество сопровождения, формирования отчета, использования трассировочного инструмента DOORS. Вероятно, из такой структуру при желании можно сгенерировать диаграмму дейятельности (правда я еще не пробывал только начал изучение)

Вряд ли имеет смысл говорить о слабости инструментов или проработке стандарта. Вероятно будет все это иметь смысл, когда будет придуман и реализован исполняемый UML во всех его проявлениях