Коллеги, здравствуйте.

В рамках одного из проектов столкнулась с необходимостью согласования документа под названием "Проект пользовательского интерфейса". Документация, разрабатываемая в рамках проекта должна оформляться в соответствии с ГОСТ. Подскажите, пожалуйста, как лучше структурировать документ?
Сейчас за основу взяла некий собственный шаблон. Но может кто-то поделиться опытом интеграции мокапов в гостовский документ

100 клиентов и 100 шаблонов

Ну я как бы и не пытаюсь спорить с этим тезисом! И свою проблему на текущий момент решила  "заглушкой". Просто хочется улучшить качество, послушав мысли умных людей

Качество чего хотите улучшить? За счет шаблона из ГОСТ?

Ой Я не очень форумный человек, но тут, как настоящий консультант, отвечу историей и вопросом

Был у нас заказчик, который все оформлял по ГОСТу. И говорил об этом открыто и гордо, высоко подняв при этом голову. Ну ГОСТ и ГОСТ. Дошло дело до обследования. Прошу: Принесите ТЗ по ГОСТу, а я посмотрю по какому же ГОСТу вы пишите - по 19му или по 34му. Приносят бумажку на 3 странички... из которых одна титулка, а вторая оглавление и аннотация...

Я в шоке. Спрашиваю: это что? ТЗ по ГОСТу... Я говорю, что это очень интересно, но я ожидал несколько большего.

Вобщем, после разбирательств выяснилось, что имелся ввиду ГОСТ 2.105-95 "Единая система конструкторской документации. Общие требования к текстовым документам". Смакуем. не ГОСТ19 на ПО, не ГОСТ34 на АС, а ГОСТ на оформление

Теперь вопрос: что вы имеете ввиду "Документация, разрабатываемая в рамках проекта должна оформляться в соответствии с ГОСТ"? А то мало ли... наш заказчик был полугоскомпанией и такой перл

А ведь вопрос в точку. Действительно, мы часто говорим : "оформлено по ГОСТ", а что имеем в виду ?

"Проект пользовательского интерфейса". Документация, разрабатываемая в рамках проекта должна оформляться в соответствии с ГОСТ.

Если уж заговорили о ГОСТ, разве есть такой документ как Проект?

Да и вопрос все-таки оформить или структурировать?

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

Как писали, есть два уровня требований по ГОСТ. Первый - просто на оформление текстов. Второй - на состав документации и содержание отдельных разделов. При этом, по опыту, оба уровня требований принимающая сторона трактует достаточно произвольно. И бывает, когда документы нормально проходящие через одного принимающего, не принимались другим. А доказывать "ГОСТ это позволяет" - вредно, потому что этим ты доказываешь, что знаешь ГОСТ лучше принимающего, и даже если ты это сделаешь - он будет дальше придираться. Таким образом, вопрос в том, что есть ГОСТ с точки зрения принимающей стороны. Это надо выяснять, задавая конкретные вопросы и предлагая варианты более-менее в рамках ГОСТа (который в принципе стоит прочитать по диагонали).

Ну, по ГОСТу все же есть Технический проект, Эскизный проект. Но если говорят "оформлять" по ГОСТу, то я почему-то на 90% уверен, что это именно ГОСТ 2.105-95

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

Как писали, есть два уровня требований по ГОСТ. Первый - просто на оформление текстов. Второй - на состав документации и содержание отдельных разделов. При этом, по опыту, оба уровня требований принимающая сторона трактует достаточно произвольно. И бывает, когда документы нормально проходящие через одного принимающего, не принимались другим. А доказывать "ГОСТ это позволяет" - вредно, потому что этим ты доказываешь, что знаешь ГОСТ лучше принимающего, и даже если ты это сделаешь - он будет дальше придираться. Таким образом, вопрос в том, что есть ГОСТ с точки зрения принимающей стороны. Это надо выяснять, задавая конкретные вопросы и предлагая варианты более-менее в рамках ГОСТа (который в принципе стоит прочитать по диагонали).

Могу подписаться под каждым словом

Качество чего хотите улучшить? За счет шаблона из ГОСТ?

Я просто пытаюсь сделать свою работу хорошо в тех условиях, в которые меня поставили. Если у меня нет выбора и надо использовать только ГОСТ, это, как мне кажется, не повод делать что-то на недостаточно высоком уровне качества.

Если уж заговорили о ГОСТ, разве есть такой документ как Проект?

Я в данном случае привела полностью пункт ТТЗ. Не хватает только примечания о том, что документ должен быть согласован в течение такого-то времени.
Интересно именно структурирование документа. Мне раньше приходилось писать похожие вещи. В результате получался объемный документ вида: use case + мокапы к нему. Но в данном случае (госзаказчик) я не думаю, что кто-то станет читать подобные объемные вещи.

Что касается ГОСТ 2.105-95. Как бы с ГОСТ знакома и проблем с его использованием не было. Собственно он и был использован. В итоге документ получился в виде описания 3-4 основных экранных форм. Смутило меня то, что данный документ был в ТТЗ в одной куче с типичными набором документации на ПО по ГОСТ 19.  Он и еще один "Проект формата автоматизированного отчета".

Коллеги, просветите пожалуйста, что означает слово "мокап"? Это макет пользовательского интерфейса?

Да это еще друиды придумали изменять язык для упрощения
Mockups - Макет

В итоге, какой-то ясности по названной теме я так и не обнаружил. Формулирую вопросы следующим образом:
- В каком разделе ГОСТа допускается указывать требования к пользовательскому интерфейсу?
- Как этот раздел допускается назвать?
- Сами макеты GUI допускается ли оформлять в созданном разделе требований к GUI или логичнее их переместить в приложение, проставив ссылки из раздела требований к GUI?

По-третьему "макеты GUI"

Разумнее всего сделать Приложение к ТЗ, а в нем и разместить экранные формы с описанием. Если заказчик начнет прогибать на модификации этих форм, то ТЗ в целом трогать будет не надо, а достаточно будет редактировать Приложение к нему. Это упростит задачу.

Цитата  отсюда ГОСТ 34 и описание пользовательского интерфейса