ГОСТ 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С» для работы с ИИ-инструментами. Показано, почему обычного пересказа стандартов недостаточно для надёжной генерации и ревью кода: при сокращении теряются условия применения, исключения, обязательность требований и контекст. Авторы описывают переход к формализованным карточкам правил, содержащим источник, условия, исключения, способ проверки, тяжесть нарушения, возможности автоматического контроля и дату сверки со стандартом. Материал будет полезен руководителям проектов 1С, архитекторам и разработчикам, которые внедряют ИИ в разработку и контроль качества. На реальных тестах показано, как структурированное представление стандартов снижает число пропущенных дефектов, ложных замечаний и потенциально опасных исправлений.

25.09.2026    219    0    Rico17    2    

1

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

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

24.09.2026    169    0    YA_826532418    0    

3

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

После нормативной документации, несоответствий, жалоб и аудитов остается еще один большой пласт СМК: записи качества, периодический мониторинг, цели, показатели и анализ со стороны руководства. В статье разбираю, что из этого стоит вести непосредственно в 1С:Документообороте, где достаточно контроля и хранения результата, когда нужен проект, а какие данные лучше оставить в профильных учетных системах.

22.09.2026    146    0    YA_826532418    0    

3

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

Жалоба клиента может привести к регистрации несоответствия, внутренний аудит — сразу к нескольким проблемам, а корректирующее действие — к новой редакции нормативного документа. Во второй части разбираю, какие механизмы 1С:Документооборота подходят для жалоб и внутренних аудитов, какие связи между объектами нужно предусмотреть и что спросить на обследовании, чтобы СМК не превратилась в набор несвязанных карточек.

22.09.2026    137    0    YA_826532418    0    

3

Стандарты и документация 1С:Предприятие 8 1С:Документооборот Бесплатно (free)

Имея опыт работы и специалистом по системе менеджмента качества, и бизнес-аналитиком, я отметила, что автоматизация СМК редко сводится к созданию нескольких видов документов и маршрутов согласования, потому что нормативная документация, несоответствия и корректирующие действия живут по разным правилам. В статье посчитала важным разобрать не только вопрос того, какие механизмы 1С:Документооборота подходят для этих процедур, но и какие вопросы нужно задать на обследовании, чтобы потом не переделывать структуру документов и маршруты.

21.09.2026    197    0    YA_826532418    0    

4

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

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

04.09.2026    519    0    YA_826532418    0    

3

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

Разбираем ISO/IEC 42001:2023 – самостоятельный стандарт по системам менеджмента искусственного интеллекта, построенный на логике ISO/IEC 27001 и расширяющий привычные подходы информационной безопасности на разработку, поставку и использование ИИ-систем. Показываем, как типовая модель оценки рисков дополняется анализом воздействия на бизнес и общество, а приложение А объединяет меры управления рисками в десять групп контролей. Объясняем, чем отличаются требования к разработчикам, поставщикам и пользователям систем искусственного интеллекта и какие риски каждая из сторон должна учитывать на своих этапах жизненного цикла. Материал будет полезен специалистам по информационной безопасности и разработчикам информационных систем, интегрированных с ИИ.

31.07.2026    581    0    roman_nikishov    0    

1

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

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

29.07.2026    578    0    OksanaBogdashkina    2    

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