SRS (спецификация требований к ПО): полное руководство и шаблоны

SRD, или Software Requirements Document (также называемый SRS — Software Requirements Specification) — это инженерный чертёж для создания программного обеспечения. Он определяет, что ПО должно делать, как оно должно работать, какие ограничения на него действуют и как компоненты связаны между собой. Там, где PRD описывает продуктовой команде, что строить, а FRD задаёт поведение системы, SRD даёт инженерам полную техническую картину для написания кода, проектирования архитектуры и планирования тестирования.

SRD отвечает на один вопрос: если передать этот документ команде разработки без дополнительного контекста, смогут ли они построить систему?

Key insight

SRD — самый полный требований-документ в цепочке. Он объединяет функциональное поведение (что система делает), нефункциональные ограничения (насколько хорошо она это делает), архитектуру (как она построена) и модели данных (что она хранит). Это единый источник истины для инженерной команды.

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

Владелец SRD — обычно системный архитектор, технический лид, ведущий инженер или системный аналитик — специалист, понимающий и бизнес-домен, и техническую реализацию.

Читатель	Что ищет в документе
Бэкенд-инженеры	Функциональные требования, контракты API, модели данных, системные интерфейсы
Фронтенд-инженеры	UI-спецификации, правила валидации, сообщения об ошибках, управление состоянием
QA / тест-инженеры	Критерии приёмки, нефункциональные цели, тестовые сценарии
DevOps / SRE	Целевые показатели производительности, ограничения инфраструктуры, требования к наблюдаемости
Архитекторы	Границы системы, точки интеграции, технологические ограничения
Проектные менеджеры	Скоуп, зависимости, факторы риска

Key insight

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

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

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

Проект включает несколько инженерных команд или внешних подрядчиков, которым нужна общая техническая спецификация
Регуляторные требования или требования комплаенса предполагают аудируемые, отслеживаемые требования (здравоохранение, финансы, госсектор)
У системы значительные нефункциональные требования — SLO производительности, стандарты безопасности, политики хранения данных
Нужен формальный контракт между стейкхолдерами и инженерной командой о том, что будет поставлено
Система интегрируется с множеством внешних сервисов и контракты данных должны быть определены заранее

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

Маленькая кросс-функциональная команда работает короткими спринтами с непрерывной поставкой — user stories с критериями приёмки достаточно
PRD и FRD уже покрывают функциональные и нефункциональные требования с достаточной детализацией
Вы строите прототип или proof of concept, где формальная спецификация замедлит обучение
Проект — один сервис, одна команда с прямым доступом к стейкхолдерам

На практике регулируемые отрасли (банковская сфера, здравоохранение, оборона, госконтракты) почти всегда требуют формальный SRD. Стартапы и agile-команды часто включают детали уровня SRD в PRD или FRD.

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

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

Хорошо структурированный SRD следует стандарту IEEE 830 (обновлённому как ISO/IEC/IEEE 29148) с современными адаптациями. Обычно включает восемь секций:

Введение — назначение документа, скоуп ПО, определения и аббревиатуры, ссылки на связанные документы (PRD, BRD, архитектурные документы), обзор структуры документа. Введение устанавливает чёткие границы: что покрывает этот SRD и что явно исключает.
Общее описание — контекст продукта (как это ПО вписывается в более крупную систему или заменяет существующую), классы пользователей и их характеристики, операционная среда (браузеры, устройства, ОС, облачные провайдеры), ограничения проектирования и реализации (технологический стек, регуляторные требования, бюджет), допущения и зависимости.
Функциональные требования — детальное описание того, что система делает. Каждое требование имеет уникальный ID, описание с использованием «shall» (обязательно) или «should» (опционально), входы, выходы, бизнес-правила и обработку ошибок.
Нефункциональные требования — измеримые цели по производительности, безопасности, масштабируемости, надёжности, юзабилити и поддерживаемости. Каждое требование квантифицировано: «Система должна отвечать на 95% API-запросов в пределах 200мс» вместо «Система должна быть быстрой».
Требования к внешним интерфейсам — как система взаимодействует с пользователями (UI-спецификации), с другими внутренними системами (API, очереди сообщений, шины событий), с внешними сервисами (сторонние интеграции) и с оборудованием (при необходимости).
Требования к данным — модели данных (сущности, связи, ограничения), словарь данных (имена полей, типы, правила валидации), политики хранения и архивации данных, планы миграции из существующих систем, требования по приватности и комплаенсу.
Архитектура системы — высокоуровневые диаграммы архитектуры, описания компонентов, решения по технологическому стеку, топология развёртывания, требования к наблюдаемости (логирование, мониторинг, алертинг) и контракты API.
Приложения — глоссарий, диаграммы вариантов использования, диаграммы состояний, вайрфреймы, журнал изменений, открытые вопросы (TBD) и страница подписей.

Key insight

Ценность SRD — в секциях 4-7. Функциональные требования (секция 3) пересекаются с FRD. Отличие SRD в том, что он добавляет нефункциональные спецификации, контракты интерфейсов, модели данных и архитектуру — технический контекст, необходимый разработчикам помимо описания поведения системы.

Нефункциональные требования: правило измеримости

Нефункциональные требования — место, где большинство SRD проваливается. Расплывчатые NFR порождают неизмеримые результаты.

Плохие NFR:

«Система должна быть быстрой» — насколько быстрой?
«Система должна быть безопасной» — от чего?
«Система должна масштабироваться» — до какого объёма?

Хорошие NFR:

ID	Категория	Требование	Цель
NFR-001	Производительность	Система должна отвечать на 95% API-запросов в пределах 200мс на P95	200мс P95
NFR-002	Производительность	Система должна поддерживать 10 000 одновременных пользователей без деградации	10K одновременно
NFR-003	Доступность	Система должна поддерживать 99.9% аптайм, измеряемый ежемесячно	99.9% SLA
NFR-004	Безопасность	Система должна шифровать все данные в покое с использованием AES-256	AES-256
NFR-005	Безопасность	Система должна требовать MFA для всех администраторских аккаунтов	100% MFA для админов
NFR-006	Масштабируемость	Система должна обрабатывать 10-кратное увеличение ежедневных транзакций в течение 30 минут автомасштабирования	10x burst
NFR-007	Хранение данных	Система должна хранить логи транзакций 7 лет согласно регуляторным требованиям	7 лет

Правило: если вы не можете написать тест, который проверяет, выполняется требование или нет — перепишите требование.

Вариации SRD

Вариация	Когда использовать	Ключевая особенность
Стандартный SRD	Энтерпрайз, регулируемые отрасли, большие команды	Полная восьмисекционная структура, выровнена по IEEE 830
Agile SRS	Agile-команды, итеративная разработка	Лёгкий, живой документ, модульный по фичам
Комбинированный PRD+SRD	Маленькие команды, где продукт и инженерия пересекаются	Объединяет продуктовый контекст с технической спецификацией

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

SRD находится на техническом конце цепочки требований:

MRD → BRD → PRD → FRD → SRD

Документ	Вопрос	Уровень
MRD	«Что нужно рынку?»	Стратегический
BRD	«Зачем бизнесу инвестировать?»	Стратегический
PRD	«Что мы строим?»	Тактический
FRD	«Как система должна вести себя?»	Технический
SRD	«Каковы полные технические спецификации?»	Технический

Связь FRD и SRD — наиболее часто путаемая:

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

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

1. Копирование PRD. SRD — это не PRD с добавленным техническим жаргоном. PRD определяет, что строить с продуктовой точки зрения. SRD специфицирует, как строить с инженерной точки зрения, включая цели производительности, меры безопасности и архитектурные решения.

2. Пропуск нефункциональных требований. Функциональные требования получают внимание, потому что соответствуют фичам. Нефункциональные (производительность, безопасность, масштабируемость) обнаруживаются в продакшене, когда система падает под нагрузкой.

3. Невозможность верификации требований. Каждое требование должно иметь соответствующий тест. «Система должна быть надёжной» — теста нет. «Система должна восстановиться после failover базы данных в течение 30 секунд» — тест чёткий.

4. Одноразовый документ. Требования эволюционируют. SRD, написанный один раз и никогда не обновляемый, становится обузой. Храните его в системе контроля версий рядом с кодом.

5. Спецификация реализации вместо требований. «Система должна использовать PostgreSQL 16» — решение о реализации. «Система должна хранить данные в реляционной БД с гарантиями ACID и поддержкой полнотекстового поиска» — требование.

6. Нет трассируемости. Каждое функциональное требование должно прослеживаться к бизнес-потребности (BRD/PRD) и вперёд — к тестовому кейсу.

Тренд 2026: SRD как контекст для AI-агентов разработки

В 2026 году SRD обслуживает инженеров и AI-агентов одновременно. AI-агенты в Cursor, Claude Code и GitHub Copilot Workspace потребляют структурированные документы требований для генерации кода, тестов и архитектурных каркасов.

Это меняет практики SRD:

SRD хранится в репозитории как markdown-файлы, а не во внешних инструментах, чтобы AI-агенты могли читать требования вместе с кодовой базой.
Нефункциональные требования включают явные критерии приёмки, которые непосредственно транслируются в автоматизированные тесты.
Архитектурные секции включают контракты API в машиночитаемых форматах (OpenAPI, AsyncAPI).

Ресурсы

Шаблоны SRD — Standard и Agile, готовые к использованию
Генератор SRD — создайте SRD с помощью AI
Agile SRS — облегчённый вариант для agile-команд
FRD — полное руководство — спецификация поведения, которая питает SRD
PRD vs BRD vs FRD — сравнение документов требований
Навигатор документов — найдите нужный тип документа