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

Поскольку я подвёргся цензуре, повторю в социально приемлемой форме:

Засуньте свои непрошеные советы подальше.

При этом почему вы не рассматриваете ТЗ как инструмент сдерживания "буйной фантазии" заказчика? 

Это имеет смысл, если нет более простых способов сдерживания буйной фантазии. Но эта тема за пределами доклада.

Ссылка на доклад: https://www.youtube.com/watch?v=zVtTrXcHH2M

Однако у меня все ходы записаны. Вопросы есть, ответов только нет.

Ну, тогда на правах свирепого оффтопа... (может, перенесет кто куда надо?)

1. Является ли ГОСТ методологией разработки?

Зависит от того, как определить "методологию". Мое мнение - да, является. Рамочной. Поскольку определяет:
1. Что должно быть сделано.
2. В какой последовательности.
3. Как должно сдаваться.
4. Как должны выстраиваться формальные отношения между сторонами разработки.

Понятно, что это не везде прямым текстом, но если сказано, что документ должен содержать а), б) и в), то довольно очевидно, какие работы для этого нужно выполнить.

2. Когда следует применять ГОСТ 34?
Когда:
а) это прямо предписано контрактом,
б) нужно подстелить соломки ввиду невнятных перспектив проекта,
в) умеете это делать,
г) в иных случаях.

3. Когда не следует применять ГОСТ 34

В целом - не следует, когда без него получается лучше, чем с ним.

Например, относительным противопоказанием применения ГОСТ 34 являются проекты итерационного характера. Но не все, а те, для которых характерно появление совершенно новых требований от итерации к итерации (не то, что нельзя, а просто сильно неудобно).

4. В каких случаях ГОСТ 34 обязателен к исполнению?

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

5. На каких этапах жизненного цикла разрабатываются требования по ГОСТ 34?

О каких именно требованиях идет речь? Если в широкой трактовке, то на всех.

С 1 по 6 стадии по ГОСТ 34.601-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ" - достаточно очевидно.
http://rugost.com/index.php?option=com_content&view=article&id=95:gost-34-601-90-avtomatizirovannye-sistemy-stadii-sozdaniya&catid=22&Itemid=53

На 7 стадии:
7.6. Проведение предварительных испытаний.
7.7. Проведение опытной эксплуатации.
7.8. Проведение приёмочных испытаний,
могут возникнуть требования, которые необходимо реализовать в системе или документации для ее приемки.

На последней стадии "Сопровождение АС" появляются требования на последующее развитие.

6. В каких документах по ГОСТ 34 содержатся требования?

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

Полагаю обсуждение содержательной части более - менее закончено. Можно перейти к оформительской части.

-- Построение ------------------------------------------
Как и Леонид я часто строю такие схемы в голове.
При повышенной сложности - стикеры или тетрадь в клетку А4.
Изредка доску или флипчарт.

-- Фиксация ------------------------------------------
Но в какой то момент нужна фиксация результата. Почерк у меня "не очень", и сканирование не очень помогает. Почти всегда под рукой есть пауерпоинт. В нем чаще всего я фиксирую простые диаграммы. При необходимости и IDEF, и стейт, и прочие. Так быстрее, проще и эффективнее. Иногда использую визио. Приведенная в статье диаграмма быстрее всего строится во флаинглоджик. Набор выразительных средств там достаточно куцый и на освоение уходят минуты. Минимум возможностей - очень высокая скорость фиксации готового результата. Заметим, фиксации готового результата с наименьшими потерями времени и мыслетоплива.

Что касается пользы от специализированных инструментов, то она сомнительна. Продавцы гербалайфа пакета Rational много лет утверждали, что только покупка их продуктов сделает ваши волосы длинными и шелковистыми проекты успешными. Типа, если аналитик не использует Rational Rose, то он и не аналитик вовсе. "Господа, его вообще сюда пустил?".

По этой теме у Григория есть несколько отличных статей:
"Убийцы времени" https://www.greesha.ru/articles/%D1%83%D0%B1%D0%B8%D0%B9%D1%86%D1%8B-%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8/
"Простые инструменты" https://www.greesha.ru/articles/%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%8B%D0%B5-%D0%B8%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B/
И особенно: "Семь смертных грехов аналитика. Gula" https://www.greesha.ru/livejournal/%D1%81%D0%B5%D0%BC%D1%8C-%D1%81%D0%BC%D0%B5%D1%80%D1%82%D0%BD%D1%8B%D1%85-%D0%B3%D1%80%D0%B5%D1%85%D0%BE%D0%B2-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0-gula/


-- Презентация ------------------------------------------
Что касается совместного обсуждения большой диаграммы (100+ элементов 200+ связей).
* Лист ватмана.
* Напечатать множество листов и склеить в лист А2 - А0, если нет большого принтера.
* Возможно, когда нибудь в переговорке станет нормой монитор (телевизор) 60+ дюймов, с сенсорным экраном, развернутый вертикально.

Есть еще неплохой вариант продемонстрированный Эли Шрагенхаймом в книге "Управленческие дилеммы"

-- Сложности восприятия ------------------------------------------
Дюжину лет назад тестировщики моего отдела достаточно свободно работали со схемой БД склеенной из 20 листов А4. Это примерно 150-200 таблиц. Про программистов и говорить нечего. Они ее читали "на лету".

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

Я прочитал это так: "Для меня, Леонида, работа с такими диаграммами не представляет труда, для программистов представляет."

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

7. Какие документы ГОСТ 34 являются самыми важными?

С какой точки зрения? Если с формальной точки зрения (получения денег за выполненные работы) - то связка ТЗ + Программа и методика испытаний + отчасти протокол испытаний. Это самые попоприкрывательные документы, при разработке и "реализации" которых требуется максимум внимания.

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

8. Какие документы из ГОСТ 34 являются самыми полезными?

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

9. Что нужно изучить, прежде чем браться за разработку ТЗ по ГОСТ 34?

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

10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

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

11. Обязательно ли заполнять все разделы ТЗ, перечисленные  в ГОСТ 34?

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

12. Какие ошибки чаще всего совершают аналитики, использующие ГОСТ 34?

Я в растерянности. Меня только что попросили рассказать самые смешные анекдоты, которые я знаю. А в голову ничего не идет, хоть тресни.

Ну, например, из любимого. Каждый второй путается с "объектом автоматизации". Немудрено, поскольку явного определения, что это такое, ГОСТ 34 не содержит. Отсюда у многих получается, что объект автоматизации - это процессы, которые надлежит автоматизировать.
Однако, если посмотреть внимательнее, можно заметить:
а) в том же ТЗ "3) создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;"
б) в Пояснительной записке "7) решения по комплексу технических средств, его размещению на объекте;" или "4) мероприятия по изменению объекта автоматизации;"
в) в Общем описании системы "4) описание взаимосвязей АС с подразделениями объекта автоматизации."

Помятую о том, что АС - это не только ПО, но также и ИТ-инфраструктура, которая должна быть где-то развернута, и люди, которые должны быть где-то рассажены, напрашивается единственный вывод:

Объект автоматизации - это ГДЕ происходит автоматизация.

Чаще всего объект автоматизации представляют в одном из двух вариантов (или их комбинацией):
а) Перечень орг.подразделений заказчика: "в подразделениях, ведущих архивную работу"
б) Перечень адресов: "в здании Мособл... по адресу г.Москва, ул...,"

Что касается пользы от специализированных инструментов, то она сомнительна.

Аминь.

Дюжину лет назад тестировщики моего отдела достаточно свободно работали со схемой БД склеенной из 20 листов А4. Это примерно 150-200 таблиц. Про программистов и говорить нечего. Они ее читали "на лету".

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

Я прочитал это так: "Для меня, Леонида, работа с такими диаграммами не представляет труда, для программистов представляет."

Правильнее будет "не представляет сложности, требует только заметного количества труда"

Но я тоже заметил, за последние десяток лет восприятие больших диаграмм ухудшилось.

Как и больших документов.

Что касается пользы от специализированных инструментов, то она сомнительна. Продавцы гербалайфа пакета Rational много лет утверждали, что только покупка их продуктов сделает ваши волосы длинными и шелковистыми проекты успешными. Типа, если аналитик не использует Rational Rose, то он и не аналитик вовсе. "Господа, его вообще сюда пустил?".

Ну я бы не бы столь категоричен. Эпоха системного анализа началась исключительно благодаря развитию компьютерных систем и технологий. Rational и им подобные штуки делают упор на визуальные модели. Возможно в этом их промах.

10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

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

Коротко она пересказывается, например, здесь: http://foranalysts.blogspot.ru/2011/08/blog-post_17.html
Картинка в статье - из книги Вигерса "Разработка требований к программному обеспечению".

Теоретически - соглашусь. Более-менее грамотно отрисованное вполне можно читать, было бы время. Но практически, схемы из 200+ элементов и 500+ связей не читают даже те технари, для которых они предназначены. Проверял на моделях БД неоднократно. Пугается такого клубка человек, и уходит в оборону.

Правильно делают, что не читают. Вместе с тем 200+ элементов - это фактически учебная задача. ER простенькой системы  - это 500-700 сущностей, более-менее детальное описание логистического процесса 500 и более активностей. В САП около 100 000 таблиц
 
Больших слонов едят по частям - сделать что-то полезное с таким количеством элементов и их связей человек с нормальной психикой просто не в состоянии. Поэтому у аналитика и есть инструментарий с репозитарием , который позволяет работать не со всей моделей на ватмане, а с отдельной проекцией, помещая в фокус именно ту часть модели, которая необходима для принятия решения.
 

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

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

Коротко она пересказывается, например, здесь: http://foranalysts.blogspot.ru/2011/08/blog-post_17.html
Картинка в статье - из книги Вигерса "Разработка требований к программному обеспечению".

Значит, будем плясать от этой ссылки.

10. Как артефакты ГОСТ 34 соотносятся с классификацией требований Вигерса?

а) Предпроектная документация (отчеты об обследовании*, ТЗ) может содержать все виды требований, от "зачем это надо вообще" до "тут нужно кодить исключительно на турбопаскале, потому что у заказчика лицензий к нему немеряно и люди натасканы".

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

Что касается ТЗ, то хоть п.1.4 ГОСТ 34.602 провозглашает "Задаваемые в ТЗ на АС требования не должны ограничивать разработчика системы в поиске и реализации наиболее эффективных технических, технико-экономических и других решений", но как правило, искать решения нужно в отведенных границах. Или вокруг неких констант, забитых гвоздями низкоуровневых требований. Например, если одна из основных задач создаваемой системы - служить источников данных для другой системы, которая умеет переваривать только csv-файлы, то самые замечательные и современные xml-технологии будут неактуальны.

В целом, в предпроектной документации акцент смещен в сторону высокоуровневых требований.

б) Проектная документация.
А в проектной наоборот: хоть она и касается высокоуровневых требований и задач, основной акцент делается на том, КАК (за счет каких своих свойств) разрабатываемая система будет их выполнять, и что для этого потребуется.

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

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

Артефакты ГОСТ 34 соотносятся с артефактами Вигерса приблизительно так же, как соотносятся АС и ПО.

Правильно делают, что не читают. Вместе с тем 200+ элементов - это фактически учебная задача. ...
 
Больших слонов едят по частям - сделать что-то полезное с таким количеством элементов и их связей человек с нормальной психикой просто не в состоянии.

А это и есть часть большого слона. В чем же правы те, кто отказывается есть, что дают?

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

 

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

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

Ничего не имею против осознанности. А вот попа все-таки нужна. Без попы нет усидчивости, а без усидчивости никакая осознанность не поможет съесть кусок слона на 200+ элементов.

Артефакты ГОСТ 34 соотносятся с артефактами Вигерса приблизительно так же, как соотносятся АС и ПО.

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

Дисклеймер: вывод о вигерсовом подходе сделан на основании предоставленный выше ссылки и может не соответствовать фактическому положению вещей.

Артефакты же ГОСТа перпендикулярны вигерсовским, поскольку ГОСТ иначе смотрит на предстоящие работы, применяет другую классификацию и, как следствие,  рекомендует иную расстановку акцентов.

Можно попунктно сравнить состав ГОСТ 19.201-78, IEEE 830-1998 и SRS Вигерса чтобы увидеть, что разница между ними чисто эволюционная, а не "перпендикулярная", что бы это ни значило.