Прочитал доклад Александра. Соглашусь с Виталием. По-моему чистое нарушение принципа Оккама: не создавай сущностей сверх меры.

Представленные для обсуждения пользовательские сценарии по существу варианты использования в стиле Дуга Розенберга, о которых мы уже начали дискутировать в теме Розенберг против Коберна. Замечу, что Розенберг указывает на то, что:
1. каждый шаг ВИ должен содержать объекты модели предметной области и названия форм, как вы полагаете их использовать
2. описание должно быть не более 8 шагов
3. такой стиль помогает лучше понять задачу программисту и лучше написать user guide.

Как мне кажется пользовательские сценарии в интерпретации Саши - и есть сосбтвенно user guide в действии

Понятие сценарий часто определяется как экземпляр варианта использования

Единственное отличие в том, что в альтернативные сценарии представляют собой отдельный функционал, который является неким расширением основного функционала и под одним ПС собраны все функции, оперирующие конкретным объектом управления, например справочником

Ну собственно тут говорится об описании  CRUD ВИ

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

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

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

Естественно, исходя из презентации наверное все не ясно, многое хотел сказать словами.
Наверное ты прав, надо написать статью.

Александр, описанный Вами сценарий, мне напомнил crud ВИ, приведенный Коберном в своей всем известной книге .
Посмотрите ВИ32 в книге коберна, помоему вы написали нечто похожее.

Еще раз говорю, что мы когда декомпозируем ПТ вообще НЕ ДУМАЕМ КАТЕГОРИЕЙ ВИ, т.е. целями Пользователей, а декомпозируем по ф-ти, по блокам, как-то еще ...

Саша, тогда не понятно зачем открывать велосипед, если он 100 лет открыт.

Иерархия требований существует давно. Стиль их описаний вполне конкретен. Используете ли вы сценарный тип ВИ или список - сути дела не меняет. На лицо функциональная декомпозиция.

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

Принципиальная разница между чем и чем?? Приведи аналог описания ИМЕННО  ПТ, похожий на мой.

Дык я не могу привести пример, поскольку не понимаю, что тут другого.

По моему типичные круд ВИ. От них принципиальная разница.

Ну вот пример пользовательских требований (и не только)

1. Книжный магазин должен быть реализован на базе web-технологий, но решение должно иметь достаточно гибкую архитектуру для обеспечения возможности разработки альтернативных внешних интерфейсов (Swing/апплеты, web-сервисы, и т.д.).
2. Книжный магазин должен быть способен продавать книги посредством заказов, принятых через Интернет.
3. Пользователь должен иметь возможность добавить книги в online торговую корзину, до контроля.
    a. Точно так же пользователь должен иметь возможность удалить выбранные книги из корзины.
4. Пользователь должен иметь возможность управлять списками предпочтений книг, которые он или она хочет купить позже.
5. Пользователь должен иметь возможность отменить заказы прежде, чем они будут отправлены.
6. Пользователь должен иметь возможность совершить оплату кредитной картой или платежным поручением (банковским переводом).
7. Пользователь должен иметь возможность возвратить книги.
8. Книжный магазин должен быть встраемым в вебсайты партнеров, используя миникаталоги, которые получают из полного главного каталога, хранимого в центральной базе данных.
   a. Миникаталоги должны быть определены в XML-формате, поскольку они будут переданы между этим и (позже, чтобы быть определенными) внешние системы.
  b. Система выполнения доставки должна быть выполнена через Веб-службы Амазонки.
9. Пользователь должен иметь возможность создать учетную запись клиента, так, чтобы система запоминала детали пользователя (название, адрес, детали кредитной карты) при его входе в систему.
  a. Система должна поддержать список учетных записей в своей центральной базе данных.
  b. Когда пользователь вошел, его пароль должен всегда соответствовать паролю в сводном списке учетных записей.
10. Пользователь должен иметь возможность поиска книги в соответствии с различным методами поиска: по заголовку, по автором, по ключевому слову, или категории - и затем изучить детали книги.
11. Пользователь должен иметь возможность отправить отзыв на понравившиеся книги; комментарии
должны появляться на экране деталей книги. Обзор должен включать оценку клиента (1-5), которая обычно отображается рядом  с заголовком книги в списке книг.
   a. Рецензии на новую книгу должны модерироваться то есть быть проверенными и одобренными  представителем персонала прежде, чем они будут опубликованы на вебсайте.
   b. Более длинные отзывы должны быть урезаны при отображении на экране деталей книги; клиент может
изучить полную версию отзыва на отдельной странице.
12. Должна существовать возможность для персонала публиковать рецензии редактора книг. Они должны также
отображаться на экране деталей книги.
13. Книжный магазин должен позволить сторонним продавцам (например, книжные магазины second-hand) добавлять их собственные индивидуальные книжные каталоги. Они добавляются в сводный каталог книг так, чтобы книги этих продавцов включались в результаты поиска.
14. Книжный магазин должен быть масштабируемым, со следующими определенными требованиями:
   a. Книжный магазин должен быть способным к поддержанию учетных записей пользователя вплоть до 100 000 клиенты за его первые шесть месяцев, и затем дальнейшие 1 000 000 после этого.
   b. Книжный магазин должен быть способным к обслуживанию до 1 000 пользователей одновременно (10 000 после шести месяцев).
   c. Книжный магазин должен иметь возможность выполнять до 100 запросов поиска в минуту (1,000/минута после шести месяцев).
   d. Книжный магазин должен иметь возможность выполнять до 100 покупок в час (1,000/час после шести месяцев).

аааааааааааааааааа, буду бить
Ну не ВИ это, там просто пример в презентации не совсем верный

аааааааааааааааааа, буду бить
Ну не ВИ это, там просто пример в прицентации не совсем верный

будешь бить или будут бить?

чего там в прицентации не совсем верное?

Саша - ты вроде аналитик - выражай мысль однозначно, а то не поймешь тебя приходится догадываться

Что такое ВИ? ВИ - это в первую очередь цель пользователя по отношению к системе. Т.е. чтобы правильно выявить ВИ нам нужно правильно сформулировать цели, которые далее станут ВИ.
Для начинающего аналитика правильно выявить цели и следовательно обозначить правильно ВИ трудно и требует значительных навыков и тренировки. Вот что получается когда человек пытается выявить ВИ: http://www.uml2.ru/forum/index.php?topic=286.0

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

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

Фуф, вроде все. Если и так не понятно, то я тогда не заню как объяснить ....

Окей, Саня, (блин хорошее у тебя имя - столько в нём разнообразия)

Мысль твоя понятна, понята и принята.

Правда не вижу нового на самом деле - типичное использование функционального подхода. Я подобное объясняю при преподавании DFD и IDEF0.

Т.е. имеем иерархию функции или процессов. Ну аналог твоей иерархии ПТ по сути. Декомпозиция упирается в миниспецификацию, которая может описываться с использованием:
1. описаний на естественном структурированном языке
2. с помощью языков программирования
3. с помощью визуальных блок-схем
4. с помощью таблиц и деревьев решений

правило такое - описание не должно превышать 20-30 строк (и то много), должно быть простым - т.е. следование ветвление цикл

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

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

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

Интересная ситуация. Я подумал, что если передо мной поставить задачу описать пользовательские требования для текстового процессора типа word, я знаю как это сделать используя подход Александра или используя форму ФТ и совершенно теряюсь как это сделать с помощью ВИ (CRUD ВИ).
Эд, не могли бы вы в качестве примера написать текст ВИ для текстового редактора типа word. (буквально 10 строчек, так чтобы было понятно, как они в принципе будут выглядеть)

Интересная ситуация. Я подумал, что если передо мной поставить задачу описать пользовательские требования для текстового процессора типа word, я знаю как это сделать используя подход Александра или используя форму ФТ и совершенно теряюсь как это сделать с помощью ВИ (CRUD ВИ).
Эд, не могли бы вы в качестве примера написать текст ВИ для текстового редактора типа word. (буквально 10 строчек, так чтобы было понятно, как они в принципе будут выглядеть)

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