Проектировщик интерфейсов, который работал там, утверждает, что их аналитики создают описания use case вот в таком виде.

Что вы об этом думаете?

Полностью согласен с Your Dah.
То что предложено не является use case в его изначальном понимании. Правда авторы и название извратили и семантику. Сценарий как мы понимаем экземпляр Use case, а не наоборот.

Все зависит от поставленного в Большой компании процесса. Может им так удобнее, может они сначала создают графическое изображение странички, а потом уже задумываются о логике работы...Например, сначала прорабатывается юзабилити, а предметка воруется с другого сайта...
То что их нельзя называть use case, я согласен - суть они переврали, с другой стороны, если такой подход помогает им разрабатывать качественные и классные продукты, то почему бы и нет. В конце концов - методологии и технологии - это лишь инструмент достижения целей...

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

Мне ещё понравилось Описание целевой аудитории. Кто-то, похоже, прочитал "Психбольницу в руках пациентов" и так же "творчески" применил подход, описанный Аланом Купером.

А ещё есть диаграммы взаимодействия. Но аналитикам со слабым здоровьем я туда ходить не советую, а особенно не советую смотреть на URL этой страницы.

ИМХО, весь этот "контент" используется только пиара ради, а не работы для. Сайт должен создать у клиента видимость "солидности" - очень распространённое в рунете явление в последнее время.

Я такой подход описал в своей презентации - Пользовательские Сценарии как лучший способ описания Пользовательских Требований

Как "Сценарии взаимодействия" это вполне может себе жить. Но не как Use Cases. Я всегда говорил, что если желаешь делать ТАК КАК ТЕБЕ ХОЧЕТСЯ/удобно/понятно ... то называй это "сценарием", если обзываешь нечто use case, будь добр придерживаться их сути.

А ещё есть диаграммы взаимодействия. Но аналитикам со слабым здоровьем я туда ходить не советую, а особенно не советую смотреть на URL этой страницы.

Взять банан, подписать Это перец - поди потом докажи, что это вовсе не перец.

То что изображено называтся примерно так - диаграмма последовательности экранных форм. Крэг Ларман, в частности, приветствовал использования диаграмм состояний для отображения логики переходов по web-страницам.

Что они и сделали, почему-то назвав диаграммами взаимодействия. Вопрос кто с кем взаимодействует?

Так это дизайнерский юзкейс?...

На юзкейс обычный не тянет - там же дизайн описан.

Состав полей — это дизайн? Впервые слышу.

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

ida, это элементы проектирования, а не дизайна. Ты же пишешь выше «дизайнерские use case'ы?».

А мы таковых не знаем Есть business use case, use case и use case realisation. Похоже на последнее. (Если бы не прочие НО).

Отличный антипаттерн. Нужно будет сохранить и в тренинг вставить.

Коллеги из минской локации...
У нас в компании все зависит от проекта. Поэтому, слава богу не все так пишут UC в EPAM

Я однажды читал UC, которые присылали аналитики из Штатов ... "я плакалъ". Так что дело не в локации и компании, а в конкретных людях.