+7 499 350 77 10
+7 499 322 88 70
Василий Баракин

Как разработать ТЗ по ГОСТ

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

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

  1. Об основных мифах вокруг ГОСТ 34
  2. О трудностях при разработке ТЗ по ГОСТ и способах их решения
  3. О взаимосвязи ТЗ с другими стадиями создания АС
  4. Советы по разработке ТЗ по ГОСТ
Время на чтение статьи: 15 минут
Не любите читать? Посмотрите видео.
Оглавление
Введение
Общие представления о ТЗ на создание АС
  Стадии создания АС
  Что такое ТЗ согласно ГОСТ?
  В чем мы заблуждаемся?
     Миф 1. ГОСТ определяет только оформление
     Миф 2. ГОСТ задает устаревший подход
     Миф 3. ГОСТ нужен только в госсекторе / нужен только заказчику
     Миф 4. ГОСТ громоздок и излишне детализирован
     Миф 5. ГОСТ заставляет разрабатывать ненужные документы
Фундаментальные трудности при разработке ТЗ
  Трудность 1. Исходные данные
  Трудность 2. Требования для ТЗ
  Трудность 3. Пропущенные стадии
  Трудность 4. Определение заинтересованных лиц
Советы по наполнению ТЗ
  Цели создания АС
  Режимы функционирования АС
  Формулирование требований
  Уровень детализации функций
  Границы работ
Заключение
Вопросы и ответы
Об авторе
Общие представления о ТЗ на создание АС
Стадии создания АС
Процессы создания АС и документации к ним в РФ регламентируются серией стандартов ГОСТ 34.
Обратите внимание, что в 2022 году произошло обновление некоторых стандартов 34 серии. Так, наряду со стандартом ГОСТ 34.601−90 «Автоматизированные системы. Стадии создания» появился стандарт ГОСТ Р 59 793−2021 «Автоматизированные системы. Стадии создания». Изменения в ГОСТ Р 59 793−2021 заметны в части оформления, названия документов в комплекте и некоторых нюансов, жестко регламентируемых в отдельных ситуациях, например, для требований ИБ . В составе и порядке шагов или общем смысле работ существенных различий нет.

Несмотря на то что формат нумерации изменился и технически это уже не ГОСТ 34 серии, далее под «ГОСТ 34» мы будем иметь в виду в том числе ГОСТ Р 59 793−2021. «Р» в данном случае означает, что стандарт применим на территории РФ.
Стандарт ГОСТ Р 59 793−2021 (ранее ГОСТ 34.601−90) выделяет восемь стадий создания АС.

Стадии создания АС по ГОСТ
1. Формирование требований к АС. Стадия предполагает исследование объекта автоматизации и формирование требований пользователей.
   a. Зачем нужна система?
   b. Какой эффект ожидается от внедрения системы?

2. Разработка концепции АС. Стадия предполагает изучение объекта автоматизации, разработку и выбор варианта концепции системы и оценку рисков проекта.
   a. Какие особенности есть у автоматизируемых процессов?
   b. Какие технологии и подходы можно использовать?
   c. Сколько это будет стоить?
   d. Сколько это займёт времени?

3. Техническое задание. Стадия предполагает разработку и утверждение ТЗ на АС.
   a. Какие функции система должна иметь?
   b. Каким требованиям система должна удовлетворять?
4. Эскизный проект (встречается редко). Стадия предполагает разработку предварительных проектных решений по АС и её частям: «Как предположительно должна быть устроена система?».

5. Технический проект. Стадия предполагает разработку проектных решений по АС и её частям: «Как именно должна быть устроена система?».

6. Рабочая документация. Стадия предполагает разработку рабочей документации по АС (включая эксплуатационную)
   a. Как пользователи должны работать с системой?
   b. Как нужно обслуживать систему?

7. Ввод в действие. Стадия предполагает обучение персонала, пусконаладочные работы, проведение предварительных и приёмочных испытаний, запуск в опытную эксплуатацию.

8. Сопровождение АС. Стадия предполагает выполнение гарантийного и послегарантийного обслуживания после ввода системы в эксплуатацию.
Что такое ТЗ согласно ГОСТ?
Разработка технического задания — одноименная стадия (третья по порядку) в процессе создания АС.

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

  1. Какие цели преследуются при создании системы?
  2. Какие функции должны быть реализованы в системе?
  3. В каких условиях и режимах должна работать система?
  4. Каким требованиям должна удовлетворять система с точки зрения надёжности, безопасности, производительности и т. д.
  5. Какие работы необходимо выполнить, чтобы разработать, внедрить и сопровождать систему?

Процесс разработки ТЗ регламентируется стандартом ГОСТ 34.602−2020 «Техническое задание на создание автоматизированной системы». Стандарт предлагает следующие обязательные разделы ТЗ:

  1. Общие сведения
  2. Цели и назначения создания АС
  3. Характеристика объектов автоматизации
  4. Требования к АС
  5. Состав и содержание работ по созданию АС
  6. Порядок разработки АС
  7. Порядок контроля и приёмки АС
  8. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу АС в действие
  9. Требования к документированию
  10. Источники разработки
ТЗ может быть разработано в виде нескольких документов и иметь иерархическую структуру: сначала формируется общее ТЗ на систему в целом, а далее на каждую из подсистем разрабатывается отдельное — частное техническое задание, зависящее от ТЗ на всю систему.
В чём мы заблуждаемся?
Вокруг ГОСТ 34 сложилось некоторое количество мифов и заблуждений, формирующих предвзятое отношение к ГОСТам.
Миф 1. ГОСТ определяет только оформление
На самом деле, стандарт ГОСТ 34.602−2020 не определяет визуальное оформление ТЗ. Документ определяет требования именно к составу ТЗ.
Миф 2. ГОСТ задает устаревший подход

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

Но на самом деле важна не частота обновления стандартов, а то, что они описывают общий подход к созданию АС, не зависящий от конкретных технологий. Несмотря на то что новые технологии появляются постоянно, описанный в стандартах серии 34 подход остаётся актуальным и применимым.
Миф 3. ГОСТ нужен только в госсекторе / нужен только заказчику

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

Миф 4. ГОСТ громоздок и излишне детализирован

На самом деле ГОСТ предлагает достаточно гибкий подход к разработке ТЗ на создание АС. Если внимательно читать стандарты, можно увидеть, что детальное наполнение ТЗ жёстко не регламентируется. В зависимости от особенностей автоматизируемых процессов и специфики условий функционирования АС разработчик ТЗ может:

  • Оформлять разделы ТЗ в виде приложений, вводить дополнительные разделы ТЗ, объединять или исключать подразделы ТЗ (п. 4.2)
  • Самостоятельно определять состав требований, включаемых в ТЗ (п. 4.6)

ГОСТ — всего лишь инструмент, позволяющий построить чёткую структуру ТЗ. Даже если у вас нет жёсткого требования использовать ГОСТы, на предлагаемую стандартом структуру можно ориентироваться, чтобы не упустить ничего важного.
Миф 5. ГОСТ заставляет разрабатывать ненужные документы

Все возможные виды документов, разрабатываемых на разных стадиях создания АС перечислены в стандарте ГОСТ 34.201−2020 «Виды, комплектность и обозначение документов при создании автоматизированных систем».

Всего стандарт насчитывает более 60 видов документов, но это не значит, что все они должны быть разработаны. Именно разработчик определяет, какие документы необходимы при создании той или иной системы. В большинстве случаев на всех стадиях создания АС разрабатывается не более десятка документов.
Системный анализ и Разработка требований в ИТ-проектах

Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Посмотреть программу курса
Фундаментальные трудности
при разработке ТЗ
Трудность 1. Исходные данные

Разработчики ТЗ регулярно сталкиваются с тем, что часто непонятно:

  1. Где взять исходные данные?
  2. Какими должны быть исходные данные?
  3. Зачем заказчику АС?

Как решить эту проблему? Нужно вернуться к стадии «Формирование требований к АС» и проследить её взаимосвязь с ТЗ.

Связь ТЗ с этапом 1 «Формирование требований к АС»

Цели первой стадии:

  • Сбор исходных данных
  • Выявление проблем, решение которых возможно средствами автоматизации
  • Установка ограничений (финансовых, материальных, временных, технологических, эксплуатационных и иных) создания АС

ГОСТ Р 59 793−2021 предполагает, что результатом первой стадии является отчёт об аудите (обследовании) объекта автоматизации. Именно в этом документе разработчик ТЗ может найти ответы на вопросы об исходных данных. Поэтому для качественного ТЗ важно, чтобы на момент его разработки были выявлены и задокументированы требования к АС.
Заказчик обязательно должен согласовать отчёт об аудите во избежание разногласий на дальнейших этапах.
Трудность 2. Требования для ТЗ

При разработке ТЗ бывает непонятно:

  1. Какие именно требования включать в ТЗ?
  2. Что эти требования должны описывать?

Как решить эту проблему? Здесь нужно вернуться к стадии «Разработка концепции АС» и проследить её взаимосвязь с ТЗ.

Связь ТЗ с этапом 2 «Разработка концепции АС»

На этой стадии рассматриваются:

  • Варианты технологий, которые лягут в основу системы
  • Альтернативные варианты концепции АС
  • Необходимые для реализации АС ресурсы
  • Преимущества и недостатки каждого из вариантов реализации
  • Условия эксплуатации системы
  • Эффект от реализации системы

Концепция определяет, какие именно технологии будут использоваться при создании АС. В ТЗ необходимо предъявить требования, которые будут учитывать возможности, особенности и ограничения выбранных технологий.
Трудность 3. Пропущенные стадии
Согласно логике ГОСТа, прежде чем перейти к ТЗ, необходимо иметь:

  1. Отчёт об обследовании объекта автоматизации (стадия 1, «Формирование требований к АС»)
  2. Концепцию АС (стадия 2, «Разработка концепции АС»)
Эти два документа являются основными источниками данных для ТЗ. Разработать качественное ТЗ без них — трудная задача.

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

Восемь стадий разработки АС можно объединить в более крупные группы:

  1. Формирование бюджета
  2. Проектирование и разработка
  3. Внедрение и поддержка

Укрупненные группы стадий создания АС

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

  1. Обследование и концепцию заказчик выполняет сам
  2. Обследование и концепцию никто не делает
  3. Заказчик объединяет обследование и концепцию с последующим проектированием в один лот

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

  1. Так как заказчик скорее всего не имеет нужной экспертизы, при самостоятельном выполнении работ могут быть заложены ошибки, которые «аукнутся» в будущем. Неправильно собранные исходные данные или нечёткая концепция могут привести к тому, что заказчик на выходе получит совсем не ту систему, которая нужна.

  2. Может произойти подмена понятий: заказчик может сразу поставить слишком конкретизированную задачу вместо бизнес-цели. Например, истинная цель заказчика — автоматизировать бухгалтерию, а заказчик ставит задачу «Внедрить 1С». Здесь могут закладываться предпосылки разногласий между заказчиком и исполнителем.

Что же делать, если обследование объекта автоматизации и проработка концепции не проводились или были выполнены некачественно? Есть два варианта как можно облегчить разработку ТЗ в таком случае. Оба варианта не исключают того, что ТЗ придётся переделывать, но помогут минимизировать этот риск.

  1. Если вы реализуете пилотный проект (например, для демонстрации базовой функциональности), ставьте в качестве задач пилотного проекта сбор требований и разработку концепции. После завершения пилотного проекта оформите полученные результаты в виде отчёта и отдайте на согласование заказчику.

  2. Самостоятельно придумайте недостающие исходные данные и включите их в ТЗ. Заказчику в любом случае придётся их изучить при согласовании ТЗ.
Трудность 4. Определение заинтересованных лиц

Ещё одна трудность — не совсем понятно, для кого пишется ТЗ. Разработчик ТЗ пытается понять:

  1. Кто является потребителем ТЗ?
  2. Кто является заинтересованной стороной в разработке требований?
  3. Кто будет согласовывать ТЗ?

Как решить эту проблему? Сначала нужно вспомнить, что ТЗ влияет на следующие после его разработки стадии:

  1. «Технический проект». Технический проект (5 стадия) должен содержать решения по каждому из требований ТЗ.
  2. «Ввод в действие». В рамках испытаний системы осуществляется проверка каждого требования ТЗ.

Связь ТЗ с этапами 5 «Технический проект» и 7 «Ввод в действие»
Как это связано с определением заинтересованных лиц?

На этапе «Технический проект» потребителем ТЗ будет выступать разработчик АС (то есть исполнитель). Разработчик должен реализовать АС так, чтобы она удовлетворяла требованиям, описанным в ТЗ.

На этапе «Ввод в действие» потребителем ТЗ будёт выступать заказчик, который примет созданную исполнителем АС и будет использовать её для решения своих задач.

Так мы определили, что глобально есть две заинтересованные стороны: заказчик и исполнитель. Есть некоторые особенности при работе с заказчиком, которые нужно учитывать.

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

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

Здесь мы опять можем проследить взаимосвязь ТЗ с другими стадиями, а именно со стадией 8 «Сопровождение АС».

Связь ТЗ с этапом 8 «Сопровождение АС»
Как это связано с последней стадией? Предположим, что цель создания АС: снизить время выполнения пользователем какой-либо операции до 30 секунд. Если на этапе сопровождения заказчик предъявит претензию о том, что операция выполняется за 25 секунд, то исполнитель может указать на цель ТЗ. То же самое работает и в обратную сторону: если операция выполняется 35 секунд, заказчик может обоснованно предъявить исполнителю претензии.

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

Кроме цели, в ТЗ есть два вида сущностей, которые задают некоторые важные ограничения.
  1. Показатели назначения — некие условия, в которых должна эксплуатироваться система. Например, максимальное количество пользователей или максимально допустимый объём хранимых данных. Эти ограничения могут быть защитой от претензий заказчика на стадии сопровождения. Например, если в ТЗ установлено ограничение в 1000 пользователей, любые инциденты, возникающие при большем числе пользователей, становятся ответственностью заказчика.

  2. Перспективы развития определяют границы расширения системы за счёт увеличения компонентов (например, масштабирование количества серверов). Желание заказчика в будущем расширить систему больше, чем указано в ТЗ, также будет являться зоной ответственности заказчика. Если на этапе разработки ТЗ определить границы развития невозможно, стоит включить требование по выявлению этих границ.
Режимы функционирования АС и обучение персонала
Ещё один пункт ТЗ, о котором часто забывают — «требования к организации функционирования АС и порядку взаимодействия персонала и пользователей с АС».
Здесь нужно обратить внимание на ещё одну взаимосвязь ТЗ, на этот раз со стадией 6 «Рабочая документация».

Связь ТЗ с этапом 6 «Рабочая документация»

На этой стадии разрабатывается эксплуатационная документация (ЭД) на систему. Не всегда при разработке ЭД есть чёткое понимание того, что должно в эту документацию входить. На самом деле ЭД должна состоять из инструкций, последовательностей шагов при работе с системой. Зная эти шаги, разработать ЭД — не самая трудная задача. Но возникают вопросы:

  1. Где взять перечень операций?
  2. К каким режимам работы отнести те или иные операции: штатный / регламентный / аварийный режимы?
  3. Как описывать аварийные ситуации?
  4. Насколько подробной должна быть ЭД?

Чтобы разработка ЭД не вызывала затруднений, в ТЗ нужно предъявить соответствующие требования. Необходимо указать:

  1. Описание режимов работы системы и процедуры перехода из режима в режим.
  2. Перечень ролей и типов пользователей, нужная квалификация и количество человек; требования к организации рабочего места.
  3. Перечень операций системы, длительность и частота их выполнения.
  4. Какие пользователи какие операции могут выполнять.
  5. Перечень регламентных работ.

Если такие требования предъявить при разработке ТЗ затруднительно, то необходимо включить в ТЗ требования по разработке соответствующих решений на стадии разработки технического проекта (стадия 5).
Формулирование требований
Чтобы избежать разночтений, стоит максимально аккуратно относится к тому, что вы пишите в документации.

1. Все формулировки в ТЗ должны быть чётко выверены. Двусмысленных и нечётких формулировок быть не должно.
   a. Размытые формулировки позволят заказчику интерпретировать их в свою пользу.
   b. Неоднозначные формулировки могут быть неверно поняты командой разработки и система может быть реализована не так, как ожидалось.

Чтобы этого избежать, каждое требование необходимо сопровождать критерием достижения. Пример размытого требования: «система работает быстро». Такое требование каждый воспринимает по-своему. Чтобы сделать это требование однозначным, нужно добавить критерии, например: «95 % запросов в системе выполняются менее чем за 1 сек».
2. Любые двусмысленности в формулировках должны быть выявлены и устранены на стадии разработки ТЗ, но никак не на стадии технического проекта или приёмки системы.

3. Любые договоренности должны быть зафиксированы на бумаге, а не устно. Малейшее изменение в составе рабочей группы проекта может уничтожить любые устные договорённости.
Уровень детализации функций
Насколько детально описывать функции системы? Нужно найти баланс.

С одной стороны, требования должны содержать как можно больше деталей о конкретном способе достижения результата — варианте реализации системы. Потому что:

  • Чем конкретнее описано ТЗ, тем меньше вероятность разногласий с заказчиком при приёмке системы.
  • Чем точнее описаны особенности функционирования системы — тем проще и быстрее она будет реализована.
  • Проектирование системы начинается уже на стадии разработки ТЗ.
С другой стороны, чем конкретнее в ТЗ описаны требования к варианту реализации АС, тем сильнее ограничен исполнитель:

  • Изменить ТЗ на последующих этапах будет затруднительно или вовсе невозможно
  • Выбор способа реализации заранее ограничен
  • Выбранный на стадии разработки ТЗ вариант реализации системы может не подойти

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

Например, уже на стадии ТЗ известно, что на компоненты АС нужно будет установить антивирус и подключить его к имеющемуся у заказчика серверу защиты. В ТЗ в этом случае стоит так и писать: установить такие-то агенты антивируса, подключить их к такому-то серверу, применить на них такие-то политики. Если же в ТЗ будут включены общие фразы о необходимости наличия абстрактного антивируса, то это в крайнем случае позволит заказчику на стадии проектирования поднять вопросы о перепроктировании имеющегося у него антивирусного средства.
Если же на стадии ТЗ выбор антивируса не осуществлён и такой выбор входит в согласованный объём работ, то в ТЗ можно оставить общие требования о наличии антивирусной защиты.

Если же на стадии ТЗ выбор антивируса не осуществлён, но такой выбор не входит в согласованный объём работ, то в ТЗ в плане работ следует чётко указать, что именно с антивирусом будете делать вы, а что — ваши смежники или сам заказчик.
Границы работ
Если созданием АС занимается не один подрядчик, а несколько — часто бывает сложно провести границы ответственности между ними. Например, вы создаете систему мониторинга и параллельно, в рамках этого же проекта, создаётся вычислительная инфраструктура. Вы в описании своих требований зависите от реализации вычислительной архитектуры, которая ещё не создана.

ГОСТ 34.602−2020 предполагает наличие раздела 6 «Порядок разработки АС». В этом разделе вы можете прямо описать зависимости вашей работы от результатов работы других подрядчиков. Например, можно указать, что какие-то исходные данные вы должны получить от заказчика / смежного исполнителя.

Кроме того, ТЗ позволяет разделить ответственность не только между подрядчиками, но и между заказчиком и исполнителем. Так, в ТЗ есть раздел 8 «Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу АС в действие». В этот раздел необходимо включить требования к условиям эксплуатации, которые должен выполнить заказчик, прежде чем можно будет проводить испытания системы (организация рабочих мест, наём и обучение персонала и т. д.).
Заключение
  1. ТЗ — удобный инструмент при создании АС, позволяющий выстроить порядок работы и учесть различные условия и особенности объектов автоматизации. ТЗ позволяет исполнителю и заказчику «говорить на одном языке», одинаково понимать всем заинтересованным сторонам особенности разработки системы.
  2. Грамотно составленное ТЗ защищает интересы как заказчика системы, так и исполнителя.
  3. Использование ГОСТов особенно полезно при разработке больших и сложных систем. Заложенная в ГОСТ структура ТЗ позволяет не забыть ничего важного и предусмотреть все аспекты разработки, внедрения и сопровождения системы.
Системный анализ и Разработка требований в ИТ-проектах

Этот курс — для ИТ-менеджеров и ИТ-специалистов, которые хотят научиться создавать требования и технические задания на программное обеспечение и сложные веб-сайты, веб-сервисы и мобильные приложения.
Посмотреть программу курса
Вопросы и ответы
  • Вопрос:
    Насколько разумно использовать ГОСТ 34 при внедрении информационных систем на готовых платформах? Например, при внедрении информационной системы планирования и управления ресурсами предприятия на базе 1С ERP.
    Ответ:
    Использовать можно. ГОСТ 34 чаще применяется именно при внедрении серийных продуктов. При разработке нового программного кода используют стандарты серии 19.
  • Вопрос:
    Разница между ТЗ и ЧТЗ? Что такое постановка на разработку функции?
    Ответ:
    ТЗ (техническое задание) — документ с требованиями по всей системе в целом. ЧТЗ (частное техническое задание) — документ с требованиями к части системы. Если система большая и её разрабатывают несколько исполнителей, есть смысл каждому исполнителю на его часть системы разработать отдельное ЧТЗ. ЧТЗ при этом должно зависеть от ТЗ на всю систему и ссылаться на него.

    Постановка на разработку функции описывает чётко каждую из функций системы. Таким документом можно воспользоваться, если разрабатываемая функция большая и сложная или разрабатывается отдельным исполнителем.
  • Вопрос:
    Применим ли ГОСТ при Scrum?
    Ответ:
    ГОСТ применим при любой методологии разработки. ГОСТ определяет последовательность разработки, позволяет заказчику и исполнителю говорить на одном языке.
  • Вопрос:
    При работе по ФЗ-44 на каком этапе пишется ТЗ? С одной стороны ТЗ пишется уже после торгов, когда есть победитель, но при этом деталей требований на уровне концепции не хватает для проведения тендера.
    Ответ:
    Здесь мы попадаем в терминологическую ловушку. Требования, выставляемые на конкурс на самом деле не являются ТЗ, хотя и носят такой заголовок. Правильнее было бы называть их техническими требованиями.

    Первое что должен сделать выигравший исполнитель — разработать ТЗ. Но сделать это не получается, так как документ с названием «Техническое задание» уже предоставлен заказчиком. Обычно исполнители пишут документ с другим названием, но по сути являющийся ТЗ и работают по нему.

    Примечание: ФЗ-44 — Закон о контрактной системе (закон о госзакупках). Федеральный закон от 5 апреля 2013 г. N 44-ФЗ «Федеральный закон «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».
  • Вопрос:
    Почему происходит насаждение ГОСТ 34? Почему нельзя пользоваться ГОСТ 19?
    Ответ:
    ГОСТ 34 серии и ГОСТ 19 серии регламентируют разные вещи.
    ГОСТ 19 регламентирует разработку программного изделия / программного обеспечения. ПО — универсальный продукт, который разрабатывается для массового использования в различных неспецифических условиях. Документация, разработанная по стандартам 19 серии, предполагает краткое описание абстрактных условий эксплуатации.

    ГОСТ 34 регламентирует создание АС. АС — не то же самое, что программное изделие. АС включает в себя не только код системы (техническую часть), но и персонал, который с этой системой будет работать (организационную часть). Поэтому документация по стандартам 34 серии должна учитывать все особенности бизнес-процессов, аспекты объектов автоматизации и условия, в которых система будет функционировать.
  • Вопрос:
    Документация по ГОСТ чаще всего применяется при заказной разработке. Можно ли её применять при внутренней разработке?
    Ответ:
    ГОСТ используется как некая «третья сторона», к которой можно обратиться в случае возникновения разногласий. Если и заказчик и исполнитель находятся на одной стороне, они могут договориться и без ГОСТов.
  • Вопрос:
    Кто должен писать ТЗ — исполнитель или заказчик?
    Ответ:
    Так как заказчик систем чаще всего не является экспертом в ИТ или экспертом в применяемых технологиях, ТЗ должен разрабатывать исполнитель.
  • Вопрос:
    Кто должен писать ТЗ — системный или бизнес-аналитик?
    Ответ:
    К разработке ТЗ должны привлекаться и системный и бизнес-аналитик. Задача бизнес-аналитика — описание и формализация автоматизируемого бизнес-процесса. Системный аналитик нужен для написания детальных требований к системе, описания набора компонентов системы, структур баз данных и так далее.
  • Вопрос:
    Что включать в «организационное обеспечение» в ТЗ?
    Ответ:
    Включать в этот раздел можно всё, что нужно для организации работ: разработка регламентов, дополнительных процессов или подразделений в организации.
  • Вопрос:
    Что описывать в разделе «лингвистическое обеспечение» в ТЗ?
    Ответ:

    В этом разделе можно описывать всё, что касается языков:

    1. Языков интерфейса, если предполагается мультиязычность системы.
    2. Языков программирования, если есть ограничения по использованию конкретных языков программирования.
  • Вопрос:
    В чем разница между ТЗ на сопровождение и ТЗ на эксплуатацию?
    Ответ:
    ТЗ, о котором идёт речь в статье — это ТЗ на создание АС. ТЗ распространяется в том числе на стадии сопровождения и эксплуатации. Когда речь идёт о какой-то одной стадии — это технические требования, на которые ГОСТ не распространяется.
Автор
Василий Баракин
Архитектор проектов по информационной безопасности в компании BCC
  • Опыт применения ГОСТ 34– — более 15 лет
  • Участие в создании АС федерального уровня