Я прямо вижу, как в этом топике на глазах вырастает готовый раздел "FAQ по ГОСТ 34" для сайта.

Я прямо вижу, как в этом топике на глазах вырастает готовый раздел "FAQ по ГОСТ 34" для сайта.

Будут появляться "Q", может и наберется достаточно материала.

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

Предлагаю в этой теме общими усилиями сформировать список вопросов по ГОСТ 34, а потом сделать из них FAQ.

У меня получился такой список. Критикуйте, предлагайте свои вопросы и более правильные формулировки.

Является ли ГОСТ 34 методологией разработки?
Когда следует использовать ГОСТ 34?
Когда не следует использовать ГОСТ 34?
В каких случаях ГОСТ 34 обязателен к исполнению?
На каких этапах жизненного цикла разрабатываются требования по ГОСТ 34?
В каких документах по ГОСТ 34 содержатся требования?
Какие документы ГОСТ 34 являются самыми важными?
Какие документы ГОСТ 34 являются самыми полезными?
Что нужно изучить, прежде чем браться за разработку ТЗ по ГОСТ 34?
Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?
Обязательно ли заполнять все разделы ТЗ, перечисленные в ГОСТ 34?
Какие ошибки чаще всего совершают аналитики, использующие ГОСТ 34?

Кто и зачем разработал ГОСТ 34?
Представители каких профессий должны создавать отдельные документы ГОСТ 34?
В чём особенности и преимущества ГОСТ 34 в сравнении с международными стандартами и вендорскими процессными библиотеками?
В чём устарел ГОСТ 34?
Почему не появилось нового поколения российских стандартов, заменяющих ГОСТ 34?

Спасибо всем, что помогаете разобраться в таком нелёгком деле, как работа по ГОСТ34

Добавлю от себя список некоторых вопросов, с которыми сталкивался в процессе:
- Возможно ли в рамках разработки документации часть написать по ГОСТ34, а часть допустим по 19? Т.е. ТЗ пишем по 34, а руководство оператора по 19?
- Возможно ли оставить пакет документов без единого ТЗ, сразу оформить несколько ЧТЗ на каждую из подсистем?
- Как правильно отформатировать документ(ы)? Шрифт, поля, интервалы и тд.
- Какие из документов, описанных в 34201 являются СТРОГО обязательными?
- Насколько подробно необходимо описывать требования именно в ТЗ? И как понять, что необходимый уровень точности уже достигнут. (Здесь будем исходить из того, что подробные ФТ пишутся все-таки на стадии ТП, а в ТЗ пишутся требования верхнего уровня).

Могу добавить еще вопросы относительно ПМИ, если это пойдет в эту же тему.

Я бы добавил, то о чем говорил уважаемый greesha в соседнем посте.
Сравнительный глоссарий ГОСТ 34 и других стандартов методологий (Не только с Вигерсом но и с другими)  по разработке ПО/ИС

Предлагаю в этой теме общими усилиями сформировать список вопросов по ГОСТ 34, а потом сделать из них FAQ.

Перечень вопросов для FAQ - это хорошо. А как видишь работу с ответами? (пока предложено только формировать перечень вопросов).

Спасибо всем, что помогаете разобраться в таком нелёгком деле, как работа по ГОСТ34

В продолжение помощи...

- Возможно ли в рамках разработки документации часть написать по ГОСТ34, а часть допустим по 19? Т.е. ТЗ пишем по 34, а руководство оператора по 19?

Да. Но такое бывает очень редко (как и использование 19-го вообще).

- Возможно ли оставить пакет документов без единого ТЗ, сразу оформить несколько ЧТЗ на каждую из подсистем?

Не слышал о таком. Нормальный подход в таком случае - сделать для всех ЧТЗ одно ТЗ-папку, в котором будут обозначены какие-то общие вопросы, а в остальном - ссылки на ЧТЗ.

- Как правильно отформатировать документ(ы)? Шрифт, поля, интервалы и тд.

Нет единого мнения. ГОСТ 2.105, который как раз об этом, разрабатывался для печатных машинок и "чертежного шрифта", которым красиво писали на ватмане от руки. Сейчас никаких проблем не вызывают ТЗ, оформленные 14 или 12 размером с полуторным интервалом. Шрифт - в принципе, что удобно. Чаще всего попадался Times New Roman. Вообще, ГОСТ 2.105 иногда оказывается довольно важным при согласовании ТЗ с заказчиком. При наличии у последнего свирепого нормоконтроля, вернуть документ могут просто по совокупности нарушений правил оформления (точки не там, списки нумерованные, а не маркированные, абзацные отступы не те и т.п.). К счастью, такое встречается редко.

Есть смысл поискать на форумах техписов: наверняка ГОСТовые шаблоны стилей для Ворда (а то и рыбы ТЗ) водятся в изобилии.

- Какие из документов, описанных в 34201 являются СТРОГО обязательными?

Думаю, это не очень корректная постановка вопроса. Обязательность диктуется ситуацией. Минимальный набор, который я видел, это ТЗ, Пояснительная записка к техпроекту, руководство пользователя и ПМИ.

- Насколько подробно необходимо описывать требования именно в ТЗ? И как понять, что необходимый уровень точности уже достигнут. (Здесь будем исходить из того, что подробные ФТ пишутся все-таки на стадии ТП, а в ТЗ пишутся требования верхнего уровня).

Это зависит. Невысокая детализация применяется тогда, когда:
- есть налаженные отношения с заказчиком;
- нет особо времени детализировать;
- есть сомнения в корректности и актуальности частных требований (когда кроме нужного придется делать еще и то, что поспешили навалить в ТЗ). Надо отметить, что в ГОСТ 34.602 (ТЗ) предусмотрен механизм внесения изменений, но на практике он применяется достаточно редко. Хлопотно это, да и чревато повышенным вниманием ревизоров.
Детализируют по максимуму тогда, когда:
- есть высокие риски того, что заказчик постарается "нагнуть" исполнителя на куда большее, чем оговаривалось изначально (пользуясь размытыми формулировками).
- есть возможность тщательно разобраться и "от души" разработать требования;
- вероятность значительного изменения требований невысокая (относительно небольшие сроки, высокая стабильность предметной области).

На практике народ лавирует между этими полюсами по обстоятельствам.

Могу добавить еще вопросы относительно ПМИ, если это пойдет в эту же тему.

Если составлять ЧАВО по ГОСТ 34 вообще, то будет в тему. На мой взгляд, связка ТЗ+ПМИ имеет наибольший "вес" при работе по ГОСТ 34.

Перечень вопросов для FAQ - это хорошо. А как видишь работу с ответами? (пока предложено только формировать перечень вопросов).

Попросим ответить экспертов. Одного мы уже знаем.

Попросим ответить экспертов. Одного мы уже знаем.

А... Ну, как соберетесь, меня растолкайте. Я тоже хочу экспертов послушать. А то и сам что скажу.

Еще вопросики:
* Можно ли use-case запихать в ГОСТ 34 и куда?
* Чем отличается ГОСТ 34 от 19?

Еще вопросики:
* Можно ли use-case запихать в ГОСТ 34 и куда?

В программу и методику испытаний отлично запихивается. Но это уже стадия рабочего проектирования (для IT - написания кода). Из документов технического проекта для use-case наверно подойдёт "Описание автоматизируемых функций".

* Чем отличается ГОСТ 34 от 19?

ГОСТ 19 - стандарт для разработки программного обеспечения. Результат разработки по 19 ГОСТу - код и документация к нему.
ГОСТ 34 - для разработки автоматизированных систем. Автоматизированная система кроме программного обеспечения, включает в себя техническое обеспечение и персонал. Результат разработки по 34 ГОСТу - автоматизация определенного рабочего процесса. Т. е. ПО не только написано и задокументировано, но и установлено, при необходимости закуплено необходимое оборудование, протянуты сети, пользователи обучены, распределены роли их работы в системе, написаны инструкции для каждой роли и т.д.

В программу и методику испытаний отлично запихивается. Но это уже стадия рабочего проектирования (для IT - написания кода). Из документов технического проекта для use-case наверно подойдёт "Описание автоматизируемых функций".

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

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

ГОСТ 19 - стандарт для разработки программного обеспечения. Результат разработки по 19 ГОСТу - код и документация к нему.
ГОСТ 34 - для разработки автоматизированных систем. Автоматизированная система кроме программного обеспечения, включает в себя техническое обеспечение и персонал. Результат разработки по 34 ГОСТу - автоматизация определенного рабочего процесса.

1. Правильно ли я понимаю, что для проектов внедрения АС, ту часть которая про ПО можно описать, например по 19 ГОСТу (ну или формате функциональной спецификации), а все что относится к его внедрению как системы по 34?
Если это так, то возможно ли обосновать такой подход, опираясь на сам ГОСТ?
2. В общепринятой терминологии, в том числе при написании проектных документов, принято любой программный продукт называть системой, тогда получается, что даже если ты продаешь заказчику ПО без внедрения, но в договоре обозвали это системой, то формально необходимо описывать ее с применением ГОСТ 34 (Если, в том же договоре, допустим будет прописано, что вся сопровождающая документация должна быть подготовлена на основе соответствующих ГОСТов)?

1. Правильно ли я понимаю, что для проектов внедрения АС, ту часть которая про ПО можно описать, например по 19 ГОСТу (ну или формате функциональной спецификации), а все что относится к его внедрению как системы по 34?
Если это так, то возможно ли обосновать такой подход, опираясь на сам ГОСТ?

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

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

Что, как и насколько строго нужно документировать, сильно зависит от заказчика, и согласовывать это нужно с ним (и по возможности фиксировать в договоре и ТЗ всё, что согласовали). Я никогда не встречалась с формулировкой "на основе соответствующих ГОСТов" (правда, у меня и опыт не очень большой). Обычно указываются конкретные номера ГОСТов, которых нужно придерживаться, часто и названия документов из указанных гостов.