У меня вопрос.
Сейчас аналитики пишут ТЗ для новой системы.
Моя роль.
1 Помогал создавать прототип GUI в Visio
2 Сейчас выполнению GUI в Visual Studio C#(кликабельный интерфейс).Была дана установка - должно быть все красиво

Возникли проблемы:
1 При выполнении GUI на C#(используем только базовые компоненты) , стали появляться требования типа: добавь или удали кнопку.Добавь грид с данными.
В результате приходиться все перерабатывать.
2 Некоторый Gui функционал выполненный в Visio просто не знаю как делать.(Тут видимо сказывается начальный опыт в C#.Ограниченно колличество GUI компонентов)

Как у вас поставлен процесс?Как разрулитьпроблему?
Какой должен быть уровень детализции GUI на данном этапе?
Спасибо

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

Теперь детально.

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

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

Второй уровень — это понимание того, как эти задачи соотносятся друг с другом. Как часто возникает та или иная задача и в какой связи.

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

Чтобы не возникало постоянных переделок, необходимо фиксировать пользовательские задачи и автоматизировать их, разбирая по итерациям. При попытке внесения изменений требовать обоснование в терминах критериев успеха данного проекта — больше денег, меньше затрат, меньше процент ошибок, больше количество обработанных заявок и т.д — всё измеренное в «на сколько именно»?

Как мы делаем.

Строим модель предметной области.
Пишем Способы Применения, сопровождая их Структурами Данных, Правилами и Ограничениями.
Разрабатываем Модель Навигации, определяя перечень Экранов, необходимых для покрытия этих Способов Применения.
Делаем Макеты экранов, опираясь на Сценарии и Структуры Данных.
Отдаём Макеты на согласование Разработчикам.
Разработчики согласовывают и позже, при реализации показывают реализованное в ходе итерации.
В ходе реализации итерации N мы прототипируем следующие Способы Применения и вносим корректировки в макеты итерации N-1 (функциональность которых уже доступна и тестируется), складируем доработки с обоснованиями в план итерации N+1.

У нас совсем другая ситуация :-(.
По поводу установки - "должно быть красиво".
Как я понимаю. На данном этапе интерфейс  делается для руководства , чтобы оно или они одобрили продолжение проекта.Как я понял согласование с разработчиками неведется.

Офтопик. А кто нибудь сталкивался с такой ситуацией, когда продумывание интерфейса отдается на откуп разработчику? У меня на работе именно такая технология. Макет интерфейса делается только если совсем сложная форма. Несложные формы разработчики ваяют прямо по ТЗ. Плюс в том, что при написании ТЗ нет надобности и интерфейс разрабатывать, а с другой стороны юзабилити полученного результата, мягко скажем, хромает. Правда у нас ПО для внутреннего употребления, возможно поэтому такая схема и продолжает быть рабочей.

По теме.
Если сейчас у вас этап разработки ТЗ, то сначала пусть все бизнес-требования соберут. А уже когда их зафиксируют(!), тогда и делайте прототип интерфейса. Причем сразу в VS, чтобы не наталкиваться на то, что нарисованное в Visio невозможно реализовать в VS. И на просьбы в очередной раз изменить ваш прототип требуйте обоснований. Изменения тех же бизнес-требований, например. Основной смысл - поставить между вами и заказчиками еще один слой, через который их пожелания будут проходить к вам и который будет играть роль фильтра для действительно значимых требований.

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

Денис!
Если я правильно понял вы работаете так?
Прости за мой убогий UML.
Поправь по возможности ошибки.
Спасибо.

P.S. Я просто хочу в плане собственной инициативы описать процесс разработки GUI (как есть и как надо).
Пока мне непонятно какая должна быть входная и выходная информация

Андрей, во первых у вас очень странная нотация выбрана. Мне кажется, что проще было-бы нарисовать это в ARIS или в IDEF. Тогда можно будет избавиться от надписей "входная/выходная", да и нагляднее будет.

Что касается схемы. Я думаю, что на шаге "Построение модели предметной области" никак не может появится диаграммы UC. Раз уж аналитик (какой аналитик, кстати, системный, бизнес-аналитик?) описывает предметную область, то и результатом его работы, скорее всего, должен быть перечень сущностей предметной области и диаграмма их взаимосвязей.

А диаграммы UC будут уже на следующем этапе - "Описание способов применения". Кстати, а "структуры данных" - что вы под этим понимаете? Если это структуры в разрабатываемой ИС, то вряд ли их создает аналитик. Как правило это задача либо разработчика, либо архитектора. И что такое "сценарии"?

"Разработка макетов экранов" у вас на выходе ничего не имеет? А что же тогда там происходит?

Андрей, во первых у вас очень странная нотация выбрана. Мне кажется, что проще было-бы нарисовать это в ARIS или в IDEF. Тогда можно будет избавиться от надписей "входная/выходная", да и нагляднее будет.

Что касается схемы. Я думаю, что на шаге "Построение модели предметной области" никак не может появится диаграммы UC. Раз уж аналитик (какой аналитик, кстати, системный, бизнес-аналитик?) описывает предметную область, то и результатом его работы, скорее всего, должен быть перечень сущностей предметной области и диаграмма их взаимосвязей.

А диаграммы UC будут уже на следующем этапе - "Описание способов применения". Кстати, а "структуры данных" - что вы под этим понимаете? Если это структуры в разрабатываемой ИС, то вряд ли их создает аналитик. Как правило это задача либо разработчика, либо архитектора. И что такое "сценарии"?

"Разработка макетов экранов" у вас на выходе ничего не имеет? А что же тогда там происходит?

К сожалению у меня ограничение по использованию инструментария по построению диаграмм.Можно использовать: Rational Rose, Visio, MindMap и все.

Зачем мне это надо:
Выше вы писали:"Крайне желательно разработать документ, регламентирующий процесс разработки."
Пока документов таких я не видел.А мне надо эти документы , чтобы показать руководству.Вот смотрите вот там работают так-то или так-то.А мы можем работать исходя из ресурсов так.
Просто у меня есть опасения , что проект могут зарубить по политическим причинам.
Спасибо за пример , который  дал Денис.Денис описал письменно как они работают(см выше).Что собственно я и попытался изобразить(с ошибками).
Вот еще хороший пример:http://www.jvetrau.com/2008/07/01/proektirovanie-v-agile-protsesse-grafik-rabotyi-komand-razrabotki-i-analitiki/
Тут  кратко указанны документы , сроки и тд.
 
Помогите с диаграмками.
Спасибо.

Денис!
Если я правильно понял вы работаете так?

Вот ещё документарное содержание: http://beskov.ru/wp-content/uploads/2008/11/beskovdenis_requirementsdox.pdf

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

В предметной области не только сущности есть и значимы.

В предметной области не только сущности есть и значимы.

Согласен. Я не писал, что только сущности.