Алё, гараж. Я понимаю, что время летнее и всё такое, но давайте двигаться дальше!

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

Предлагаю такой набор для обсуждения на семинаре:
1. Границы применимости прецедентов - для чего они подходят, для чего уже нет
2. Примеры конкретных прецедентов (не забудьте подготовить "50 страниц контекста" :-)
3. Шаблоны прецедентов - наиболее типовые прецеденты, их повторное использование - CRUD, ...

Жду ваших идей и предложений по наполнению семинара.

Ориентир по дате - последняя неделя июня.

1. Что понимается под прецедентом? Вариант использования или нечто иное? Если первое, то давайте сразу определимся с терминалогией.
2. Прочитайте мои переводы по концепции вариантов использования на Open UP - думаю весьма полезно для старта
3. Имеет ли смысл рассматривать разные виды UC: бизнеса, системные, прозрачного или черного типа

А зачем презентация и доклад? рабочий семинар сделаем.

даже эргономисты с ними работают.

Ага, написал в теле письма на гмэйл.ком "вариант использования" - вышла контекстная реклама крупной юзабилити-компании и семинара по управлению проектами

1. Многих волнует:
а. отличие БВИ от СВИ и когда то или иное использовать
б. переход от БВИ к СВИ.
в. переход от СВИ к ДК
2. Сравнить Коберна с РУП
3. Разобрать пример или два
4. Проблема описания внутренних БП с помощью ВИ
5. Типичные ошибки новичка при работе с ВИ
6. Что такое ВИ?
7. Достаточно ли ВИ при описании функц. требований?

Ориентир по дате - последняя неделя июня.

Вот по дате нужно будет согласовать отдельно ...

1. Многих волнует:
а. отличие БВИ от СВИ и когда то или иное использовать
 б. переход от БВИ к СВИ.

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

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

в. переход от СВИ к ДК

ДК есть реализация СВИ, поэтому переход возможен через реализацию варианта использования путем построения так называемой VOPC view only participant classes
при этом сущестует рекомендация: на каждого участника(актора) по одному граничному классу, один управляющий класс на один ВИ, и часть относящихся к делу классов-сущностей.
Например в выше приведеном примере, можно было бы создать показать:
Форму документа продажи (+ возможно  форма деталей продажи)
управляющий класс - Менеджерпродажи и возможно МенеджерТранзакций
Интерфейс подключения к системе управления запасами
Ну и сущностные классы Продажа, Товар как минимум

2. Сравнить Коберна с РУП

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

3. Разобрать пример или два

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

В ходе проекта пришла идея создания специализированного рабочего места преподавателя или система разработки УМК с использованием шаблонов, сценариев разработки, не знаю найдутся ли энтузиасты сделать это

4. Проблема описания внутренних БП с помощью ВИ

Что значит внутренние БП? и в чем тут проблема?

5. Типичные ошибки новичка при работе с ВИ

1. плохое знание матчасти - попытка сразу делать модели писать сценарии, не имея пока четких теоретических знаний
2. функциональная декомпозиция
3. смешивание уровней абстракции
4. попытка применять технику ВИ ко всем подряд случаям
5. + все те ошибки, которые описаны у Коберна. Я своим студентам так и говорю, по вашим ВИ писать книгу Как не надо делать. Причем делаются такие ошибки с пугающей неизбежностью

6. Что такое ВИ?

Экземпляр вариант использования описывает последовательность действий, выполняемых системой, которая приводит к заметному результату, представляющему ценность для отдельного действующего лица.
Функциональность системы определяется различными вариантами использования, каждый из которых представляет особую цель (заметный результат, представляющий ценность) отдельного действующего лица. Описание варианта использования определяет, что случится (произойдет) в системе, когда вариант использования выполнится.
Каждый вариант использования имеет свою собственную задачу выполнения. Собранные варианты использования составляют все возможные способы использания системы. Следует так именовать вариант использования, чтобы цель его выполнения ясно и просто определялась из его названия.
Вариант использования может следовать по почти неограниченному, но счетному, количеству путей. Эти пути представляют альтернативы, раскрывающиеся при описание потоков событий варианта использования. Выбор того или иного пути зависит от событий:
Вариант использования описывает то, что происходит в системе, когда действующее лицо взаимодействует с ситемой. Вариант использования не определяет, как система выполняет свои задачи с точки зрения взаимодействующих объектов. Для этой цели применяется реализация варианта использования.
Каждый вариант использования должен иметь название (имя), которое показывает, что достигается при его (варианта использования) взаимодействии с действующими лицами. Название может содержать несколько слов для полноты понимания назначения варианта использования.
Для того, чтобы описать возможный поток событий, составляющий ВИ, полезно для начала понять, выяснить в какие возможные состояния должна перейти система при его выполнения(при выполнении экземпляра ВИ). Понимая, чего должен достигать ВИ при своем выполнении, проще придумать, предложить потоки событий, приводящие к этим состояниям.

7. Достаточно ли ВИ при описании функц. требований?

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

1. Многих волнует:
а. отличие БВИ от СВИ и когда то или иное использовать

Ну это есть в ФАК, ты в принципе тоже и повоторил. Вопрос снимаем.

б. переход от БВИ к СВИ.
в. переход от СВИ к ДК

Немного подправлю и добавлю твои мысли в ФАК

2. Сравнить Коберна с РУП

Ну тут ты в корне не прав. А как же БВИ и СВИ по РУП и облака/моря по Коберну.

3. Разобрать пример или два

Самые каверзные примеры ты можешь подкинуть

4. Проблема описания внутренних БП с помощью ВИ

Если в кратце, то ВИ не для этого .... См. http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=265.0

5. Типичные ошибки новичка при работе с ВИ

НУ кроме тебя и Юры врядли кто-то более полно раскажет об ошибках. Подумай плиз и добавь еще. Потом в ФАК добавим.

6. Что такое ВИ?

Ну это я для вводного вопроса оставил, в принипе, это есть в ФАКе

7. Достаточно ли ВИ при описании функц. требований?

Скорее вопрос когда достаточно, а когда нет

+ еще вопрос:

8. ТЗ по ГОСТ и  ВИ

Ну тут ты в корне не прав. А как же БВИ и СВИ по РУП и облака/моря по Коберну.

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

Самые каверзные примеры ты можешь подкинуть

Ну не наю...
 

Вобщем, чтобы перевести дискуссию в более практическое русло, я предлагаю каждому желающему подготовить мини-доклад на 10 мин сообщения + 10 мин обсуждения.

В частности, я готов рассказать о диаграммах прецедентов:

1. Расширение диаграммы прецедентов стереотипами <<потребность>> и <<функция>> - как я к этому пришёл, зачем это надо, как это использовать.

2. Использование отношений <<include>> и <<extend>> на практике - стоит ли их использовать при общении с экспертами заказчика и как сделать их максимально понятными для них.

Было бы здорово, если бы Юра сделал мини-доклад на тему "как убедить Заказчика в целесообразности использования прецедентов для описания ФТ".

Boatman, может мы пойдём итерационно, от малого, не дожидаясь подготовки многостраничного доклада по целеполаганию? И тебе будет проще, и нам, к тому же мой доклад пересекается с этой темой.

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

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

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

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

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

Да, всё это можно делать, если договоримся. Тебя какая тема интересует?

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

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

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

Ну за учёного-теоретика сойдёшь ) Если я подкреплю твои рассуждения практикой, то и нормально.

Да, всё это можно делать, если договоримся. Тебя какая тема интересует?

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

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

Я говорю например о стандартных стереотипах, они конечно стандартны потому как приняты разработчиками и активно используются в кодогенерации, инжиниринге и т.п.
В частности к ним относятся "business use case" "case worker" "internal actor" и некоторые другие. Это несколько перекликается и с твоим пониманием стереотипа "потребность" - как некоторая ожидаемая функциональность. Термин "функция" - до конца  не понятен, слишком противоречит понятию варианта использования

Ну за учёного-теоретика сойдёшь ) Если я подкреплю твои рассуждения практикой, то и нормально.

Не ученого - но преподавателя.  Для ученого к сожалению в области ИТ - я слишком дилетант. Вот если бы семинар был по плазмохимии

Денис! По поводу стереотипов для UC предлагаю до семинара помотреть в сторону Requironments диаграммы bp UML2

Ты должно быть имеешь в виду SysML.

А можно прийти на семинар не с ответами, а с вопросами? Или доклад является входным билетом?