Поддержу Эда, нифига не понял

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

А сказать я хотел следующее: экономией времени на проектировании очень часто оправдывается лень и авторитаризм. Да, описание UC может быть в разной степени полным и формальным, в зависимости от масштаба проекта и использования аутсорсинга, но совмещать его с изложением реализации (экранных форм) IMHO очень вредно: трудно делать всё сразу, "за один шаг", и при этом хорошо. Невозможно проверить ответ задачи (архитектуру, в т.ч. формы), не увидев её условия (требований, в т.ч. UC).

Алекс, теперь идея понята. Ты полагаешь, что более прав Коберн, чем Розенберг?

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

Хотелось бы спросить, ты читал книгу Розенберга (указанную в первом посте) или критикуешь позицию автора с моих слов?

Ведь я мог просто элементарно не разобраться в мотиивации автора и выдал лишь то, что прочитал.

Однако и книга Авара Якобсона Aspect-Oriented Software Development with Use Cases во многом перекликается с идеями Розенберга.

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

Кроме того действительно, а что значить разработка, основанная на вариантах  ипользования? Не то же, что требования обязательно описываются как варианты использования!

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

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

От заказчика получено одобрение.

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

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

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

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

Что Вы думаете?

Phsony, я с Вами согласен. Примерно в том же направлении я думал и размышлял.

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

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

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

Вообще, можно применять и такой подход.
Но будет ли у вас время на переработку и детализацию всех ВИ?
У нас была принята такая схема работы:
1. Пишем сценарий ВИ + формы
2. Типа согласуем с заказчиком, но его не было как такого, т.к. мы развивали новое коробочное решение
3. Если Программисту было что-то не понятно, то шаг сценария детализировался в секции функциональные и требования и делалась ссылка из шага и из AN друг на друга.
До компонентов программы мы не детализировали.