Предлагаю Вашему вниманию перевод статьи "Советы по наименованию вариантов использования"

Эд,

Мне понравились советы, только примеры немного подкорректировал бы, н-р, "Сравните: "Рассчитай рентабельность" и "Рентабельность рассчитывается"", заменил бы на "Сравните: "Рассчитать рентабельность" и "Расчет рентабельности""

Саша, понимаешь, тут как раз и есть тонкость перевода.

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

В отличии от английского мы используем обезличенную неопределенную форму: Рассчитать или отглагольное существительное: Расчет.

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

ИМХО нужно скорректировать.

Я С Сашей согласна. Когда я вижу такие названия "Встань, Иди, Возьми, Рассчитай" слух и взгляд режет.

Я С Сашей согласна. Когда я вижу такие названия "Встань, Иди, Возьми, Рассчитай" слух и взгляд режет.

Я исправлю, вопросов нет, но мне интересно как англоязычные воспринимают информацию по юзкейсам?

Т.е. я как рускоговорящий напишу:
Клиент
   Посмотреть меню (Просмотр меню)
   Заказать блюда  (Заказ блюда)
   Изменить статус заказа (Изменение статуса заказа)

он некто англоговорящий прочтет
Клиент
   Посмотри меню
   Закажи блюда
   Измени статус

Возможно именно по этому, коллега из Индии (о котором я писал в теме по наименованию ВИ) именно по этому и пишет, что для он считает более правильным если ВИ буду звучать так:
Клиент
   Представь меню
   Возьми заказ
   Измени статус - какая счастливая случайность ну или Представь возможность изменить статус

ИМХО нужно скорректировать.

Скорректировал, смотрите-советуйте

Ну для буржуев все по другому. Что для них привычно, для нас дико. Отступление: недавно приехала из Англии, там всюду говорят sorry, даже если ты ему на ногу наступил. А мне привычнее, что бы меня матом обложили.

Очень интересный топик. Очень часто приходится сталкиваться с различным подходом к форомированию списка UC, к их именованию. На самом деле это не такой уж второстепенный вопрос (мы не можем сказать it depends of project), поскольку это отражает принципиальное понимание что такое UC, откуда он берется, каков процесс выявления features и формирования списка UC.
Мое понимание этого процесса (меня так учили гуру живые и книжные ) я описал в топике на LinkedIn http://www.linkedin.com/groupItem?view=&gid=1216497&type=member&item=68658010&qid=3aaf5e8a-5442-4b77-abcf-41695380e0ae&trk=group_most_popular-0-b-ttl&goback=%2Egmp_1216497 (откуда, собственно вырос данный пост). Приведу здесь as is, надеюсь, там все понятно:

Hello, colleagues.
It seems you completed your discussion but this topic is very interesting for me and I'd like to clarify my opinion.
Every time when I start a new Use Case definition session I try to follow the following procedure.
I ask and answer the following questions:
What problem we want to solve? We want to increase book sale.
How do we solve this business problem? We solve that problem with a new Information System (IS).
How does the IS help us? IS should provide customer a set of features which makes his or her interaction with E-shop easier and more comfortable (read – more attractive). These features allow customer to achieve his (her) goals (e.g. order book, get catalog a so further).
Ok, we understand that customer will interact with our IS. And he or her will initiate some IS functionality (features) to order book, to get catalog, to cancel order and so on. Therefore Customer is an ‘actor’. And he (her) is a ‘primary actor’.
Ok, on the next step we should clarify what functionality we have to implement. Of course, first of all we have to implement functionality which meets user goals, because we develop IS for IS user, for customer.
One of the best way to describe it is Use Case as step by step scenario of using our IS for achieving some particular user goal.
Because of it I prefer to give UC a user goal name, for example “order book” (not “process an order”), “get catalog” (not “provide catalog”)… and describe this goal achieving by scenario of user-IS interaction. This is a Functional Requirement. We can find Requirement definition in many sources like Karl Viegers books and articles, in BABOK. The main idea of these definitions is it is something valuable from primary actor perspective(not IS itself). It is not a goal of IS in general or its individual module. It’s a primary actor goal.
Ok, we understood that our IS will interact with some external systems, for example publisher IS. Our IS initiates this interaction. Therefore publisher IS is a “secondary actor”. The secondary actors definition is an extremely important step of our procedure and we should not omit it.
And so further…
This procedure is not my personal discovery. There are a lot of methodologies that recommend to follow this procedure, RUP for example.
...