Ваши зарисовки идеально укладываются в моей голове на мои мысли  И вроде как мои рассуждения полностью это подтверждают.

Может быть.
Но давайте развивать идею. ВИ - это набор сценариев: как минимум базовый успешный и масса разных альтернативных. Ясно, что альтернативы в принципе можно описать экстендами. А то что включается инклюдами - это по сути подпотоки базового потока, хотя они могут возникнуть и в алтернативных потоках. Если продолжить мысль, то наша ДВИ превратится в некоего монстра типа mind map. Но последнее - это мой слепок мозговой деятельности.

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

Очень хорошо. Это помогло Вам и может помочь другим, тогда нужно предложить методику и возможно ее обсудить и доказать ее эффективность, но может это сделать в другой ветке? Как считатете?

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

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

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

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

Пропустить первый этап и приступить ко второму - это не есть хорошо

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

Опять же, слишком общая ДВИ жизнь не облегчит, а может привести к потере части функционала Системы.

Если отталкиваться от ДВИ как от центра и забыть о других средствах выражения - согласен.

Но это все, как говорится, ИМХО! 

Из разных имхо рождается истина

извиняюсь, пишу с телефона, цитировать неудобно.
1. монстр с точки зрения обилия элементов на схеме? ну и замечательно! простые схемы хороши в обучении для быстрого понимания, в работе же монстры предпочтительнее, так как позволяют глубже погрузиться в систему. подразумевается, что профессионалов не испугает количество элементов на схеме :-)
2. методики писать мне еще рановато, опыту маловато. да и как показывает практика вся теория хороша только в теории, на деле же все проекты развиваются своим уникальным путем: то форс-мажоры, то сроки, то отдельные члены команды... но если нужно порассуждать, покритиковать - это я всегда "за" :-)
3.на самом первом этапе идет активное обсуждение системы между участниками команды разработчика и заказчика, сама система претерпевает множество трансформаций, пока не принимает свой более-менее конечный облик. все это удобнее делать на схемах, чем на тексте: они компактны, наглядны, их проще менять. когда схемы устаканятся и все разбредутся выполнять свои задачи можно и описанием заняться, которое потом включается в документацию эскизного или технического проекта.

Посмотрите, пожалуйста, что у меня получилось.
Вариант использования (ВИ): Просмотреть информацию о вариантах предоставления услуг интернет-магазина.
ID: 1
Краткое описание: Система выдает Клиенту информацию о вариантах оплаты и доставки товаров.
Основное действующее лицо: Клиент
Второстепенные действующие лица: Нет
Предусловия: Нет
Основной поток:
1. ВИ начинается, когда Клиент запрашивает информацию о вариантах предоставления услуг.
2. Если Клиент запрашивает информацию о вариантах оплаты товара
2.1. Система выводит на экран информацию о вариантах оплаты товара, приобретаемого в интернет-магазине.
3. Если Клиент запрашивает информацию о вариантах доставки товара
3.1. Система выводит на экран информацию о вариантах доставки товара, приобретаемого в интернет-магазине.
Постусловия: Система вывела на экран запрошенную Клиентом информацию.
Альтернативные потоки: Нет

ВИ: Найти товар
ID: 2
Краткое описание: Система выполняет поиск в каталоге товаров на основании заданных Клиентом критериев.
Основное действующее лицо: Клиент
Второстепенные действующие лица: Нет
Предусловия: Нет
Основной поток:
1. ВИ начинается, когда Клиент переходит в каталог товаров.
2. Система запрашивает у клиента критерии поиска товаров.
3. Клиент вводит запрашиваемые критерии.
4. Система выполняет поиск товаров, соответствующих заданным критериям.
5. Для каждого найденного товара
5.1. система выводит на экран изображение товара.
5.2. система выводит на экран наименование товара.
5.3. система выводит на экран цену товара.
6. Если Клиент запрашивает полную информацию о выбранном товаре
6.1. Система выводит на экран все характеристики соответствующего товара
7. Если Клиент выбирает опцию «Добавить товар в тележку» для выбранного товара
7.1. Система добавляет выбранный товар в тележку.
7.2. Система пересчитывает стоимость содержимого тележки.
Постусловия:
1. Система нашла товары по заданным критериям и вывела результаты поиска на экран.
Альтернативные потоки:
1. Системе не удалось найти товары.

Альтернативный поток: Найти товар: Системе не удалось найти товары.
ID: 2.1
Краткое описание: Система сообщает Клиенту, что товары с заданными характеристиками не найдены.
Основное действующее лицо: Клиент
Второстепенные действующие лица: Нет
Предусловия: Система не нашла товары с заданными характеристиками.
Альтернативный поток:
1. Альтернативный поток начинается после шага 4 основного потока
2. Система сообщает пользователю, что товары с заданными характеристиками найти не удалось
Постусловия:
1. Система вывела на экран сообщение о том, что товары не найдены

ВИ: Оформить заказ
ID: 3
Краткое описание: Оформление заказа на покупку товара в интернет-магазине.
Основное действующее лицо: Клиент.
Второстепенные действующие лица: Система автоматизации торговли.
Предусловия:
1. В тележке Клиента присутствуют товары.
Основной поток:
1. ВИ начинается, когда Клиент выбирает опцию «Оформить заказ».
2. Система отображает форму оформления заказа.
3. Система отображает на экране содержимое виртуальной «тележки» Клиента.
4. Система отображает на экране стоимость заказа.
5. Если Клиент выбирает опцию «Удалить товар»
5.1. Система удаляет отмеченные товары из виртуальной «тележки».
5.2. Система пересчитывает стоимость содержимого виртуальной «тележки».
6. Система предлагает Клиенту выбрать вариант оплаты товара.
7. Клиент выбирает вариант оплаты товара.
8. Система предлагает Клиенту выбрать вариант доставки товара.
9. Клиент выбирает вариант доставки товара.
10. Пока введенные Клиентам данные имеют некорректный формат.
10.1. Система запрашивает контактный телефон и электронный адрес Клиента.
10.2. Клиент вводит запрашиваемую информацию.
10.3. Система проверяет корректность введенных Клиентом данных.
11. Система запрашивает у Клиента подтверждение оформления заказа.
12. Клиент подтверждает оформление заказа.
13. Система отправляет заказ в Систему автоматизации торговли.
Постусловия:
1. Система автоматизации торговли получила заказ.
Альтернативные потоки:
1. Некорректный формат введенных Клиентом данных.
2. Клиент отказался подтверждать оформление заказа.

Альтернативный поток: Оформление заказа: Некорректный формат введенных Клиентом данных.
ID: 3.1
Краткое описание: Система сообщает Клиенту, что он ввел некорректные данные.
Основное действующее лицо: Клиент
Второстепенные действующие лица: Нет
Предусловия: Клиент ввел некорректные данные
Альтернативный поток:
1. Альтернативный поток начинается после шага 10.3 основного потока
2. Система сообщает пользователю, что введенные данные имеют некорректный формат.
Постусловия:
1. Система вывела на экран сообщение о том, что введенные данные имеют некорректный формат.

Альтернативный поток: Оформление заказа: Клиент отказался подтверждать оформление заказа.
ID: 3.2
Краткое описание: Клиент не подтвердил оформление заказа
Основное действующее лицо: Клиент
Второстепенные действующие лица: Нет
Предусловия: Клиент отказался подтверждать оформление заказа.
Альтернативный поток:
1. Альтернативный поток начинается после шага 11 основного потока
2. Система возвращается в форму оформления заказа
Постусловия:
1. Система перешла в форму оформления заказа.

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

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

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

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

Удачи!

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

Я понял, мне не удастся Вас переубедить быстро. Ну как и Вам меня. Так что если все-таки хочется, давайте откроем тему или возможно такая тема уже есть?

Клиент обращается в магазин, чтобы приобрести товар - вот главная цель использования магазина.

Эд, ты про магазин как коммерческое предприятие/организацию или про интернет-сайт?

Эд, ты про магазин как коммерческое предприятие/организацию или про интернет-сайт?

Ден и как про интернет-магазин тоже. Я понимаю, что использование интернет-магазина шире. Но основаня цель - все-таки приобретение товара. Другая - узнать что-то о товарах, услугах.

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

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

Я понял, мне не удастся Вас переубедить быстро

На каком слове акцент? 

Ну как и Вам меня

такой задачи не стояло

Так что если все-таки хочется, давайте откроем тему или возможно такая тема уже есть?

похожая тема есть: http://www.uml2.ru/forum/index.php?topic=5365.msg35217#msg35217
можно развить тему

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

Можно поступить следующим образом.
Описать несколько возможно лишних ВИ
Просмотр каталога товаров (чтобы определиться с выбором)
Найти товар по заданным критериям поиска
Обновить содержимое корзины
Можно кратко описать каждый, не используя полный стиль Актор делает .... Система делает ..., а просто список основных действия. Задача понять, если между этими ВИ что-то общее, можно ли это общее выделить в 1 включаемый ВИ. Включаемый должен включаться как минимум в 2 ВИ. Включение в 1 - это будет функциональная декомпозиция.

Вот пример из книги Use Case Modeling By Kurt Bittner, Ian Spence

Example
Outline for the use case Browse Products and Place Orders
Basic Flow
Browse Products
Select Products
Identify Payment Method
Identify Shipping Method
Confirm Purchase

Alternative Flows
A1 Keyword Search
A2 No Product Selected
A3 Product Out of Stock
A4 Payment Method Rejected
A5 Shipping Method Rejected
A6 Product Explicitly Identified
A7 Order Deferred
A8 Ship to Alternative Address
A9 Purchase Not Confirmed
A10 Confirmation Fails
etc….

Ну и немного описания
The Browse Products and Place Orders use case includes the following behavior:
The system displays the product offerings, highlighting the product categories associated with the Customer's profile.
The Customer selects a product to be purchased, entering the number of items required.
For each selected item that is in stock, the system records the product identifier and the number of items required, reserving them in inventory and adding them to the Customer's shopping cart.
Steps 3 and 4 are repeated until the Customer selects to order the products.

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

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

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

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

Так почему бы вам не описать все эти ВИ полностью и понять что в них общего, а что можно объединить и не рассматривать как отдельную часть функциональности?

На каком слове акцент?

Быстро Тем более ведь еще надо работать. Вы читаете на английском? Могу прислать интересную книгу, если в личке дадите адрес.

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

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

Классики use cases говорят, что расширяющий use case начинает жить как альтернативный поток, и тот и тот запускается по условию.
Так что, если вам кажется, что это правильно и соответствует вашему пониманию - конечно делайте.

Предлагаю нарисовать схему и описание ВИ тогда сразу будет ясно, что к чему