I)
Пишите как вам больше нравиться, если Вы понимаете технику описания ВИ, то от того что Вы напишет ОК или Подтверждение - ничего не измениться. Вопрос только в двух вещах:
1. С самого начала надо учить правильно, если человек будет зацикливаться на ГУИ, то он никогда правильно писать ВИ не будет
2. Если уж пишите кнопка ОК, то все аналитики в компании должны писать так, а то один напишет Ок, другой Подвредить, третий Да, вот Вы и получите три формы с тремя разными кнопками.

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

II)
Ну кто вам мешать создать спек по ГУИ?? Мы так и делаем - сначала пользовательские Требования в виде ВИ, потом спек на ГУИ. То и то подтверждается у заказчика.

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

Но я похоже все же неверно донес мысль. Дело не в ГУИ, а в уровне абстракции. И разделение на три класса здесь очень условно.

-появляется ли при этом дополнительная логика на спеке экрана, не описанная в ВИ?
-не противоречит ли данная спецификация ВИ (и легко ли это понять)?
-дополняется ли ВИ после создания спеки?

1. Опять же как писать. Я обычно когда пишу, то вписываю все в рамки либо доп требований для ВИ, либо в дополнительные потоки действий. И у меня не появляется. Вот например девочка, которая только первый раз писала - у нее появлялась доп. функциональность (добавить/удалить счет и т.д.)
2. Нет. Главный закон требований - они должны быть не противоречивыми. Понять не так легко если идет все в разных документах, но можно. Особенно если это пишет один человек, как у нас это и происходит. Опять же Вы не используете никакой трассировки (систем упр. требованиями), по трассировке понять очень легко.
3. Как правило нет. Больше добавляется после ревью Заказчиком

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

1 Речь идет не о подмене спецификаций GUI сценариями. Речь идет о сценариях, опирающихся на элементы GUI.

Что очень часто приводит именно к тому, что описываем движение по интерфейсу, вместо движения к цели ... и это увы реальность (часто видел такое). И приводит к усложнению юзкейсов.

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

Невозможно реализовать проект быстро и одновременно качественно в условиях ограниченных ресурсов :-). Можно лишь с заданным уровнем качества. Остается определить каков этот уровень :-). А Коберн не задает стандартов ... он лишь вводит определенные практики написания. И никто не говорит что это истина в последней инстанции. Просто нужно ОЧЕНЬ внимательно изучить его практики и желательно не только по книге а и курс его послушать, если компания конечно оплатит, ибо самому -- очень дорогое удовольствие.

А на счет поддержки таких требований - это опять же по обстоятельствам. Если в проекте три аналитика, то почему бы и нет. К тому же, большой вопрос на что потратишь больше времени: на поддержку детальных требований или на объяснение программистам, как это хотелось бы видеть.

Практика показывает, что даже к не очень простому GUI при наличии хороших тренингов пользователи привыкают достаточно быстро. Вы видили пользовательский интерфейс Axapta? Жуть как все сложно ... а ничего .. работают :-).

Практика показывает, что если ты что-то не прописываешь, то это додумывают за тебя. И обычно это не совпадает с твоим видением.

А что тут можно не дописать, когда речь идет о GUI элементах в юзкейсе? Название кнопки поставят вместо "ОК" -- "Принять изменения", это смертельно и потребует больших усислий по переделке?

2 Согласен - демонстрация картинок это не решение проблем заказчика. Однако, сами понимаете, что большинство ориентируются на визуальную сторону. Так проще, хотя бы, начать разговор.

Ну и дайте им эту визуальную сторону ... storyboarding для этого и существует :-), причем РЯДОМ с юзкейсами а не в самих юзкейсах.

GUI как пример я выбрал, т.к. это самая банальная вещь. Можно привести пример другой ситуации: системе необходимо по запросу пользователя скачать файлы с удаленного сервера и проверить их целостность.

Писать можно и так:
1) Пользователь активирует загрузку
2) Система копирует объекты, взаимодействуя с системой N
3) Система проверяет целостность объектов

Это скорее всего вызовет больше вопросов. Если знаешь, что здесь лучше использовать протокол ftp - пиши ftp. Используй термины вроде "загрузка", "логин", "пароль", "адрес сервера" и всем будет проще.

Для начала Гл. успешный сценарий написан некорректно ... другая система будет как мининмум secondary actor и нужно делать отдельный шаг по взаимодействию с ней. Кроме этого вы НИЧЕГО не сказали о параметрах которые должен указать пользователь при активации загрузки .. посему "Пользователь активирует загрузку" больше тянет на Триггер а в первом шаге нужно указать что пользователь дает системе -- типа указывает URL или еше что-то ... Это действительно будет "абстрактный" юзкейс, если вы не упомяните еще все то о чем сказали в других слотах спецификации юзкейса ... про FTP/HTTP например в слоте Вариации технологий и данных ...
Вобщем пример IMHO либо сильно умышленно утрирован (понятно что для целей демонстрации идеи), либо не очень удачный.
Т.о. то что вы привели как пример не имеет ничего общего с рекомендациями Коберна.
[/quote]

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

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

Ух, тема интерфейсов прогрессирует. Ладно, как говорится - Devil is in the details. Чем отвечать на каждую фразу, думается, полезней рассмотреть конкретный случай: пользователю нужно просматривать список платежных поручений с возможностью фильтра по дате поступления. Другими словами, ему интересно просмотреть список документов задавая диапазоны дат. Я вижу здесь один сценарий - "просмотреть платежные поручения". Можете привести пример такого вот сценария?

2 Юрий
Да, не совсем корректно. Ок, исправляюсь. А относительно URL и других параметров - мы же не завязываемся на "технологии": возможно, у нас и нет никакого URL и мы связываемся через ком-порт.

Вариант 1.
-не оговариваю технологии: может и не клиент-сервер
-не оговариваю механизм установки соединения: кто знает, какой он... оставим варианты

Запускающее событие: пользователь инициирует загрузку
1) Система передает Удаленной_Системе команду на получение инф. объектов
2) Удаленная_Система передает  запрошенные информационные объекты Системе

Note: Если Вы говорите, что это утрированно - тогда, пожалуйста, покажите границу, после которой сценарий можно считать не-утрированным.

Вариант 2:
-ладно, пусть будет клиент-сервер
-ладно, пусть будет какой-то механизм соединения/аутентификации: не обязательно, основанный на передваемой идент. информации
-ладно, работаем с файлами, а не с "информационными объектами"
-не оговариваю технологии (кто знает - может быть ftp, http, smb, rsync или вообще com-порту)

Запускающее событие: пользователь инициирует загрузку
1) Система передает запрос на установку соединения с удаленным Сервером N
2) Cервер N подтверждат соединение
3) Система передает команду на получение файлов
4) Сервер N передает Системе запрошенные файлы

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

Вариант 3.
Догадываемся поговорить с архитектором и сопоставить требования с вариантами реализации. В результате
-полагаем, что используется ftp-сервер
-полагаем, что связь идет через корп. vpn, тем самым отпадает аутентификация на ftp-сервере

Запускающее событие: пользователь инициирует загрузку
1) Система передает запрос на установку соединения с удаленным ftp-сервером
*адрес сервера является системной константой SERVER_ADDRESS
2) Удаленный ftp сервер подтверждает соединение
3) Система передает команду на загрузку файлов каталога X
* X является системной константой SERVER_FOLDER
4) Удаленный ftp-сервер передает файлы
5) Система проверяет целостность файлов, сопоставляя чек-суммы

Основной тезис - чем больше мы примем РАЗУМНЫХ допущений (решений), тем проще будет сценарий в понимании и реализации.
Надо заметить, что это три совершенно различных сценария: последний не может быть редуцирован из второго или первого. Переход от абстрактности к конкретике здесь не РЕДУКЦИЯ, а КОНСТРУИРОВАНИЕ.

А теперь вопрос - какой из сценариев Вы бы использовали и почему? Можно свой вариант.

Ух, тема интерфейсов прогрессирует. Ладно, как говорится - Devil is in the details. Чем отвечать на каждую фразу, думается, полезней рассмотреть конкретный случай: пользователю нужно просматривать список платежных поручений с возможностью фильтра по дате поступления. Другими словами, ему интересно просмотреть список документов задавая диапазоны дат. Я вижу здесь один сценарий - "просмотреть платежные поручения". Можете привести пример такого вот сценария?

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

Важно уточнить, для чего именно собирается просматривать платежки пользователь. И, возможно, пользователь не один.
Возможно просматривать список платежных поручений нужно будет РАЗНЫМ заинтересованным лицам, которые будут решать на основании информации из платежки РАЗНЫЕ задачи?  Тогда еще, возможно, нужно будет решать, насколько оправданно делать один интерфейс для обоих пользователей... Т.е. хорошо бы еще понять -
1. ЗАЧЕМ пользователю нужно просматривать (с какой целью на бизнес-уровне).
2. Последовательность действий пользователя в ВИ, как способ достжения цели (сначала и отдельно на бизнес-уровне, затем на программно-архитектурном).
3. А от этого уже выстраивать логику интерфейсного взаимодействия пользователя и системы.