Что-то я уже запутался в аргументах и контраргументах. Мне бы, например, помогла ссылка на некое графическое отбражение взаимосвязей функций и ВИ, если таковое имеется или не лень рисовать.
А еще лучше - комиксы - http://top.rbc.ru/society/14/12/2010/514963.shtml

не в целях спорить:
1. От себя сошлюсь на Фаулера, который определяет UseCase (вариант использования) как множество сценариев, объединенных вместе некоторой общей целью пользователя (например "Настроить принтер" - пример мой).
Описание сценариев же выполняется в стиле "Пользователь делает это" - "Система делает то", отсюда и термин "интерфейс "пользователь-система".

Поясню также термин "грубо говоря" -  в данном случае он не означает, что UseCase определяется до уровня кнопок (несмотря на написанное выше :о))) - действительно UseCases ведь разрабатываются, когда система еще не существует, о каких конкретно элементах управления может идти речь. Но тем не менее те или иные (назовем их - стандартные или типовые) абстрактные элементы все-таки подразумеваются: элементы выбора - списки, меню, справочники и тп.; элементы продолжения - типа кнопки, элементы для ввода значений и т.д. и т.п. Кстати, с их использованием был разработан стандарт CUA и поныне используемый в Windows, MacOs, Linux и других системах.

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

2. Вообще-то я написал выше IMHO, и оно (это самое IMHO) распространяется на все три пункта. Извините, если это неочевидно.
Действительно, UseCase "Настроить принтер" может попасться под руку и при печати документа, и при печати форм, и при настройке устройства печати, и при переформатировании документа Портрет/Альбом, и ... да когда угодно! Поэтому наверняка не существует жесткой и однозначной связи между функциями системы (или может лучше Функциями Системы), которые пишут на коробке, и какими-то там UseCases. Однако существует ряд UseCase, которые связаны ТОЛЬКО с Функциями Системы - это те, которые относятся к основной ее функциональности (опять пардон за тавтологию), т.е. содержат то, для чего система создавалась (пример - "набор сообщения" в клиенте почтовой системы, каждый может по своим системам мноооого таких примеров насобирать). Их, кстати, можно (и нужно!) использовать при сравнении систем сходной функциональности.

всё вышенаписанное - IMHO.

Честно говоря, не вполне уловил логику, невзирая на IMHO :-) ... Я после некоторого опыта, стал очень осторожно относиться к указанию каких-либо элементов управления в теле варианта использования. Т.к. это часто воспринимается разработчиками буквально, а это не факт что наиболее оптимально с т.з. эргономики. Очевидно, что зависит от системы и контекста.

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

а если продукт не "коробочный"?

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

Типичная фича (она же функция), например, для телевизора - прием до 100 телевизионных каналов в метровом и дециметровом диапазоне...

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

Да, так пишу ... при таком описании мы не указываем конкретных элементов пользовательского интерфейса. Тот же список может быть выпадающим, скролируемым и т.п., посему, только говоря о списках, у нас уже появляется двусмысленность :-). "Пользователь вводит данные" - кто сказал что это именно в контрол типа Edit вводит пользователь значение? А может он вводит непосредственно в Grid??? Тут тоже нет однозначного указания на контрол. Так что пока я не увидел подтверждения вашего тезиса "IMHO это и есть недвусмысленное указание на те самые элементы" :-).

Хотя "меня терзают смутные сомнения" (с) - мне кажется, что мы подразумеваем одно и то же - т.е. что следует избегать написания в UC таких действий как "Пользователь нажимает кнопку <Распечатать>", или "Пользователь выбирает из выпадающего списка ...", а стараться заменять их более абстрактными утверждениями. Если вы хотели сказать именно это, правда пытались это сказать как-то очень сложно .... - то вопрос исчерпан :-)

Да, мы с Вами имеем в виду одно и тоже, и говорим практически одними и теми же словами :о))) Собственно, написав ранее "абстрактные элементы ввода, выбора и т.п." ровно это и имел в виду. Ведь на стадии формирования UseCases еще не вполне известно что и в каком объеме вводить... А "недвусмысленность" в том, что они (эти элементы) есть.

Тоже считаю вопрос исчерпанным.

А какая разница? ... Так и тут 5-10 основных преимуществ-функций (что делает Система) вашего решения, по которым можно его продать

с этим не согласен, в заказной разработке так далеко не всегда бывает, но это другая тема.

а стараться заменять их более абстрактными утверждениями. Если вы хотели сказать именно это, правда пытались это сказать как-то очень сложно .... - то вопрос исчерпан :-)

...
Тоже считаю вопрос исчерпанным.

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

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

IMHO это не от абстрагирования зависит, а от распределения зон ответственности за компоненты. ну и от архитектуры, ессно.

IMHO это не от абстрагирования зависит, а от распределения зон ответственности за компоненты. ну и от архитектуры, ессно.

Стандарты на GUI должны быть по-идее ...

Стандарты на GUI должны быть по-идее ...

скорее стандартные компоненты с определенными требованиями, которые повторно используются (и сами компоненты и требования к ним) - и так мы плавно перетекаем к управлению программными активами 

скорее стандартные компоненты с определенными требованиями, которые повторно используются (и сами компоненты и требования к ним) - и так мы плавно перетекаем к управлению программными активами 

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

да причем тут юзабилити? просто если в двух полях логин/пароль их заголовки в окне имеют 3 разные комбинации - это несогласованность требований, выданных (а скорее не выданных) разработчикам.
больших проблем не создает - но в других случаях (не с логином) может и создать.

если в двух полях логин/пароль их заголовки в окне имеют 3 разные комбинации

Мне всегда казалось, что названия полей - это прерогатива дизайна, а не требований.

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