Инженерия требований

ГОСТы на автоматизированные системы

Коротко ГОСТ — государственный стандарт. Многие ГОСТы появились ещё в Советском Союзе и до сих пор действуют в России и ряде других стран СНГ. На ИТ-проектах для государственного сектора и крупных предприятий от вас могут потребовать техническое задание «по ГОСТ 34». На этой странице — три стандарта, которые называют чаще всего, и их связь с документом «Видение» и SRS.

По материалам: Ю. А. Маглинец, «Анализ требований к информационным системам», лекции 4 и 6; ГОСТ 34.601-90; ГОСТ 34.602-89; ГОСТ 19.201-78.

На этой странице

Главные идеи#

Что такое ГОСТ 34 и ГОСТ 19#

Аналитику важны две серии стандартов:

  • ГОСТ 34 — «Комплекс стандартов на автоматизированные системы». В этих стандартах автоматизированная система (АС) включает не только технические и программные средства, но и персонал, который с ней работает, поэтому стандарты охватывают людей и организацию, а не только код.
  • ГОСТ 19 — более старая серия стандартов на программную документацию, Единая система программной документации (ЕСПД).

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

ГОСТ 19.201-78: общий стандарт на техническое задание#

Этот более ранний стандарт устанавливает содержание и оформление технического задания (ТЗ) на разработку программы. Маглинец описывает ГОСТ 34.602-89 как более подробный вариант той же идеи, приспособленный к автоматизированным системам.

ГОСТ 34.601-90: стадии создания и концепция с вариантами#

Этот стандарт определяет стадии создания автоматизированной системы. После стадии «Формирование требований к АС» в нём предусмотрена отдельная стадия «Разработка концепции АС». Её этапы: изучение объекта; проведение необходимых научно-исследовательских работ; разработка вариантов концепции АС; оформление отчёта о выполненной работе.

Отличительная черта — концепция должна предлагать несколько вариантов. Каждый вариант оценивают по нужным ресурсам и обеспечиваемой функциональности, с его преимуществами и недостатками. Концепция также содержит оценки качества, условия приёмки и ожидаемый эффект, а отчёт обосновывает рекомендуемый вариант. Маглинец объясняет логику: заказчику трудно придумать видение системы с нуля, но выбрать из обоснованных вариантов он может хорошо. Большинство западных методологий, например RUP и MSF, вместо этого дают единственный документ о видении системы.

ГОСТ 34.602-89: техническое задание на создание автоматизированной системы#

ТЗ на АС состоит из девяти основных разделов; ниже — их краткое содержание:

  1. «Общие сведения»: стороны, их реквизиты и финансирование.
  2. «Назначение и цели создания (развития) системы»: какие показатели объекта автоматизации должна улучшить система и по каким критериям будут оценивать достижение целей. Маглинец отмечает, что к этому разделу часто относятся формально, хотя именно в нём место бизнес-требованиям.
  3. «Характеристика объектов автоматизации»: организационная структура и структура управления, площадки и филиалы.
  4. «Требования к системе» (см. ниже).
  5. «Состав и содержание работ по созданию системы»: методология, стадии и этапы.
  6. «Порядок контроля и приёмки системы»: роли заказчика и разработчика в испытаниях, сценарии испытаний, критерии приёмки.
  7. «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие»: подбор персонала, обучение и организационные изменения, которые нужны до запуска.
  8. «Требования к документированию».
  9. «Источники разработки»: имеющиеся документы, на которые опирается работа.

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

Три класса требований#

Раздел 4 делит требования на три класса:

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

Соответствие западным документам#

Раздел ГОСТ 34.602-89 Ближайший западный аналог
2. Назначение и цели создания (развития) системы Бизнес-цели и метрики успеха в документе «Видение» или в документе концепции и границ
3. Характеристика объектов автоматизации Бизнес-контекст, профили заинтересованных сторон, текущее состояние
4. Требования к системе в целом Атрибуты качества и ограничения в SRS
4. Требования к функциям (задачам) Функциональные требования или варианты использования
4. Требования к видам обеспечения Отчасти ограничения на проектные решения; отчасти прямого аналога нет
6. Порядок контроля и приёмки системы Критерии приёмки и план тестирования, обычно вне SRS
7. Подготовка объекта автоматизации к вводу системы в действие Переходные требования

По оценке Маглинца, стандарт остаётся содержательно здравым, потому что не привязан к технологиям, и добавляет то, чего нет в SRS и документе «Видение»: явную приёмку, подготовку организации и виды обеспечения.

Как применять#

  1. Уточните требование. Проверьте, какие стандарты и в какой редакции названы в договоре и есть ли у заказчика собственный шаблон.
  2. Отнеситесь к разделу 2 всерьёз. Запишите в нём измеримые бизнес-цели и критерии успеха.
  3. Используйте результаты своего анализа. Контекст и заинтересованные стороны идут в раздел 3, функциональные требования — в требования к функциям (задачам) раздела 4 (по подсистемам), атрибуты качества — в требования к системе в целом.
  4. Задайте для каждой функции требования к качеству и критерии отказов, а не только название.
  5. Договоритесь о приёмке заранее. Подготовьте раздел 6 вместе с заказчиком: от него зависит, когда работа считается выполненной.
  6. Спланируйте организационные изменения в разделе 7. Обучение и персонал по ГОСТ — часть системы.
  7. На стадии концепции подготовьте два-три варианта и обоснованно рекомендуйте один. Эта привычка полезна и за пределами проектов по ГОСТ.

Подводные камни#

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

Источники и что почитать#

  • Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 4 (стадия разработки концепции по ГОСТ 34.601-90) и лекция 6 (ГОСТ 34.602-89 и ГОСТ 19.201-78).
  • ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания».
  • ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы».
  • ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению».