Графический интерфейс в ТЗ

Спасибо, Vadim, за поддержку! Вчера я пошла этим путем. Сегодня уже приличный документ вырисовывается Думаю, это подойдет.

Я думаю, что на начальной стадии создания АС это — единственно правильный подход, иначе за деревьями можно не увидеть леса.

Сейчас при создании системы тоже возникла задача написать некий достаточно формализованный документ "Требования к пользовательскому интерфейсу". Мне понятен подход, предложенный surgeon выше. Но возможно ли не конкретизировать все? То есть на данном этапе понятно, что на экране должна быть группа функциональных кнопок. Но будут ли они располагатьяс в прямоугольном окне слева, или в колонке справа - пока неясно, так как идут обсуждения. Кроме того, по мере наращивания функционала, могут возникнуть кое-какие дополнения и в интерфейсе пользователя. Вопрос: может не стоит себя загонять в жесткие рамки строго расписанным документом "Требования к пользовательскому интерфейсу"? Может возможно подойти проще? Расписать, основные функциональные элементы, которые должны быть на экране, Минимальные размеры элементов, классификацию элеменов интерфейса прописать и т.д. То есть просто основные подходы при реализации интерфейса....?

Вы задайте свой вопрос на philosoft'е

Позовите

Эх, нет здесь byur'а.

Спасибо за ответ. Да, речь идет о пользовательском интерфейсе.
Рекомендуемое Вами описание экранных форм напоминает руководство пользователя, а это мне знакомо

Если речь идет о пользовательском интерфейсе, а не об интерфейсе какого-нибудь межмашинного взаимодействия, тогда можно так:

1. разрисовать (схематично) экранные формы с элементами управления, размещаемыми на них;
2. расписать назначение каждого элемента управления.

Допустим, на форме есть кнопка, при нажатии на которую на экране отображается другая экранная форма. Фразу можно построить несколькими способами:

1. кнопка такая-то предназначеная для вызова другой экранной формы;
2. кнопка такая-то обеспечивает выполнение функции вызова другой экранной формы;
3. еще варианты.

Это самый простой и прозрачный способ формулирования требований (состав -> назначение каждого элемента, входящего в состав). Получится древовидная иерархическая структура изложения.

Можно почитать здесь - http://authorit.ru/?c=8&b=6 и рядом лежащие статьи.

Здравствуйте. Я новичок-системный аналитик. Мне надо разработать требования к интерфейсу модуля. Я собираюсь нарисовать сеть переходов между экранными формами, с каким-то описанием. Видимо, буду рисовать и сами экранные формы. Хотелось бы уточнить, ход моих мыслей правильный или надо как-то по-другому разрабатывать требования? А рисовать в чем - в paint-е, visio, может еще в чем-то? Спасибо

Совершенно верно. Но в ТЗ можно затребовать применения конкретного технического решения. Полное право имеем. Например, "канал связи между тем и тем должен быть реализован с применением технологии Ethernet"

Что касается GUI - есть раздел "дополнительные требования", туда - все, что угодно, на рассмотрение разработчика.

Более того, мне лет десять приходилось создавать системы без проектирования вообще, действуя по схеме "ТЗ-ПМ-РЭ". Не было ни времени, ни денег.

Интересно ... вообще-то ТЗ по ГОСТ не предусматривает внесения проекта GUI как такового в текст ... ибо это уже дизайн. ТЗ содержит ТРЕБОВАНИЯ а не "технические решения". Говоря про ТРЕБОВАНИЯ к GUI, в частности на размеры кнопочек -- стоит говорить про т.н. ограничения проектирования -- т.е. отдельный вид требований, в котором и описывать размеры и форму элементов GUI. Но не в коем случае не рисовать в Visio или еще в чем-нить собственно экранные формы.

Нет в ТЗ такого раздела, но ГОСТ позволяет вводить новые разделы на усмотрение разработчика.

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

Картинки обязательно надо нарисовать, если после ТЗ не предусмотрено проектных работ.