EN RU SR

Как написать TRD: руководство по техническим требованиям

TRD, или Technical Requirements Document, определяет технологическую среду, необходимую для работы системы. Если PRD описывает, что строить, а FRD — как система должна вести себя, то TRD определяет инфраструктуру, оборудование, программное обеспечение и платформенные требования, от которых зависит система. Он отвечает на вопрос: какой технический фундамент нужен этой системе для корректной работы?

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

Key insight

TRD — не о том, что ПО делает (это FRD) и не о том, насколько хорошо оно работает (это секция NFR в SRD). TRD специфицирует техническую экосистему — серверы, сети, базы данных, операционные системы, сторонние инструменты и платформенные сервисы, которые требуются системе.

Кто пишет и для кого

Владелец TRD — обычно системный архитектор, инженер инфраструктуры, DevOps-лид или технический проектный менеджер.

ЧитательЧто ищет в документе
DevOps / SREСпецификации серверов, облачные сервисы, сетевые требования, инструменты мониторинга
Бэкенд-инженерыТребования к БД, версии рантаймов, ограничения зависимостей
Команда безопасностиСтандарты шифрования, контроль доступа, требования комплаенса
ЗакупкиСпецификации оборудования, стоимость лицензий, требования к вендорам
Проектные менеджерыТехнологические риски, зависимости, сроки подготовки инфраструктуры

Когда нужен TRD — и когда не нужен

TRD нужен, когда:

  • Проект требует закупки специфического оборудования (серверы on-premise, IoT-устройства, специализированное оборудование)
  • Решения по облачной инфраструктуре должны быть задокументированы и утверждены до провижининга
  • Несколько команд или подрядчиков должны согласовать общий технологический стек
  • Комплаенс или безопасность диктуют конкретные технологические решения
  • Вы мигрируете с одной платформы на другую

TRD не нужен, когда:

  • Команда имеет полную автономию в технологических решениях и инфраструктура уже готова
  • Проект работает на стандартизированной платформе
  • PRD или SRD уже покрывает технологические ограничения достаточно подробно

Что содержит TRD

Основные секции

TRD обычно включает шесть секций:

  1. Введение — назначение документа, скоуп системы, связь с другими документами и определения терминов.

  2. Требования к оборудованию — спецификации физических серверов, сетевого оборудования, систем хранения, IoT-устройств или пользовательских устройств.

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

  4. Требования к платформе и инфраструктуре — облачные сервисы, сетевая конфигурация, DNS, CDN, контейнерная оркестрация, CI/CD-пайплайн, спецификации сред (разработка, стейджинг, продакшен).

  5. Безопасность и комплаенс — стандарты шифрования (в покое и при передаче), инфраструктура аутентификации и авторизации, сегментация сети, инструменты сканирования уязвимостей, фреймворки комплаенса (SOC 2, HIPAA, GDPR, PCI-DSS).

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

TRD и другие документы требований

TRD работает параллельно с SRD, а не последовательно:

MRD → BRD → PRD → FRD → SRD
                           ↑
                          TRD (инфраструктурный слой)

SRD говорит: «система должна поддерживать 10 000 одновременных пользователей». TRD говорит: «для поддержки 10 000 одновременных пользователей системе нужны три инстанса c6i.4xlarge с автомасштабированием, настроенным на добавление ёмкости при 70% CPU».

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

1. Смешение функциональных и технических требований. «Система должна позволять загружать файлы до 100MB» — функциональное требование (FRD). «Система требует S3-совместимое объектное хранилище с лимитом 100MB на реверс-прокси» — техническое требование (TRD).

2. Указание технологий без обоснования. «Использовать Kafka» — не требование. «Система требует распределённый брокер сообщений с гарантией at-least-once, возможностью replay и пропускной способностью 50 000 сообщений/сек» — требование.

3. Игнорирование паритета сред. TRD должен специфицировать требования для всех сред — разработки, стейджинга и продакшена.

4. Отсутствие планирования ёмкости. TRD без проекций ёмкости устаревает в момент роста трафика. Включайте ожидаемую нагрузку при запуске и прогноз роста (6 месяцев, 12 месяцев).

5. Забытые лицензии. Коммерческие лицензии на ПО, SaaS-подписки и стоимость облачных сервисов принадлежат TRD.

Ресурсы