ГОСТ 19.201-78. ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ.

29.06.05

Управление ИТ - Стандарты и документация

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

Стандарт полностью соответствует СТ СЭВ 1627-79.
1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78.

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

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

1.4. Техническое задание должно содержать следующие разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе или программному изделию;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
в техническое задание допускается включать приложения.

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

(Измененная редакция, Изм. № 1)
2. СОДЕРЖАНИЕ РАЗДЕЛОВ

2.1. В разделе «Введение» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

(Измененная редакция, Изм. № 1)

2.2. В разделе «Основания для разработки» должны быть указаны:
документ (документы), на основании которых ведется разработка;
организация, утвердившая этот документ, и дата его утверждения;
наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

2.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
требования к функциональным характеристикам;
требования к надежности;
условия эксплуатации;
требования к составу и параметрам технических средств;
требования к информационной и программной совместимости;
требования к маркировке и упаковке;
требования к транспортированию и хранению;
специальные требования.

(Измененная редакция, Изм. № 1)

2.4.1. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.

2.4.2. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).

2.4.3. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

2.4.5. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1)

2.4.6. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

2.4.7. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.

2.5а. В разделе «Требования к программной документации» должен быть указан предварительный состав программной документации и, при необходимости, специальные требования к ней.

(Введен дополнительно, Изм. № 1).

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

2.6. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

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

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Стандарты и документация Бесплатно (free)

Рассказываем, как использовать текст договора в качестве инструмента управления проектом: фиксировать ожидания, этапы работ, сценарии выполнения и возможные изменения. На примере проектов переноса данных 1С показываем, чем они отличаются от проектов внедрения, зачем нужна короткая анкета на старте и как декомпозиция помогает заранее «разложить проект на кирпичики». Объясняем, почему IT-проекты можно оценивать по аналогии со строительством – через понятные виды работ, объемы и нормировки, – а коммерческое предложение стоит делать достаточно подробным, чтобы к нему можно было вернуться при изменении сценария. Отдельно разбираем, как повторяющиеся этапы и фиксация работ по периодам помогают гибко управлять объемом проекта, снижать риски для подрядчика и упрощать согласования на стороне заказчика.

14.05.2026    466    7    primat    0    

2

Стандарты и документация Бесплатно (free)

Безопасная конфигурация в 1С начинается с соблюдения стандартов v8std, которые определяют требования к защите серверного API, работе с внешним кодом, запуску приложений и хранению чувствительных данных. Объясняем ключевые принципы безопасной разработки: от корректного использования признака «Вызов сервера» и безопасного хранения паролей до правил запуска внешних программ, ограничения исполнения произвольного кода и работы с внешними компонентами. Подробный разбор каждого требования показывает, как минимизировать риски и создать конфигурацию, устойчивую к типовым угрозам безопасности.

07.05.2026    1849    0    zeegin    3    

19

Стандарты и документация Коммуникации Россия Бесплатно (free)

Как оценить зрелость команды 1С не по общему чек-листу, а по практикам, которые реально важны для платформы? Собрал модель из 8 направлений — от управления кодом и CI/CD до AI-практик — с конкретными критериями на каждом из пяти уровней. Внутри — открытый инструмент для самооценки.

08.04.2026    878    0    maraty    10    

2

Управление знаниями в ИТ Стандарты и документация Бесплатно (free)

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

31.03.2026    627    0    monwig    0    

0

Стандарты и документация Бизнес-аналитик Бесплатно (free)

На примере записки по модели RLS в 1С ERP разбираю, что в таком документе уже хорошо, чего не хватает для управленческого решения и как сообщество оценивает качество такой аналитики?

23.03.2026    810    0    EMelihoff    1    

2

Стандарты и документация Бесплатно (free)

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

12.02.2026    1246    0    AlexeyPROSTO_1C    5    

0

Взгляд со стороны Заказчика Работа с заинтересованными сторонами Стандарты и документация Бесплатно (free)

Статья про то, как выстроить с Заказчиком прозрачные и доверительные отношения на всем пути — от коммерческого предложения до запуска. Покажем, как вовлекать его уже на этапе подготовки КП: делать документ вместе, чтобы было ясно, за что клиент платит и что в итоге получит. Разберем, как сбалансировать загрузку проектных команд и бюджет, выбирая подходы, которые не создают простоев и сохраняют темп. Также расскажем о том, как управлять ожиданиями с помощью стандартизированной документации и понятных результатов по каждому этапу. И, наконец, о том, как зажечь и удержать интерес пользователей.

21.10.2025    1366    0    user1984674    0    

-1

Внедрение изменений Стандарты и документация Бесплатно (free)

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

02.10.2025    3016    0    user1923656    0    

3
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. tsd 106 28.11.08 22:56 Сейчас в теме
у ё, support, ты из какого чулана раритетную книжку достал?
хе хе, больше всего мне нравится раздел 2.4.7.
2. O-Planet 6456 28.11.08 23:57 Сейчас в теме
Там же явно указано: образец 78-79 годов. Я вот видел такие ТЗ. Помню еще, что они пишутся на сиреневой бумаге, фиолетовыми чернилами, от руки, чертежным шрифтом. Раритет, вообще-то. Но по сравнению с тем, с чем приходится теперь работать - они шедевральны!
3. Star_SU 13 12.12.14 12:52 Сейчас в теме
O-Planet - Новое - это забытое старое. Спасибо за статью - возьму информацию из нее за основу написания своего первого ТЗ :)
Для отправки сообщения требуется регистрация/авторизация