Пример ТЗ с описанием интерфейса

Добрый день! Может кто-нибудь поделиться для примера реальным ТЗ, где есть описание windows формы интерфейса. Хочу посмотреть, как правильно описать ТЗ для разработки пользовательской формы

msleg, любые стандарты определяют требования преимущественно к содержанию информации в ТЗ.

Краткая выжимка.
Если это ГУИ, и дизайн на усмотрение разраба:
картинка макета формы,
описание полей: названия/смысл/способ получения ... не надо экономить букв на этом,
диаграмма вариантов действий пользов-ля и реакций формы на это
ну и вообще реакции формы, если они самопроизвольные.
Желательно изложить системно, тематически и не разбрасываясь туда-сюда, без ошибок и опечаток, придерживаясь стргой терминологии, не использую синонимов и жаргонизмов.

Этого достаточно для самостоятельного оформления. Не стоит мимикрировать под чей-то высокий/бюрократический стиль, описывай так, как себе пожелал бы. Конечная аудитория документа должна легко находить в нём всё, что ей надобно - в идеале.

Чем оформить - очень часто в ворде / ехсел
Насчёт ГОСТ-рамочки - это как потребуют.
Успехов!

Ссчитаю полезным дополнить.

Не только для ТЗ желательно сначала небольшое ведение в тему:
Общее назначение формы с тзр. бизнес-прочессов и с тзр. программной системы.
Её место в "окружающей среде".

Для больших документов нужно дату, номер версии и хорошее оглавление, чтобы по его прочтению уже составить представление о содержимом, и как оно раскидано в тексте.
Вообще же ТЗ много разных в инете. Легко найти и увидеть, как стандартно составляют оглавления. Тематика здесь не важна, важна узнаваемость структуры документа. В помощь ГОСТЫ 19 и 34.

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

Ну как-то так.

msleg,

У нас используются:
связка Visio(сам интерфейс/с переходами, итеративностью)/Word(описание общий документ) для простых/дешевых/стандартных интерфейсов и проектов.
(пишет и рисует/проектирует аналитик на основании общих требований по факту примерный "sketch", без привлечения дизайнера, много на усмотрение разработчика 2-1 [тоесть ели разработчик скажет, что это сложно и долго, то в корзину], интерфейс особо не меняется в процессе разработки, закреплен на начальном этапе)

(axure vs sketch)интерфейс/pdf(документ) (пишет готовит аналитик с привлечением дизайнера, часто выделен отдельный верстальщик в случае с web, учитываются пожелания всяких отделов заказчика, но основные моменты определяются на начальных этапах) - средние проекты.

Gimp/Photoshop/coreldraw/jira(прямое общение с заказчиком ) - никаких документов! - (аналитик только записывает со слов дизайнера "брендинг/общую story и.т.д." и соотнося с требованиями, часть вообще рисуется от руки, как комиксы, поменяться всё может в ночь по хотению PR - отдела - прямое взаимодействие с заказчиком) - дорого.

Со самому ТЗ:
Нужен ли интерактивный прототип? если нужен, то в ТЗ только ссылка на него, вырезать отдельные экраны в ТЗ не рекомендую.

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