6.04. Техническое задание по ГОСТ 19.201-78

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Руководителю Аналитику Техническому писателю

ГОСТ

Основано на ГОСТ 19.201-78.

Часть 1. Техническое задание

1. Что такое техническое задание (ТЗ)?

Согласно ГОСТ 19.201-78, техническое задание — это нормативный документ, устанавливающий целевое назначение, основные требования, условия разработки, контроля и приёмки программы или программного изделия.

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

✅ ТЗ не описывает реализацию (как будет сделано), а только что должно быть сделано и при каких условиях.

2. История и статус стандарта

Номер и наименование: ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению»
Дата введения: 1 января 1980 г.
Соответствие международным нормам: полностью соответствует СТ СЭВ 1627-79 (советский стандарт взаимной совместимости стран СЭВ).
Текущий статус: формально не отменён, сохраняет силу в части требований к структуре и содержанию. Однако на практике в госсекторе РФ дополняется ГОСТ Р 19.101-2016 (часть ЕСПД), а в коммерческих проектах — адаптируется под Agile-практики (User Stories, Product Backlog, SOW и др.).

⚠️ Важно: ГОСТ 19.201-78 применяется к любым программным системам независимо от назначения — как к встроенным (embedded), так и к корпоративным ERP/CRM, web- и мобильным приложениям.

3. Область применения

ТЗ по ГОСТ 19.201-78 необходимо разрабатывать в следующих случаях:

Сценарий	Обоснование
Разработка ПО «с нуля»	ТЗ служит основанием для старта проектирования и заключения договоров
Модернизация существующего ПО	Даже при инкрементальной разработке — требуется фиксация изменений в виде дополнения к ТЗ (см. п. 1.3 стандарта)
Госзакупки, госконтракты	Требование законодательства — ГОСТ входит в перечень обязательных стандартов ЕСПД
Обучение и аттестация	Используется в ВУЗах и при сертификации специалистов (например, в рамках программы «Цифровая экономика»)

4. Основные принципы стандарта

Обязательность структуры — ТЗ должно содержать определённый перечень разделов (см. п. 1.4 ГОСТ).
Гибкость содержания — разрешается уточнение, объединение или добавление разделов в зависимости от специфики системы (так, для облачного SaaS не требуются «требования к транспортированию»).
Порядок изменения — любые правки после утверждения оформляются как дополнение к ТЗ, проходят ту же процедуру согласования и утверждения.
Формат документа — листы форматов A4 (ГОСТ 2.301-68), нумерация страниц — сверху, над текстом; титульный лист и лист утверждения — по ГОСТ 19.104-78.

5. Обязательные разделы ТЗ по ГОСТ 19.201-78

Стандарт в п. 1.4 задаёт базовый каркас, обязательный для всех ТЗ:

№	Раздел	Обязательность	Краткое содержание
1	Введение	✔️	Наименование, область применения, краткая характеристика объекта автоматизации
2	Основания для разработки	✔️	Документы-основания, организация-заказчик, тема разработки
3	Назначение разработки	✔️	Функциональное и эксплуатационное назначение
4	Требования к программе / программному изделию	✔️	Наиболее объёмный раздел — содержит 8 подразделов (функциональные, надёжность, эксплуатация, совместимость и др.)
5	Требования к программной документации	✔️	Перечень документов (например: ПЗ, РД, ФО, ЭД), специальные форматы
6	Технико-экономические показатели	✔️	Экономическая эффективность, сравнение с аналогами
7	Стадии и этапы разработки	✔️	План-график, перечень исполнителей, сроки, перечень разрабатываемых документов
8	Порядок контроля и приемки	✔️	Виды испытаний (предварительные, приёмочные), критерии приёмки
9	Приложения	⚪ Опционально	Обоснования, алгоритмы, расчёты, схемы

🔄 Примечание: Стандарт допускает объединение или детализацию разделов (например, «Назначение» и «Введение» иногда объединяют). Однако ни один из обязательных разделов нельзя полностью опустить — даже если часть полей остаётся пустой, следует указать «не применимо» с обоснованием.

🧭 Часть 2: Пошаговое руководство по составлению ТЗ по ГОСТ 19.201-78

🎯 Цель этого раздела — дать практическую методику написания ТЗ:

какие формулировки использовать,

как избегать двусмысленности,

как проверить завершённость раздела,

какие ловушки типичны для новичков.

Все рекомендации строго соответствуют тексту стандарта и проверены на реальных проектах (включая госзаказы и интеграции в корпоративные ИС).

🔢 2.1. Общие правила оформления

Правило	Обоснование / Комментарий
Формат листов — А4 (ГОСТ 2.301-68), ориентация книжная	Обязательно. Нарушение формата — причина возврата документа в госструктурах.
Нумерация страниц — в верхней части, над текстом	Требование п. 1.1 стандарта. Автонумерация в Word/Confluence допустима, если соответствует.
Титульный лист и лист утверждения — по ГОСТ 19.104-78	Обязательны для официального оборота. В учебных/внутренних целях могут быть упрощены.
Аннотация и содержание — допускается не включать (п. 1.2)	Полезно для длинных ТЗ (>30 стр.), но не требуется по стандарту.
Изменения — только через дополнения к ТЗ (п. 1.3)	Прямое редактирование утверждённого ТЗ — нарушение процедуры. Дополнение должно иметь тот же уровень согласования.

💡 Совет по инструментам:

Для версионирования используйте Git (даже для .docx через git-lfs).

Для автоматической нумерации разделов — Pandoc + Markdown с YAML-заголовками и number_sections: true.

Для контроля — чек-лист на основе п. 1.4–2.8 стандарта.

📑 2.2. Пошаговое заполнение разделов ТЗ

▶ Раздел 1. Введение (п. 2.1 стандарта)

Что писать:

Наименование системы (например: «Система управления учебными проектами для школьников»).
Краткая характеристика области применения (например: «Используется в рамках образовательных программ для детей 8–16 лет»).
Объект автоматизации (например: «Процесс планирования, контроля и оценки индивидуальных IT-проектов учащихся»).

Типичные ошибки:

❌ Называть продукт аббревиатурой без расшифровки в первый раз.
❌ Подменять введение маркетинговым описанием («революционная платформа» → ✖).
❌ Описывать функции — это относится к разделу 4.

Проверочный вопрос:

Может ли сторонний эксперт, прочитав только «Введение», точно ответить — для кого и в каком контексте будет использоваться система?

▶ Раздел 2. Основания для разработки (п. 2.2)

Обязательные элементы:

Документ(-ы)-основание — например:
- Постановление Минобрнауки № X от DD.MM.YYYY
- Письмо-запрос заказчика (реквизиты: №, дата)
- Решение совета директоров ООО «X» (протокол №Y от DD.MM.YYYY)
Организация-инициатор и дата утверждения.
Наименование/условное обозначение темы — лучше использовать единый шифр (например: PROJ-EDU-2025-001).

Пример корректной формулировки:

«Разработка ведётся на основании письма Департамента цифрового развития г. Уфы № УФ-ЦР/245 от 12.02.2025 г., утверждённого начальником департамента А.В. Петровым. Тема разработки: «Информационная система поддержки проектной деятельности школьников» (условное обозначение: IS-PDS-2025).»

Важно:
Если документ-основание — внутренний, его копия должна быть приложена (п. 2.8). Для внешних — указываются реквизиты.

▶ Раздел 3. Назначение разработки (п. 2.3)

Два ключевых аспекта:

Функциональное назначение — что делает система:

«Обеспечивает учёт, планирование и оценку индивидуальных IT-проектов учащихся от идеи до реализации».
Эксплуатационное назначение — где, когда, как используется:

«Предназначена для работы в школьных классах и внеурочной деятельности; доступна через веб-браузер; не требует установки на клиентских устройствах».

Не допускается:

Указание технологий реализации («на базе Spring Boot и PostgreSQL» → ✖, это относится к РД/ПЗ).
Оценочные суждения («повысит эффективность на 30%» → ✖, это относится к ТЭП).

▶ Раздел 4. Требования к программе / программному изделию (п. 2.4 — самый объёмный)

Этот раздел всегда должен включать восемь подразделов (п. 2.4). Ниже — пошаговое руководство по каждому.

4.1. Требования к функциональным характеристикам (п. 2.4.1)

Содержание:

Перечень функций (лучше в виде таблицы или нумерованного списка).
Для каждой функции:
- входные данные (с указанием источников и форматов),
- алгоритм/логика (без кода — на уровне «если… то…»),
- выходные данные (формат, получатели),
- временные ограничения (если критичны, например: «формирование отчёта — не более 5 с при нагрузке ≤100 пользователей»).

Формат записи (рекомендуемый):

4.1.3. Функция «Регистрация проекта»  
- Вход:  
  - данные пользователя (ФИО, класс, школа — из LDAP/ввод вручную);  
  - описание проекта (не более 2000 символов);  
  - метки (теги: язык, сложность, тема — из справочника).  
- Логика:  
  - проверка уникальности названия в рамках школы;  
  - назначение ментора (автоматически — по расписанию доступности).  
- Выход:  
  - карточка проекта (ID, статус «Создан», ссылка на редактирование);  
  - уведомление ментору (email + push).  
- Ограничение: время ответа API ≤ 1.2 с (p95).

✅ Совет: Используйте термины из предметной области (не «юзер», а «учащийся» или «педагог-наставник»).
❌ Ошибка: «Система должна быть удобной» → бессмысленно. Заменить на: «время обучения новому пользователю — ≤15 минут (по результатам тестирования прототипа)».

4.2. Требования к надёжности (п. 2.4.2)

Что включать:

Допустимая частота отказов (например: MTBF ≥ 300 ч).
Время восстановления после сбоя (MTTR ≤ 15 мин для критических функций).
Методы контроля входной/выходной информации:
- валидация форматов (JSON Schema, XSD);
- проверка цифровых подписей (если требуется);
- логирование операций (полный аудит действий с проектами).
Требования к резервному копированию (например: «полный бэкап БД — ежедневно, инкрементный — каждые 2 ч»).

Важно:
Если система не критична к отказам (например, образовательный тренажёр), допустимо указать:

«Требования к надёжности не регламентируются ввиду некритичности последствий простоя. Рекомендуется обеспечивать доступность ≥ 95% в учебное время (пн–пт, 8:00–18:00 по местному времени).»

4.3. Условия эксплуатации (п. 2.4.3)

Содержание:

Параметры внешней среды (для физических носителей/оборудования):
- температура: +10°C…+35°C
- влажность: 20%–80% без конденсации
Требования к персоналу:
- администратор — 1 чел., квалификация: «специалист по эксплуатации ИС» (по ЕКСД);
- пользователи — школьники 8–16 лет, педагоги (обучение по встроенной справке).
Тип обслуживания: централизованное (облачный хостинг), без локального технического персонала.

📌 Для SaaS-систем часть требований может быть «не применимо» — но обязательно указать это с пояснением.

4.4. Требования к составу и параметрам технических средств (п. 2.4.4)

Что указывать:

Серверная часть (если развёртывается заказчиком):
- CPU: ≥ 4 ядра, 2.5 ГГц
- RAM: ≥ 8 ГБ
- HDD: ≥ 100 ГБ SSD
- OS: Ubuntu 20.04 LTS и выше
Клиентская часть:
- браузеры: Chrome ≥ 100, Firefox ≥ 102, Edge ≥ 103
- разрешение экрана: ≥ 1280×720
- стабильное подключение к интернету ≥ 5 Мбит/с.

Не включать:

Конкретные модели серверов (Dell R750 → ✖).
Марки сетевого оборудования (Cisco, Huawei → ✖), если нет жёстких требований к совместимости.

4.5. Требования к информационной и программной совместимости (п. 2.4.5)

Обязательно:

Форматы входных/выходных данных:
- импорт проектов: CSV (кодировка UTF-8, разделитель ;)
- экспорт отчётов: PDF/A-3, XLSX
- API: RESTful, OpenAPI 3.0, аутентификация — OAuth 2.0 (client credentials flow)
Интеграции:
- LDAP/AD — для синхронизации учётных записей школы
- ГИС «Образование» — передача агрегированных метрик (еженедельно, по протоколу HTTPS)
Языки программирования и платформы не указываются (это — прерогатива Рабочего проекта), кроме случаев, когда это задано внешними ограничениями, например:

«Для обеспечения совместимости с существующим стеком заказчика, модуль интеграции с ГИС должен быть реализован на Java 11 и использовать SDK ГИС версии 4.2.1»

Безопасность (если требуется):

Шифрование данных в покое (AES-256) и в транзите (TLS 1.3).
Аудит доступа к персональным данным (соответствие ФЗ-152).

4.6–4.8. Маркировка, транспортирование, хранение (пп. 2.4.6–2.4.7)

Для программного изделия (дистрибутива):

Маркировка носителя:

«На каждом оптическом диске: наименование ПО, версия, дата сборки, штрихкод»
Упаковка:

«Коробка с амортизирующей прокладкой, вложен сертификат соответствия»
Хранение:

«В сухом, защищённом от прямого света помещении при t = +5…+30°C; срок годности дистрибутива — 3 года»

Для SaaS / веб-приложений:

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

4.9. Специальные требования (п. 2.4, конец списка)

Сюда включают:

Требования, не вошедшие в другие подразделы:
- локализация (языки: русский, башкирский, английский);
- требования к UX (соответствие методическим рекомендациям Минобрнауки по интерфейсам для детей);
- ограничения по лицензированию («запрещено использование проприетарных библиотек без письменного согласия заказчика»);
- требования к аудиту («предоставление логов по запросу контролирующего органа в течение 24 ч»).

▶ Раздел 5. Требования к программной документации (п. 2.5а)

Что указывать:

Перечень документов по ЕСПД / проектному регламенту, например:

Код ЕСПД	Наименование	Стадия	Формат
ПЗ	Пояснительная записка	Рабочий проект	PDF, Markdown
РД	Руководство разработчика	ТО	HTML (внутренний портал)
ФО	Формуляр	После приёмки	PDF, заверенный ЭЦП
ЭД	Эксплуатационная документация	При поставке	Веб-справка в системе

Специальные требования:

«Все документы должны быть оформлены в соответствии с ГОСТ 19.105-78 и содержать версионную метку вида v1.2.0+20251110»
«Для пользователей 8–12 лет дополнительно разрабатывается анимированный гид (MP4, ≤5 мин)»

▶ Раздел 6. Технико-экономические показатели (п. 2.5)

Обязательно:

Ориентировочная экономическая эффективность (расчётный):

«Сокращение времени педагога на учёт проектов с 4 ч/нед до 1 ч/нед → экономия 156 ч/год на школу»
Предполагаемая годовая потребность:

«Покрытие 200 школ РБ, 40 000 учащихся»
Сравнение с аналогами:

«Аналог: «Проектник» (ООО «Образ»). Преимущества предлагаемой системы: поддержка мультиязычности, интеграция с ГИС, встроенные метрики прогресса»

📉 Методика: можно использовать упрощённый ROI, NPV, срок окупаемости — но только если есть обоснование. Иначе — качественные сравнения.

▶ Раздел 7. Стадии и этапы разработки (п. 2.6)

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

№	Стадия	Этап	Содержание работ	Исполнитель	Срок (начало–окончание)	Результат
1	Техническое проектирование	1.1. Сбор требований	Интервью с педагогами, анализ регламентов	Аналитик А.А. Иванов	01.12.2025–15.12.2025	Утверждённое ТЗ
2	Рабочее проектирование	2.1. Проектирование БД	ERD, DDL-скрипты	Архитектор С.С. Петров	16.12.2025–10.01.2026	Модель данных v1.0
…	…	…	…	…	…	…

Важно:

Стадии по ЕСПД:
1. Техническое задание (ТЗ)
2. Технический проект (ТП)
3. Рабочая документация (РД)
4. Внедрение и сопровождение
В Agile-проектах допустимо:

«Стадия „Рабочая документация“ реализуется итеративно по спринтам; полный комплект документов формируется по завершении Release 1.0»

▶ Раздел 8. Порядок контроля и приёмки (п. 2.7)

Что указать:

Виды испытаний:
- предварительные (разработчиком),
- приёмочные (заказчиком в присутствии представителя),
- комплексные (при интеграции с ГИС).
Критерии приёмки:
_«Приёмка считается пройденной, если:
- все функции из п. 4.1 реализованы и протестированы;
- 100% критических и 95% высоких дефектов устранены;
- документация передана в полном объёме.»_
Форма акта:

«Акт приёмки — по форме Приложения №3 к договору №ХХХ; подписывается в течение 5 раб. дней после завершения испытаний»

▶ Приложения (п. 2.8)

Типичный состав:

Приложение А. Перечень регламентных документов (ФГОС, СанПиН и др.)
Приложение Б. Диаграммы процессов (BPMN 2.0)
Приложение В. Примеры входных/выходных данных (JSON-сэмплы)
Приложение Г. Расчёт экономической эффективности (Excel-файл в архиве)

📎 Приложения нумеруются буквами, ссылаются в основном тексте:
«…см. Приложение Б, рис. Б.2»

🚫 Типичные ошибки при составлении ТЗ (и как их избежать)

Ошибка	Последствия	Как исправить / предотвратить
Размытые формулировки: «система должна быть быстрой»	Споры при приёмке, срыв сроков	Заменить на измеримые метрики: «время отклика на 95-м перцентиле ≤ 1.5 с при 50 одновременных пользователях»
Смешение требований и решений: «реализовать на PostgreSQL»	Ограничение конкуренции, рост стоимости	Перенести в РД. В ТЗ: «СУБД должна поддерживать ACID, репликацию и SQL-92»
Пропуск подразделов в п. 4	Возврат ТЗ на доработку (особенно в госсекторе)	Использовать чек-лист по п. 2.4 стандарта — 8 подразделов всегда присутствуют (даже с пометкой «не применимо»)
Отсутствие ссылок на документы-основания	Юридическая незащищённость	Указать реквизиты всех документов, даже внутренних. Приложить копии в Приложения.
Нет чёткого критерия приёмки	Затягивание сдачи	Прописать: «Приёмка — после устранения всех блокирующих дефектов (critical) и подписания акта по форме Прил. 3»

Пример

Техническое задание

на разработку программного изделия
«Система управления индивидуальными учебными проектами школьников»
(Условное обозначение: SUIT-EDU-2025)

1. Введение

Система SUIT-EDU-2025 предназначена для автоматизации процессов планирования, выполнения, контроля и оценки индивидуальных учебных проектов учащихся общеобразовательных организаций в возрасте 8–16 лет.

Область применения:
— общеобразовательные школы субъектов Российской Федерации;
— центры цифрового образования «IT-куб»;
— внеурочная деятельность, включая профильные смены и онлайн-кружки.

Объект автоматизации:
— процесс формирования портфолио проектной деятельности учащегося,
— взаимодействие «учащийся — педагог-наставник — эксперт»,
— сбор метрик образовательных результатов для аналитики.

2. Основания для разработки

Разработка ведётся на основании:
— Письма Министерства просвещения РФ № МП-13/445-П от 05.03.2025 г. «Об организации проектной деятельности в рамках цифровой трансформации образования»;
— Решения Совета директоров АНО «Цифровое образование» (протокол № 8 от 12.04.2025 г.);
— Договора № EDU/2025/007 на НИОКР между АНО «Цифровое образование» и ООО «ОбразТех» от 20.04.2025 г.

Наименование темы: «Разработка облачной системы поддержки индивидуальных учебных проектов школьников»
Условное обозначение темы: NIORK-2025-04-EDU

3. Назначение разработки

3.1. Функциональное назначение

Система предназначена для:
— регистрации и структурирования учебных проектов;
— ведения журналов плановых/фактических этапов;
— организации рецензирования и защиты проектов;
— формирования электронного портфолио учащегося в формате, совместимом с ФГОС ООО и ФГОС СОО.

3.2. Эксплуатационное назначение

Система эксплуатируется в режиме SaaS:
— доступ через веб-интерфейс и мобильное приложение (iOS/Android);
— работа в учебное время (пн–пт, 8:00–19:00 по местному времени);
— не требует установки на клиентские устройства (кроме мобильного приложения);
— не предназначена для обработки персональных данных категории «особые» (согласно ФЗ-152).

4. Требования к программе или программному изделию

4.1. Требования к функциональным характеристикам

№	Функция	Входные данные	Логика	Выходные данные	Ограничения
4.1.1	Регистрация проекта	— ФИО учащегося, класс, школа (из LDAP или вручную) — название, описание (до 2000 знаков) — теги (язык: Python/JS/Scratch; сложность: 1–3; область: веб/робототехника/анализ данных)	— проверка уникальности названия в рамках школы — назначение наставника по расписанию доступности — формирование карточки проекта	— ID проекта (UUID) — статус: «Создан» — ссылка на редактирование в ЛК — email-уведомление наставнику	Отклик API ≤ 1.2 с (p95)
4.1.2	Ведение дневника проекта	— дата, описание этапа, ссылки на артефакты (файлы, GitHub-репозиторий) — оценка наставника (1–5)	— привязка к проекту — версионирование записей — автоматическая генерация хронологии	— журнал в PDF/HTML — виджет прогресса (линейная шкала)	Сохранение записи — ≤ 0.8 с
4.1.3	Подготовка к защите	— список требований к защите (из справочника школы) — видео/презентация (до 100 МБ)	— валидация формата (MP4, PDF, PPTX) — проверка длины видео (≤ 5 мин) — назначение рецензентов	— карточка готовности — ссылка на онлайн-трансляцию защиты (интеграция с Zoom API)	Загрузка 100 МБ — ≤ 30 с при 5 Мбит/с

✅ Совместимость: Все API-эндпоинты должны соответствовать спецификации OpenAPI 3.0 (см. Приложение В).

4.2. Требования к надёжности

Доступность: ≥ 99.0% в интервале 08:00–19:00 (понедельник–пятница, по Московскому времени).
Отказоустойчивость:
- MTBF ≥ 250 ч;
- MTTR ≤ 30 мин для критических сбоев (недоступность основного функционала);
- резервирование: master-slave репликация БД, балансировка нагрузки на уровне приложения.
Контроль данных:
- валидация входных данных по JSON Schema (схемы — в Приложении Г);
- логирование операций с персональными данными (ФИО, школа) с детализацией: кто, когда, что изменил.
Резервное копирование:
- полная резервная копия БД — ежедневно (02:00 МСК);
- инкрементное — каждые 2 ч;
- хранение копий — 30 дней.

4.3. Условия эксплуатации

Внешняя среда (для серверной части, развёрнутой у заказчика):
- температура: +10°C…+35°C;
- влажность: 20%–80% без конденсации;
- электропитание: ИБП, резервный генератор.
Персонал:
- администратор ИТ: 1 чел., квалификация — «специалист по эксплуатации ИС» (ЕКСД);
- пользователи: учащиеся, педагоги-наставники, эксперты (обучение — по встроенной интерактивной справке).
Режим работы:
- круглосуточный приём данных;
- активное использование — в учебное время.

⚪ Примечание: Для облачного размещения (по умолчанию) требования к внешней среде обеспечивает хостинг-провайдер (см. п. 4.4).

4.4. Требования к составу и параметрам технических средств

Компонент	Требования
Сервер приложения (если on-premise)	— CPU: ≥ 4 ядра, 2.4 ГГц — RAM: ≥ 8 ГБ — SSD: ≥ 100 ГБ — OS: Ubuntu 20.04 LTS / CentOS 7+ — Сетевой интерфейс: 1 Гбит/с
СУБД	— PostgreSQL ≥ 14.0 с поддержкой репликации — Резервный сервер — аналогичные характеристики
Клиентские устройства	— Браузеры: Chrome ≥ 110, Firefox ≥ 115, Edge ≥ 110, Safari ≥ 15 — Разрешение экрана: ≥ 1280×720 — Мобильные ОС: Android ≥ 9, iOS ≥ 14
Сетевые требования	— Пропускная способность: ≥ 5 Мбит/с на пользователя — Задержка до сервера: ≤ 100 мс

❗ Примечание: При развёртывании в облаке (Яндекс.Облако, AWS) — соответствие SLA провайдера: 99.9% uptime, резервирование зон доступности.

4.5. Требования к информационной и программной совместимости

Форматы данных:
- вход: CSV (UTF-8, ;), JSON (RFC 8259), XLSX (Office Open XML);
- выход: PDF/A-3 (для отчётов), XLSX, JSON (для интеграций).
API:
- RESTful, HTTPS, аутентификация — OAuth 2.0 (client credentials + refresh token);
- rate limit: 100 req/min/IP.
Интеграции:
- LDAP/Active Directory — синхронизация учётных записей (ежедневно, 01:00 МСК);
- ГИС «Образование» — передача агрегированных метрик (кол-во проектов, % завершённых) раз в неделю по протоколу HTTPS + ЭЦП;
- «СберКласс» — единственный вход (SSO) через OpenID Connect.
Безопасность:
- шифрование данных в покое — AES-256, в транзите — TLS 1.3;
- аудит действий по работе с ПДн — хранение 180 дней.

4.6. Требования к маркировке и упаковке

Не применимо, так как программное изделие поставляется как облачная услуга (SaaS) без физических носителей.
При выпуске off-line версии (на USB-накопителе) — отдельное дополнение к ТЗ.

4.7. Требования к транспортированию и хранению

Не применимо (SaaS-модель).
В случае дистрибутива на физическом носителе:
— транспортировка — в заводской упаковке, без воздействия влаги и ударов;
— хранение — температура +5…+30°C, срок годности — 3 года.

4.8. Специальные требования

Локализация:
— интерфейс: русский, башкирский, английский (язык определяется по браузеру/аккаунту);
— тексты для детей 8–12 лет — упрощённый стиль (Flesch–Kincaid ≤ 7).
Доступность:
— соответствие ГОСТ Р 52872-2019 (веб-доступность);
— поддержка screen reader (ARIA-метки, контраст ≥ 4.5:1).
Лицензирование:
— запрещено использование проприетарных библиотек без письменного согласия заказчика;
— исходный код — на условиях MIT License (если не иное по договору).
Экологичность:
— энергоэффективность: коэффициент PUE ≤ 1.3 у хостинг-провайдера.

5. Требования к программной документации

Код ЕСПД	Наименование документа	Стадия	Формат	Срок сдачи
ПЗ	Пояснительная записка	Рабочий проект	PDF, Markdown	+30 дн. после ТЗ
РД	Руководство разработчика	Рабочий проект	HTML (внутренний портал)	+60 дн.
ФО	Формуляр	После приёмки	PDF (подписан ЭЦП)	+5 дн. после приёмки
ЭД	Эксплуатационная документация	При поставке	Веб-справка + видео (≤5 мин)	+7 дн. после Релиза 1.0
ПИ	Программа и методика испытаний	Перед приёмочными	PDF	+10 дн. до испытаний

Специальные требования:
— Все документы — в кодировке UTF-8;
— Версионирование: v{major}.{minor}.{patch}+{YYYYMMDD};
— Для учащихся 8–12 лет — дополнительный анимированный гид (MP4, 1280×720, ≤ 4 мин).

6. Технико-экономические показатели

Ориентировочная экономическая эффективность:
— сокращение времени педагога на учёт проектов: с 4 ч/нед до 0.8 ч/нед → экономия 166 ч/год на школу;
— сокращение количества бумажных анкет: 100% цифровизация.
Предполагаемая годовая потребность:
— охват: 220 школ РБ и 15 центров «IT-куб»;
— пользователи: 44 000 учащихся, 2 200 педагогов.

Сравнение с аналогами:

Параметр	«Проектник» (ООО «Образ»)	SUIT-EDU-2025 (предлагаемый)
Интеграция с ГИС	нет	да (автоматическая)
Поддержка мультиязычности	только русский	русский, башкирский, англ.
Встроенные метрики прогресса	ручной ввод	автоматический анализ дневника
Лицензия	коммерческая (120 тыс./год)	open core + господдержка

7. Стадии и этапы разработки

№	Стадия	Этап	Содержание	Исполнитель	Срок	Результат
1	Техническое проектирование	1.1	Анализ требований, уточнение ТЗ	ООО «ОбразТех», аналитик	01.11–20.11.2025	Утверждённое ТЗ v1.0
2	Технический проект	2.1	Проектирование архитектуры, БД	Архитектор	21.11–15.12.2025	ТП, ERD, API-spec
3	Рабочий проект	3.1	Реализация MVP (регистрация, дневник)	Команда 5 разработчиков	16.12.2025–15.02.2026	Релиз 0.5 (alpha)
3	Рабочий проект	3.2	Интеграция с LDAP и ГИС	DevOps + 2 backend	16.02–10.03.2026	Релиз 1.0 (beta)
4	Внедрение	4.1	Пилот в 5 школах	Заказчик + поддержка	11.03–31.03.2026	Отчёт по пилоту
4	Внедрение	4.2	Приёмочные испытания	Приёмочная комиссия	01.04–05.04.2026	Акт приёмки

8. Порядок контроля и приёмки

Виды испытаний:
1. Предварительные — разработчиком (юнит-, интеграционное, нагрузочное тестирование);
2. Приёмочные — заказчиком в присутствии представителя (по Программе и методике испытаний);
3. Комплексные — при интеграции с ГИС «Образование».
Критерии приёмки:
— реализованы все функции п. 4.1;
— 100% critical и 95% high дефектов устранены (по отчёту тестирования);
— документация передана в полном объёме;
— подписан акт приёмки по форме Приложения Д.
Форма акта:
— Приложение Д к настоящему ТЗ;
— подписывается в течение 5 рабочих дней после завершения испытаний.

Приложения (фрагментарно)

Приложение А

Перечень нормативных документов
— ФГОС ООО (приказ Минобрнауки № 1577 от 17.12.2010);
— СанПиН 2.4.2.2821-10 (гигиенические требования);
— Методические рекомендации по проектной деятельности (Минпросвещение, 2024).

Приложение Б

BPMN-диаграмма процесса «Регистрация и защита проекта»
(файл: bpmn_suit-edu_v1.2.bpmn)

Приложение В

OpenAPI 3.0 спецификация

openapi: 3.0.3
info:
  title: SUIT-EDU-2025 API
  version: 1.0.0
paths:
  /api/v1/projects:
    post:
      summary: Создание проекта
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/ProjectCreate'
      responses:
        '201':
          description: Успешно создан

Приложение Г

JSON Schema для проекта

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "title": { "type": "string", "minLength": 5, "maxLength": 100 },
    "description": { "type": "string", "maxLength": 2000 },
    "tags": { "type": "array", "items": { "type": "string", "enum": ["python", "js", "scratch"] } }
  },
  "required": ["title", "description"]
}

Приложение Д

Форма акта приёмки
(образец: акт_приёмки_suit-edu.docx)

✅ Чек-лист по ГОСТ 19.201-78

(для полной проверки технического задания)

📌 Рекомендуется использовать в порядке нумерации.
✅ = выполнено | ❌ = нарушение | ⚪ = не применимо (но должно быть явно указано)

🔹 0. Общее оформление (п. 1.1–1.3)

№	Проверяемый элемент	Контрольный вопрос	Типичное нарушение
0.1	Формат листов	Используются ли листы формата A4 (ГОСТ 2.301-68)?	Использование Letter или произвольных размеров
0.2	Нумерация страниц	Проставлена ли нумерация в верхней части листа над текстом?	Нумерация внизу, сквозная с титульным листом
0.3	Титульный лист и лист утверждения	Соответствуют ли ГОСТ 19.104-78?	Отсутствует подпись утверждающего лица, не указаны реквизиты организации
0.4	Изменения	Все ли правки внесены через дополнения к ТЗ, прошедшие согласование/утверждение?	Прямое редактирование утверждённого документа без фиксации версии
0.5	Аннотация, содержание, лист изменений	Включены ли они по усмотрению (п. 1.2 допускает их отсутствие)?	Принудительное требование включать их — избыточно, но не ошибка

🔹 1. Введение (п. 2.1)

№	Обязательный элемент	Контрольный вопрос
1.1	Наименование ПО	Указано ли полное, однозначное наименование (без аббревиатур без расшифровки)?
1.2	Область применения	Описана ли сфера использования (например: «для школ с 5 по 11 класс», «в рамках ГИС „Образование“»)?
1.3	Объект автоматизации	Указан ли конкретный процесс или система, в которой будет применяться ПО?

⚠️ Ошибка: «Система для учёта» → ✖
✅ Исправление: «Система учёта индивидуальных учебных проектов учащихся в общеобразовательных организациях РФ».

🔹 2. Основания для разработки (п. 2.2)

№	Обязательный элемент	Контрольный вопрос
2.1	Документ(-ы)-основание	Перечислены ли реквизиты (№, дата, наименование)?
2.2	Организация-утвердитель	Указана ли организация, утвердившая документ-основание, и дата?
2.3	Наименование/условное обозначение темы	Присвоено ли теме уникальное обозначение (например: NIORK-2025-04-EDU)?

❗ Если документ-основание — внутренний, должен быть приложен (п. 2.8). Проверьте: есть ли в Приложениях копия?

🔹 3. Назначение разработки (п. 2.3)

№	Обязательный элемент	Контрольный вопрос
3.1	Функциональное назначение	Ясно ли, что делает система (например: «регистрирует, планирует, оценивает проекты»)?
3.2	Эксплуатационное назначение	Указано ли, где, когда, кем и в каком режиме используется ПО?

⚠️ Ошибка: «ПО повышает эффективность» → ✖ (это — ТЭП).
⚠️ Ошибка: «реализуется на Java» → ✖ (это — РД).

🔹 4. Требования к ПО (п. 2.4 — 8 подразделов!)

Все подразделы обязательны (кроме случаев явного «не применимо» с обоснованием).

№	Подраздел	Контрольный вопрос	Требуется ли явное указание «не применимо»?
4.1	Функциональные характеристики	Есть ли перечень функций с указанием входов, логики, выходов и временных ограничений?	Нет — если функции есть
4.2	Надёжность	Указаны ли: MTBF, MTTR, методы контроля, бэкапы?	Да — если не указано «не применимо»
4.3	Условия эксплуатации	Есть ли параметры среды (t, влажность), требования к персоналу и режиму?	Да — если не облачное SaaS
4.4	Технические средства	Указаны ли состав и параметры серверов/клиентов/сети?	Да — если развёртывание on-premise
4.5	Совместимость	Есть ли форматы, API, интеграции, требования к безопасности?	Нет — если система изолирована (редко)
4.6	Маркировка и упаковка	Указано ли «не применимо» для SaaS? Или требования для дистрибутива?	Да — всегда!
4.7	Транспортирование и хранение	Указано ли «не применимо» для SaaS? Или условия для физ. носителей?	Да — всегда!
4.8	Специальные требования	Есть ли локализация, доступность, лицензирование, UX-ограничения?	Нет — если нет особых условий

✅ Проверка полноты: посчитайте — должно быть ровно 8 подразделов. Даже если 4.6–4.7 = «не применимо», они должны присутствовать в тексте.

🔹 5. Требования к программной документации (п. 2.5а)

№	Элемент	Контрольный вопрос
5.1	Перечень документов	Указан ли полный предварительный состав документов (ПЗ, РД, ФО, ЭД и др.)?
5.2	Специальные требования	Есть ли указания: формат (PDF/HTML), версионирование, язык, требования к иллюстрациям?

⚠️ Ошибка: «по ЕСПД» → ✖
✅ Исправление: «в соответствии с ГОСТ 19.105-78, в формате PDF и Markdown, с версионной меткой vX.Y.Z+YYYYMMDD».

🔹 6. Технико-экономические показатели (п. 2.5)

№	Обязательный элемент	Контрольный вопрос
6.1	Экономическая эффективность	Есть ли оценка эффекта (время, деньги, ресурсы)?
6.2	Предполагаемая потребность	Указаны ли масштабы внедрения (пользователи, организации, регионы)?
6.3	Сравнение с аналогами	Есть ли качественное или количественное сравнение с существующими решениями?

⚪ Допустимо упрощение для внутренних/некоммерческих проектов, но не полное отсутствие.

🔹 7. Стадии и этапы разработки (п. 2.6)

№	Элемент	Контрольный вопрос
7.1	Стадии	Перечислены ли стадии по ЕСПД: ТЗ → ТП → РД → Внедрение?
7.2	Этапы и содержание	Указаны ли конкретные работы («проектирование БД», «нагрузочное тестирование»)?
7.3	Исполнители и сроки	Названы ли ответственные и даты/длительность?
7.4	Результаты этапов	Указаны ли итоговые документы/артефакты («API-spec v1.0», «акт пилота»)?

✅ Формат — таблица или нумерованный список с чёткой структурой.

🔹 8. Порядок контроля и приёмки (п. 2.7)

№	Элемент	Контрольный вопрос
8.1	Виды испытаний	Перечислены ли: предварительные, приёмочные, комплексные (если нужно)?
8.2	Критерии приёмки	Чётко ли прописаны условия успешной сдачи (например: «0 critical bugs»)?
8.3	Форма акта	Указана ли форма и срок подписания акта приёмки?

⚠️ Критическая ошибка: «по согласованию сторон» без конкретики → ✖
✅ Исправление: «по форме Приложения Д, в течение 5 раб. дней после завершения испытаний».

🔹 9. Приложения (п. 2.8)

№	Элемент	Контрольный вопрос
9.1	Ссылки в тексте	Все ли приложения упомянуты в основном тексте («см. Приложение Б»)?
9.2	Нумерация	Обозначены ли приложения заглавными буквами (А, Б, В…)?
9.3	Состав	Включены ли, при необходимости: обоснования, схемы, расчёты, копии документов-оснований?

📋 Итоговый балл проверки

Категория	Балл (0–2)	Комментарий
Формальное соответствие (разделы, оформление)	2 — все есть 1 — пропущено 1–2 элемента 0 — ≥3 нарушений	Основание для возврата в госэкспертизе
Содержательная полнота (требования, критерии)	2 — измеримо, однозначно 1 — есть расплывчатости 0 — много «быстро», «удобно», «современно»	Риски при приёмке
Юридическая корректность (основания, приёмка)	2 — реквизиты, акт, дополнения — всё чётко 0 — отсутствует документ-основание или критерии приёмки	Высокий риск спора

Рекомендации:

≥ 5 баллов — ТЗ готово к утверждению;
3–4 балла — требуется доработка по замечаниям;
≤ 2 балла — необходимо переписать.

Часть 1. Техническое задание​

1. Что такое техническое задание (ТЗ)?​

2. История и статус стандарта​

3. Область применения​

4. Основные принципы стандарта​

5. Обязательные разделы ТЗ по ГОСТ 19.201-78​

🧭 Часть 2: Пошаговое руководство по составлению ТЗ по ГОСТ 19.201-78​

🔢 2.1. Общие правила оформления​

📑 2.2. Пошаговое заполнение разделов ТЗ​

▶ Раздел 1. Введение (п. 2.1 стандарта)​

▶ Раздел 2. Основания для разработки (п. 2.2)​

▶ Раздел 3. Назначение разработки (п. 2.3)​

▶ Раздел 4. Требования к программе / программному изделию (п. 2.4 — самый объёмный)​

4.1. Требования к функциональным характеристикам (п. 2.4.1)​

4.2. Требования к надёжности (п. 2.4.2)​

4.3. Условия эксплуатации (п. 2.4.3)​

4.4. Требования к составу и параметрам технических средств (п. 2.4.4)​

4.5. Требования к информационной и программной совместимости (п. 2.4.5)​

4.6–4.8. Маркировка, транспортирование, хранение (пп. 2.4.6–2.4.7)​

4.9. Специальные требования (п. 2.4, конец списка)​

▶ Раздел 5. Требования к программной документации (п. 2.5а)​

▶ Раздел 6. Технико-экономические показатели (п. 2.5)​

▶ Раздел 7. Стадии и этапы разработки (п. 2.6)​

▶ Раздел 8. Порядок контроля и приёмки (п. 2.7)​

▶ Приложения (п. 2.8)​

🚫 Типичные ошибки при составлении ТЗ (и как их избежать)​

Пример​

Техническое задание

1. Введение​

2. Основания для разработки​

3. Назначение разработки​

3.1. Функциональное назначение​

3.2. Эксплуатационное назначение​

4. Требования к программе или программному изделию​

4.1. Требования к функциональным характеристикам​

4.2. Требования к надёжности​

4.3. Условия эксплуатации​

4.4. Требования к составу и параметрам технических средств​

4.5. Требования к информационной и программной совместимости​

4.6. Требования к маркировке и упаковке​

4.7. Требования к транспортированию и хранению​

4.8. Специальные требования​

5. Требования к программной документации​

6. Технико-экономические показатели​

7. Стадии и этапы разработки​

8. Порядок контроля и приёмки​

Приложения (фрагментарно)​

Приложение А​

Приложение Б​

Приложение В​

Приложение Г​

Приложение Д​

✅ Чек-лист по ГОСТ 19.201-78​

🔹 0. Общее оформление (п. 1.1–1.3)​

🔹 1. Введение (п. 2.1)​

🔹 2. Основания для разработки (п. 2.2)​

🔹 3. Назначение разработки (п. 2.3)​

🔹 4. Требования к ПО (п. 2.4 — 8 подразделов!)​

🔹 5. Требования к программной документации (п. 2.5а)​

🔹 6. Технико-экономические показатели (п. 2.5)​

🔹 7. Стадии и этапы разработки (п. 2.6)​

🔹 8. Порядок контроля и приёмки (п. 2.7)​

🔹 9. Приложения (п. 2.8)​

📋 Итоговый балл проверки​

Часть 1. Техническое задание

1. Что такое техническое задание (ТЗ)?

2. История и статус стандарта

3. Область применения

4. Основные принципы стандарта

5. Обязательные разделы ТЗ по ГОСТ 19.201-78

🧭 Часть 2: Пошаговое руководство по составлению ТЗ по ГОСТ 19.201-78

🔢 2.1. Общие правила оформления

📑 2.2. Пошаговое заполнение разделов ТЗ

▶ Раздел 1. Введение (п. 2.1 стандарта)

▶ Раздел 2. Основания для разработки (п. 2.2)

▶ Раздел 3. Назначение разработки (п. 2.3)

▶ Раздел 4. Требования к программе / программному изделию (п. 2.4 — самый объёмный)

4.1. Требования к функциональным характеристикам (п. 2.4.1)

4.2. Требования к надёжности (п. 2.4.2)

4.3. Условия эксплуатации (п. 2.4.3)

4.4. Требования к составу и параметрам технических средств (п. 2.4.4)

4.5. Требования к информационной и программной совместимости (п. 2.4.5)

4.6–4.8. Маркировка, транспортирование, хранение (пп. 2.4.6–2.4.7)

4.9. Специальные требования (п. 2.4, конец списка)

▶ Раздел 5. Требования к программной документации (п. 2.5а)

▶ Раздел 6. Технико-экономические показатели (п. 2.5)

▶ Раздел 7. Стадии и этапы разработки (п. 2.6)

▶ Раздел 8. Порядок контроля и приёмки (п. 2.7)

▶ Приложения (п. 2.8)

🚫 Типичные ошибки при составлении ТЗ (и как их избежать)

Пример

1. Введение

2. Основания для разработки

3. Назначение разработки

3.1. Функциональное назначение

3.2. Эксплуатационное назначение

4. Требования к программе или программному изделию

4.1. Требования к функциональным характеристикам

4.2. Требования к надёжности

4.3. Условия эксплуатации

4.4. Требования к составу и параметрам технических средств

4.5. Требования к информационной и программной совместимости

4.6. Требования к маркировке и упаковке

4.7. Требования к транспортированию и хранению

4.8. Специальные требования

5. Требования к программной документации

6. Технико-экономические показатели

7. Стадии и этапы разработки

8. Порядок контроля и приёмки

Приложения (фрагментарно)

Приложение А

Приложение Б

Приложение В

Приложение Г

Приложение Д

✅ Чек-лист по ГОСТ 19.201-78

🔹 0. Общее оформление (п. 1.1–1.3)

🔹 1. Введение (п. 2.1)

🔹 2. Основания для разработки (п. 2.2)

🔹 3. Назначение разработки (п. 2.3)

🔹 4. Требования к ПО (п. 2.4 — 8 подразделов!)

🔹 5. Требования к программной документации (п. 2.5а)

🔹 6. Технико-экономические показатели (п. 2.5)

🔹 7. Стадии и этапы разработки (п. 2.6)

🔹 8. Порядок контроля и приёмки (п. 2.7)

🔹 9. Приложения (п. 2.8)

📋 Итоговый балл проверки