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

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

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

Бывают, конечно. Например, шаги сценария, входящего в UC и выполняемые пользователем, которые представить в виде самостоятельного UC нельзя никак. Хотя на некотором уровне функциональной декомпозиции они тоже являются целями пользователя.

Мальчики и девочки,

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

1. синий - первая реплика Пушта
2. Темно-крансный мой ответ вопрос
3. зеленый вторая реплика в ответ на мой вопрос Пушта

Putcha: 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 difficult to say who makes payment to whom?
 
Why? UC is a part of usage model. This model includes Actors: at least one External Entity (Primary Actor)   (who "makes payment " ) and SuD (whom makes payment ). This "whom" is customer (client) of SuD
 
Putcha:  There are two possibilities of payments.  Consider an Electronic Shop---the SuD here.  SuD buys Goods from Seller and in turn sells Goods to Buyers.  In this case both Buyers and Sellers are primary users (SuD is created to serve both of them).  SuD  1 receives payments  from Buyers and 2 makes payments to the Sellers later. Payments are involved in both the cases of 1 and 2.  They need to be distinguished.  One way is full expression as given at 1 and 2.  If you wish to use a short expression "receives payments" or "makes payments", they should be with ref to SuD in all cases.
 
Another example is BANK (real or electronic).  It (BANK) RECEIVES money and PAYS money.

Putcha: If the standard reference is the system, then it means that system makes payment to whoever (Actor) is connected to the Use Case.
Why again? Actor makes payment by means of SuD. Actor USES the system to make payment. "Make payment" is not an actor goal. Perhaps this goal is to have comfort conditions for a living
 
Putcha: Please consider End-to-End Transaction involving External Seller and External Buyer (Actors in this case). When a sale occurs, Buyer pays 1 to SuD and SuD pays 2 to Seller.  In case 1 Sud RECEIVES payment and in case 2, SuD MAKES payment.  That must be clearly indicated in the naming of use cases.  Here we are concerned with Use Case Goals ....not ultimate goals of people.

Putcha: 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"
Я: Yes but it shall be the SYSTEM goal not the Actor. Actor doesn't want to receive or enable. To recieve or to enable is system responsibility I think.
 
Putcha:  In Use Case Diagram we have only Use Case Goals (there are no separate System Goals.  The System is there to enable Actors to Achieve their Use Case Goals).  It acts as an intermediary or medium between Buyer and Seller who are NOT directly connected.
 
With reference to SuD, "Receive Payment" means SuD Receives Payment from the associate Actor (Buyer here).  If the use Case Name is "Enable Payment", it means the SuD ENABLES the associated Actor  (Buyer here) to PAY.  If the Actor associated is Seller the use case name must change.  Here SuD "Makes Payment" to Seller.  Seller "Receives Payment" FROM SuD but Use Case here SHOUD NOT be named "Receive Payment" because the implied reference here is Seller (which is not correct).
My proposed convention is based on typical naming in banks.  When a bank says "Payment" it means "Bank pays".  "Receipts" means, "Bank receives".
 
Putcha: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.
 
Я: Could you explain me what kind of confusions  in interpreting the Use Case Names have a lot of students and professionals
 
Putcha: One example involving Buyer Seller is discussed above.  There are other such cases.  I will compile and send them to you.  Thank you.

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

Меня смутило слово "декомпозируются". Я привык, что функциональные требования описывают функциональность системы, которая должна помочь пользователю решить его задачи, достичь его цели (goal). Ведь именно User Goals ложаться в основу User Requirements. Т.е. создание набора Functional Requirements - это просто поппытка прикинуть, какая функциональность должна быть реализована. И этот набор создается необязательно путем "декомпозиции" (как, по какому принципу?) пользовательских требований. Отношения между User Requirements и Functional Requirements могут любыми: один ко многим, многие ко многим (т.е. одно пользовательское требование реализуется разными функциональными требованиями, но при этом одно функциональное требование может реализовывать несколько пользовательских в том или ином объеме), многие к одному...

Бывают, конечно. Например, шаги сценария, входящего в UC и выполняемые пользователем, которые представить в виде самостоятельного UC нельзя никак. Хотя на некотором уровне функциональной декомпозиции они тоже являются целями пользователя.

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

User requirements describe user goals or tasks that the users must be able to perform with the product. Valuable ways to represent user requirements include use cases, scenario descriptions, and event-response tables. User requirements therefore describe what the user will be able to do with the system. An example of a use case is "Make a Reservation" using an airline, a rental car, or a hotel Web site.

Software Requirements, Second Edition
by Karl E. Wiegers   ISBN:0735618798
Microsoft Press © 2003 (516 pages)

Т.е. это нечто законченное и значимое с точки зрения бизнеса заказчика. Отдельное действие, вырванное из контекста, типа нажатия на кнопку для пользователя отдельного и законченного смысла не имеет. Поэтому, мое мнение, пользовательским требованием быть не может.
Мы помним, что все требования мы должны валидировать с заказчиком. Если мы предложим заказчику для согласования пользовательские требования в виде "пользователь выбрал пункт меню <menu item>" впрядли он будет счастлив
Как вы считаете?

Отношения между User Requirements и Functional Requirements могут любыми: один ко многим, многие ко многим (т.е. одно пользовательское требование реализуется разными функциональными требованиями, но при этом одно функциональное требование может реализовывать несколько пользовательских в том или ином объеме), многие к одному...

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

Декомпозиция по жизненному циклу. Признак выделения подсистем — изменение закона функционирования подсистем на разных этапах цикла существования системы «от рождения до гибели». Рекомендуется применять эту стратегию, когда целью системы является оптимизация процессов и когда можно определить последовательные стадии преобразования входов в выходы.

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

http://victor-safronov.narod.ru/systems-analysis/lectures/rodionov/07.html

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

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

Опусти пистолет!
Все вопросы мы уже закрыли в личке 

Эдуард, не проще ли дать коллегам ссылку на эту дисскуссию на Use Case Professionals, вместо того, что бы работать двунаправленным транслятором идей?

Эдуард, не проще ли дать коллегам ссылку на эту дисскуссию на Use Case Professionals, вместо того, что бы работать двунаправленным транслятором идей?

[поставил на предохранитель]
1. туда нужно записаться для начала
2. мы ее не ведем в группе, а лично по переписке

Друзья, вот что обнаружилось по ходу.

В ряде книг, посвященных разработке ПО и UML от буржуйских коллег: Мацяшек, например. Обнаружил такие рассуждения:

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

Мой уважаемый коллега Пушта из Индии в присланных мне для прочтения материалах пишет:
"ВИ - именованная служба (сервис) системы, которая, как ожидается, обеспечивает ДЛ или действующим лицам, играющим ту же роль, достижение определенной цели"
Далее идет Соглашение о именовании вариантов использования. Формулировки соглашения появились в ходе общения со студентами AMSSOI 2010 Batch:
1. Имя варианта использования относится всегда к систем, а НЕ ДЛ (выделено)
2. Используй глагол, выражающий службу (сервис), которую система выполняет (обеспечивает)
E.g Show contents (NOT View Contents), Present Welcome / Home Page, Give Options and Instructions (NOT SELECT OPTIONS), Receive Payment (Not “Payment”), Capture Decisions, Capture Recommendations, Deliver Cash (NOT Collect Cash), Read Card (NOT INSERT CARD) 
3. Используй префикс "Делать возможным" для действий исполняемых действующим лицом
E.g “Enable Registration / Log-in” or “Enable Payment” or “Enable Decision Making” or “Enable Recommendations” or “Enable Card Insertion”

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

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

ВИ и ТЗ могут быть написаны с разными целями, для разных групп пользователей. Отсюда и детальность описания, отсюда способ именования.

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

ВИ и ТЗ могут быть написаны с разными целями, для разных групп пользователей. Отсюда и детальность описания, отсюда способ именования.

1. Потому что я начал тему и задал вопрос именно о правилах именования.
2. Категорически не согласен, это будет вносить еще более серьезную путаницу

Интересное набюдение, сделанное мною во время перевода статьи и ответов на вопросы: http://www.uml2.ru/forum/index.php?topic=4413.msg30153#msg30153