Структура технического задания на разработку веб-сервиса: обязательные разделы и примеры

ГОСТ 34.602-2020 фиксирует 10 обязательных разделов ТЗ и 6 характеристик качественного требования: единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность. Полнота документа проверяется по этим координатам.

Ниже — разбор обязательных разделов ТЗ на веб-сервис по ГОСТ 34.602-2020, принципов описания API по OpenAPI Specification 3.2.0 и модели качества по ISO/IEC 25010:2023. Все формулировки — на языке проверяемых метрик.

Юридическая и практическая база

Два национальных стандарта покрывают смежные, но разные области:

Ни один из ГОСТов не обязывает применять себя к произвольному коммерческому веб-сервису. Решение принимается по договору, отраслевым требованиям и уровню регулирования заказчика — госсектор, финсектор, медицина, обработка ПДн.

Гибкие альтернативы и их стыковка с ГОСТ

Для коммерческих проектов без жёсткого регулирования ГОСТ остаётся эталоном структуры, а не обязательной формой. Распространённые альтернативы и их роль в ТЗ:

• User Story с Acceptance Criteria в нотации Given/When/Then — для функциональных требований
• PRD с приоритетами RICE или MoSCoW — для scope и backlog
• OpenAPI Specification — для контрактов HTTP API
• Технические RFC внутри репозитория — для архитектурных решений (ADR)

Рекомендация архитектурного комитета: ядро ТЗ держать в структуре ГОСТ 34.602-2020, расширяя гибкими блоками — Product Backlog, Definition of Done, описание CI/CD-пайплайна. Это снимает риск vendor lock-in на конкретную методологию и сохраняет юридическую значимость документа при возможных спорах.

Формат ТЗ — переменная. Структура требований — константа.

Фундаментальные разделы ТЗ по ГОСТ 34.602-2020

Стандарт перечисляет 10 обязательных разделов. Если требований нет, раздел не удаляется — в нём фиксируется запись об их отсутствии. Допускается оформление приложений, слияние и деление подразделов.

Состав базового ТЗ:

1. Общие сведения

2. Цели и назначение

3. Характеристика объекта автоматизации

4. Требования к системе

5. Состав и содержание работ

6. Порядок разработки

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

8. Подготовка объекта к вводу

9. Документирование

10. Источники разработки

Раздел «Общие сведения»

Предмет фиксации:

• Полное наименование системы, заказчика, разработчика
• Документы-основания: договор, распоряжение, ТЭО, служебная записка
• Плановые даты начала и завершения работ
• Источники и порядок финансирования
• Перечень смежных систем, с которыми сервис взаимодействует

Раздел «Цели и назначение»

Формулируется в измеримых показателях:

• Целевые значения технических, технологических, производственно-экономических параметров
• Критерии оценки достижения целей с методикой замера
• Границы применимости: in-scope и out-of-scope

Цель без числа — пожелание. Цель с числом — требование.

Раздел «Характеристика объекта автоматизации»

Описание AS-IS и TO-BE. Для веб-сервиса сюда выносятся:

• Текущие процессы, подлежащие автоматизации
• Узкие места существующей инфраструктуры
• Объём данных, подлежащих миграции
• Регламенты взаимодействия со смежными подразделениями

Раздел «Требования к системе»

Самый объёмный раздел. Включает четыре подраздела:

• Структура системы: способы информационного взаимодействия компонентов, взаимосвязи со смежными системами, требования к интероперабельности и совместимости, способы обмена информацией
• Функции (задачи): для каждой функции — результат выполнения, временной регламент, формат выходной информации, точность, время выполнения, требования к одновременности функций, достоверности результатов, критерии отказов
• Виды обеспечения: информационное, лингвистическое, программное, техническое, организационное
• Общие технические требования: производительность, доступность, отказоустойчивость, безопасность

Раздел «Порядок контроля и приёмки»

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

Практические элементы раздела:

• Виды испытаний: интеграционные, нагрузочные, приёмочные, по безопасности
• Методики: сценарии тестов, целевые метрики, описание среды
• Порядок устранения несоответствий: SLA на исправление, ответственные стороны
• Критерии приёма: числовые пороги по каждой метрике, автоматизированный отчёт

Формулирование требований: проверяемые критерии

Требования должны быть максимально детализированы и однозначны. Шесть характеристик качественного требования — единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность — задают контрольный фильтр на этапе согласования ТЗ.

Антипаттерны

Неприемлемые формулировки:

• «Быстрый интерфейс» — без числового критерия и условий измерения
• «Высокая доступность» — без значения uptime и допустимого окна даунтайма
• «Надежная защита» — без перечня конкретных мер и угроз
• «Удобный дизайн» — без метрик типа SUS, task success rate, time-to-first-action

Корректная конструкция требования

Формат: [Объект] + [Свойство] + [Значение] + [Условие измерения] + [Критерий приёмки].

Примеры:

• API endpoint POST /orders: время отклика p95 ≤ 300 мс при нагрузке 500 RPS, метод измерения — k6 в staging-окружении, приёмка — автоматизированный отчёт за 30 суток подряд
• Доступность сервиса: uptime ≥ 99.95% за календарный месяц, окно планового обслуживания исключено из расчёта, источник — синтетический мониторинг Prometheus + Blackbox-exporter
• RPO базы данных: ≤ 5 минут, реализация — WAL-репликация на standby, проверка — квартальный drill с замером реальной точки восстановления
• RTO сервиса: ≤ 15 минут, реализация — blue-green deploy, проверка — chaos engineering в staging-окружении, ежеквартально

Интеграции и безопасность: OpenAPI 3.2.0 и OWASP API Security Top 10 2023

Раздел «Структура системы» по ГОСТ 34.602-2020 обязывает описывать способы информационного взаимодействия компонентов, взаимосвязи со смежными системами и способы обмена информацией. Для HTTP API индустриальным стандартом описания выступает OpenAPI Specification.

OpenAPI Specification 3.2.0

Опубликована 19.09.2025. Текущая стабильная версия описания HTTP API. Документ — JSON или YAML; структура предусматривает переиспользуемые схемы, параметры, тела запросов, ответы и схемы безопасности. Машиночитаемое описание используется для генерации клиентов, серверных stub'ов, тестов и пользовательской документации.

Минимальный набор блоков для веб-сервиса:

OpenAPI — стандарт описания, а не юридическое требование. Решение о его применении принимается инженерно: контракт API версионируется вместе с продуктом, откатывается без потери совместимости и служит источником истины для backend, frontend и интеграционных партнёров.

OWASP API Security Top 10 2023

Актуальный релиз опубликован 03.07.2023. 3 из первых 5 категорий риска связаны с авторизацией. Для раздела безопасности ТЗ это прямое основание выделить:

• BOLA (Broken Object Level Authorization) — проверка авторизации на уровне объекта, а не только маршрута
• Broken Authentication — управление сессиями, ротация токенов, защита от перебора
• Broken Object Property Level Authorization — фильтрация полей DTO по роли и scope

Минимальные требования к ТЗ по безопасности API:

• Перечень ролей и scope-ов с привязкой к матрице доступа
• Политика scopes для каждого endpoint, включая методы GET, POST, PATCH, DELETE
• Срок жизни и порядок ротации access- и refresh-токенов
• Требования к логированию: перечень событий, объём ПДн, срок хранения
• Требования к разграничению доступа на уровне объекта (object-level authorization)

Соответствие OWASP API Top 10 не означает автоматического выполнения регуляторных требований. 152-ФЗ, отраслевые стандарты и политики заказчика фиксируются отдельным разделом ТЗ и при необходимости выносятся в приложения.

OWASP определяет базовый минимум. Регулятор определяет обязательный порог.

Модель качества продукта по ISO/IEC 25010:2023

Опубликована в ноябре 2023. Заменила ISO/IEC 25010:2011. Определяет 9 характеристик качества ИКТ-продукта. Каждая характеристика используется как координата раздела «Общие технические требования».

Каждой характеристике — числовое значение, методика замера, регулярность проверки и ответственный владелец. Без такой привязки характеристика остаётся декларацией.

Сопутствующие требования к инфраструктуре и поставке

Раздел «Виды обеспечения» по ГОСТ 34.602-2020 требует перечислить программное, техническое и организационное обеспечение. Для веб-сервиса сюда включаются:

• Стек: язык, фреймворк, СУБД, очереди, кэш, объектное хранилище
• Контейнеризация и оркестрация: docker-образы, k8s-манифесты или альтернативы
• CI/CD: этапы сборки, тестов, сканирования, деплоя; среды dev/staging/prod
• Мониторинг и observability: метрики, логи, трейсы; набор дашбордов
• Резервное копирование: периодичность, срок хранения, метод проверки
• Управление конфигурацией: secrets manager, переменные окружения, фичефлаги

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

Чек-лист ТЗ на веб-сервис

• Раздел «Общие сведения» — заказчик, разработчик, документы-основания, сроки, источники финансирования, перечень смежных систем
• Раздел «Цели и назначение» — целевые метрики, in-scope, out-of-scope, методика замера
• Раздел «Характеристика объекта автоматизации» — AS-IS, TO-BE, узкие места, объём миграции данных
• Раздел «Структура системы» — компоненты, взаимодействия, смежные системы, формат обмена
• Раздел «Функции» — для каждой функции результат, временной регламент, формат выхода, точность, критерии отказа
• Раздел «Виды обеспечения» — стек с версиями, контейнеризация, оркестрация, CI/CD, мониторинг, резервное копирование, secrets
• Раздел «Общие технические требования» — числовые SLA по каждой из 9 характеристик ISO/IEC 25010:2023
• Раздел «Интеграции» — спецификация API по OpenAPI 3.2.0, контракты, политика версионирования
• Раздел «Безопасность» — OWASP API Security Top 10 2023 + требования регуляторов (152-ФЗ, отраслевые нормативы)
• Раздел «Порядок приёмки» — виды испытаний, методики, критерии приёма, ответственные
• Приложения — схемы БД, ER-диаграммы, sequence-диаграммы C4, шаблоны отчётов
• Контроль качества каждого требования по 6 критериям ГОСТ 34.602-2020: единичность, непротиворечивость, актуальность, выполнимость, проверяемость, однозначность

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

Материалы сети: lawebbox.com.