Пишем конкурсное ТЗ по ГОСТ 34. Часть 1

Сразу сделаем оговорку - конкурсная документация никакими ГОСТами не регламентируется, и никаких требований к оформлению конкурсного ТЗ по 34-му ГОСТу нигде нет. То, что большинство конкурсных ТЗ пишутся "по мотивам" ГОСТ 34, скорее всего очевидно обусловлено бюрократической инерцией. В Российских дочках иностранных компаний, например, обычно используют свои корпоративные шаблоны RFP и RFI не имеющие ничего общего с ГОСТ.

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

Причина такой нестрогости не обязательно в квалификации авторов ТЗ. Часто проблема в том, что им просто не хватает информации. На этапе подготовки конкурса как правило известны только самые общие требования к создаваемой системе, их с натяжкой хватает на более-менее внятное описание объекта автоматизации (решаемых задач) и на избранные подразделы из "Требований к системе в целом".

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

В такой ситуации можно и нужно отнестись к ГОСТу прагматично и творчески.

Также важно учитывать, что конкурсное ТЗ как правило делается в виде приложения к "основному" документу конкурсной документации, в котором уже указаны все нетехнические подробности. Это дает основания исключить из ТЗ раздел "Общие сведения", а иногда даже "Назначение и цели создания…".

Смотрим на структуру ТЗ (см. ГОСТ 34.602-89) и безжалостно отсекаем то, без чего в принципе можно обойтись:

Раздел №	Содержание ТЗ по ГОСТ 34.602	Включать в ТЗ?	Комментарии
1	Общие сведения	-	Как правило указываются в основном документе конкурсной документации
1.1	Полное наименование системы и ее условное обозначение	-
1.2	Шифр темы, номер договора	-
1.3	Наименование предприятий разработчика и заказчика	-
1.4	Перечень документов, на основании которых создается Система	-
1.5	Плановые сроки начала, и окончания работы по созданию системы	-
1.6	Сведения об источниках и порядке финансирования работ	-
1.7	Порядок оформления и предъявления Заказчику результатов работ	-
1.8	Перечень нормативно-технических документов и методических материалов, использованных при разработке технического задания	-
2	Назначение и цели создания системы	+	Можно не делить на подпункты
2.1	Назначение системы	+-
2.2	Цели создания системы	+-
3	Характеристика объектов автоматизации	+
3.1	Краткие сведения об объекте автоматизации	+
3.2	Условия эксплуатации системы	+-
4	Требования к системе	+
4.1	Требования к системе в целом	+
4.1.1	Требования к структуре и функционированию системы	+
4.1.2	Требования к численности и квалификации персонала системы и режиму его работы	-
4.1.3	Показатели назначения	+-	Срок хранения данных, число пользователей, время отклика, масштабирование, ...
4.1.4	Требования к надежности	+-	Можно совместить с разделом "Показатели назначения"
4.1.5	Требования к безопасности	-
4.1.6	Требования к эргономике и технической эстетике	-
4.1.7	Требования к транспортабельности для подвижных систем	-
4.1.8	Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы	-
4.1.9	Требования к защите информации от несанкционированного доступа	+-	Как правило, требуется
4.1.10	Требования по сохранности информации при авариях	+-	«Резервное копирование, время восстановления данных,…» Можно перенести в раздел "Требования к надежности" или "Показатели назначения"
4.1.11	Требования к защите от влияния внешних воздействий	-
4.1.12	Требования к патентной чистоте	+-	Зависит от специфики конкурса. Может быть описано в основном документе конкурсной документации
4.1.13	Требования по стандартизации и унификации	-
4.1.14	Дополнительные требования	-
4.2	Требования к функциям (задачам), выполняемым системой	+	Здесь описываем требования к отдельным подсистемам и(или) компонентам. Состав подсистем описан в разделе "Требования к структуре и функционированию системы"
4.3	Требования к видам обеспечения	+-
4.3.1	Требования к математическому обеспечению	-
4.3.2	Требования к информационному обеспечению	-
4.3.3	Требования к лингвистическому обеспечению	-
4.3.4	Требования к программному обеспечению	+-	Ограничения по выбору платформ, ссылки на нормативку с ограничениями в части ИБ и т.п.
4.3.5	Требования к техническому обеспечению	+-
4.3.6	Требования к метрологическому обеспечению	-
4.3.7	Требования к организационному обеспечению	-
4.3.8	Требования к методическому обеспечению	-
5	Состав и содержание работ по созданию системы	+	Можно обойтись таблицей с этапами, результатами и сроками.
5.1	Стадии и этапы создания Системы.	+
5.2	Порядок проведения экспертизы технической документации	-
5.3	Программа работ, направленных на обеспечение требуемого уровня надежности разрабатываемое системы	-
5.4	Перечень работ по метрологическому обеспечению	-
6	Порядок контроля и приемки системы	-
6.1	Виды, состав, объем и методы испытаний	-
6.2	Общие требования к приемке работ по стадиям	-
6.3	Статус приемочной комиссии	-
7	Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие	-	Может быть описано в разделе "Состав и содержание работ…"
7.1	Перечень мероприятий	-
8	Требования к документированию	+-	Может быть описано в разделе "Состав и содержание работ…" вместе с составом выходных документов
8.1	Виды, комплектность и обозначения документов	-
9	ИСТОЧНИКИ РАЗРАБОТКИ	-

Мы уменьшили число разделов в пять раз!

Конкурсное ТЗимеет свои особенности, ведь его цель не только донести до участников требования к предмету конкурса, но и помочь конкурсной комиссии оценить соответствие каждого из полученных предложений этим требованиям.Для этого требования должны быть структурированы в соответствии с их важностью (приоритезированы): каждому требованию должен быть присвоен уникальный код и приоритет. Удобно свести требования в общую таблицу или в группу таблиц с одинаковой струкетурой, например с такой:

№ п/п

Группа

требований

Подгруппа

требований

Требование

Приоритет

В качестве примера приведем таблицу приоритетов, которая встречалась автору в нескольких конкурсах Сбербанка:

№ п/п	Приотритет	Описание
1.	Критичный	Без реализации такого требования система не может быть использована
2.	Высокий	Без реализации такого требования система может быть использована с ограничениями, требование должно быть реализовано в ходе опытной эксплуатации
3.	Средний	Без реализации такого требования система может быть использована с ограничениями
4.	Низкий	Требование желательно, но не критично

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