К вопросу об именовании вариантов использования мы обращались периодически.

Что интересно в мировом сообществе тоже идут дискуссии. Общаясь с Putcha V. Narasimham я обнаружил, что он именует варианты использования с точки зрения системы. Т.е. вместо Посмотреть меню или Сделать заказ (для Клиента), он пишет Предоставить меню и Принять заказ. На мой вопрос: "Почему он поступает именно так?", получил ответ:

The Use Case Names are the "Names of Services" that "the System provides".  They are very short.  If we do not adopt a strict convention we would not know "with reference to what we are giving a particular name to Use Case".
 
If you name a use case "make payment" it is difficulty to say who makes payment to whom? 
 
If the standard reference is the system, then it means that system makes payment to whoever (Actor) is connected to the Use Case.
 
If the Actor makes payment, then the system needs to receive the payment.  With reference to the system the use case name should be "Enable Payment" or "Receive Payment"...the use case Goal in both the cases is "Actor makes payment to the System and obtains receipt"
 
My proposed convention is based on typical naming in banks.  When a bank says "Payment" it means "Bank pays".  "Receipts" means, "Bank receives".
 
If Use Case Goals are fully written as Use Case Names, then there is NO NEED for any convention.
 
We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names.  One can guess what is intended form commonsense but cannot infer from the Use Case Name.

Во вложении таблица Акторов и  Вариантов использования в авторском оригинальном исполнении

Что вы думаете об этом? Какие аргументы за или против выскажите?

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

Здесь я вижу некоторое пересечение в недавно созданной мною темой.

Преображенский: Так что же вы читаете? Робинзона Крузо?
Шариков: Эту - как её?.. Переписку Энгельса с этим... Как его, дьявола?.. С Каутским.
Преображенский: Позвольте узнать, что вы можете сказать по поводу прочитанного?
Шариков: Да не согласен я.
Преображенский: Что, с Энгельсом или с Каутским?
Шариков: С обоими

В корне не согласен с подходом товарища Putcha. Возникает вопроос, проводился ли вообще этап, именно, Бизнес анализа?! Определялись ли бизнес проблемы, которые необходимо решить с помощью открываемого проекта, выявлялись ли Business Actors, определялись ли их Goals, вообще, каким образом формируется список будущих Use Cases? Если путем функциональной  (или системной) декомпозиции будущей системы, то это врядли получится, так как на этапе формирования Busines Use Cases видение системы еще только самое общее... Прикинуть-то можно, только ценность такой прикидки будет нулевая.
Если смогу выкроить полчасика, постараюсь изложить свою точку зрения нашему зарубежному коллеге на "Use Case Professionals"
Кстати, возвращаясь к эпиграфу...

Здесь я вижу некоторое пересечение в недавно созданной мною темой.

Павел, мне показалось, что в подходе, описанном в твоем посте, для определения Use Cases опять же используются тот самый метод функциональной декомпозиции... Меня учили (и я с этим согласен), что это мягко говоря "неверный" подход. Дело не в чистоте учения! Дело в том, что такой подход уведет вас в сторону и создаст море проблем. Каких, можно обсудить
Короче! Не согласен я!  

Павел, мне показалось, что в подходе, описанном в твоем посте, для определения Use Cases опять же используются тот самый метод функциональной декомпозиции... Меня учили (и я с этим согласен), что это мягко говоря "неверный" подход. Дело не в чистоте учения! Дело в том, что такой подход уведет вас в сторону и создаст море проблем. Каких, можно обсудить
Короче! Не согласен я!  

Да, там нечто подобное: сначала декомпозируем систему на модули/подсистемы, а в рамках каждой подсистемы ДЛ выполняют определённые ВИ (но ВИ выполняются как ДЛ, так и, возможно, сервисом системы). Почему это неверный подход? В данном подходе, на мой взгляд, проявляется некое пересечение с ГОСТ 34.602-89, где изначально необходимо определить структуру системы, а потом уже написать функциональные требования к каждому модулю. Однако ФТ могут же быть описаны и с помощью ВИ.

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

Спасибо.

Друзья, мне кажется дело тут не в подсистемах и декомпозиции.

Возьмем актора/роль Клиент (Patron). Что хочет получить клиент от использования системы?
Разместить заказа на питание (сделать заказ на обед). Зачем? Он хочет поесть в столовой, ресторане или другом общественном месте. Там реализована система электронного меню, которая должна была ускорить процесс обслуживания и дать больше возможности при выборе блюда. Потому чтобы добиться своей цели Пообедать, клиент использует нашу систему чтобы Разместить заказа.
Естественно мы пишим в требованиях нечто вроде: "Система должна Принимать заказы клиентов"

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

Естественно мы пишим в требованиях нечто вроде: "Система должна Принимать заказы клиентов"

Это пример того, как пользовательские требования декомпозируются функциональными.

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

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

Но это сразу приводит нас к тому, что ВИ=функция (feature)

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

Из профиля уважаемого индийца я сделал вывод, что он работает и преподаёт в Индии.

Эд, ты не мог бы уточнить у него, о каких именно ошибках идёт речь во фразе «We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names»?

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

В корне не согласен с подходом товарища Putcha. Возникает вопроос, проводился ли вообще этап, именно, Бизнес анализа?! Определялись ли бизнес проблемы, которые необходимо решить с помощью открываемого проекта, выявлялись ли Business Actors, определялись ли их Goals, вообще, каким образом формируется список будущих Use Cases? Если путем функциональной  (или системной) декомпозиции будущей системы, то это врядли получится, так как на этапе формирования Busines Use Cases видение системы еще только самое общее... Прикинуть-то можно, только ценность такой прикидки будет нулевая.

Александр, Putcha всего лишь предложил названия, альтернативные тем, что заявлены у Вигерса: http://processimpact.com/process_assets/sample_requirements_documents.zip
За основу взят перечень способов применения из образца документа Вигерса, поэтому вопросы не имеют смысла.

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

Эд, ты не мог бы уточнить у него, о каких именно ошибках идёт речь во фразе «We arrived at this convention after seeing that a lot of students and professionals are utterly confused in interpreting the Use Case Names»?

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

Попробую

Давайте обсудим.

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

... пользовательские требования декомпозируются функциональными.

А, если одно пользовательское требование покрывается одним функциональным? Всегда ли мы говорим о декомпозиции одних требований другими, или все-таки они состоят в других "родственных" отношениях?

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

Что такое высокоуровневые? А, бывают низкоуровневые? Как они выглядят, что описывают, в какой форме?

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

Денис, отличная идея! Теперь, если мы будем писать плохие UC мы будем объяснять американцам, что это наша национальная специфика, мы так понимаем английский!

За основу взят перечень способов применения из образца документа Вигерса, поэтому вопросы не имеют смысла

Денис, да не важно, что взято за основу, главное, что бы они понимали, что такое UC. Последовательность операций, выполняемых модулем - это все что угодно: алгоритм работы программы, циклограмма, или что-то еще но никак НЕ UC. 
Опять же, с удовольствием пообщаюсь на эту тему, но голосом. На развернутые сочинения просто нет времени  
Да, и не совсем понял по поводу "...вопросы не имеют смысла"

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

Александр, вы знакомы с примерами документов Вигерса, опубликованными на его сайте processimpact.com? Сравните текст его документа с текстом индийца. И переадресуйте вопросы Вигерсу, если не находите проработки бизнес-части в документах Вигерса.

Денис, да не важно, что взято за основу

А мне важно, тем более что вы начали рыть в сторону «да понимают ли они, что делают».

главное, что бы они понимали, что такое UC.

А вам это зачем?

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

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