коротко

SRS (Software Requirements Specification) — это полный документ требований к системе: цель и границы, акторы, функциональные требования с ID, нефункциональные требования с числами, внешние интерфейсы, ограничения и открытые вопросы. Он отвечает на вопрос «что мы строим и каким оно должно быть», но не «как это сделать в коде». От лёгкой спеки на фичу SRS отличается охватом — это документ на систему целиком; от user story — формальностью и нумерацией. Классическую структуру задал стандарт IEEE 830, сегодня живёт его наследник ISO/IEC/IEEE 29148. Ниже — целый пример SRS на сервис бронирования переговорок, который можно скопировать как шаблон.

Однажды я пришёл на проект, где «требования» были разбросаны по сорока сообщениям в чате, трём презентациям и устной памяти продакта. Каждый разработчик помнил свою версию, и любой спор заканчивался фразой «ну мы же договаривались». Я потратил неделю, собрал всё в один документ с нумерованными требованиями — и половина споров просто исчезла, потому что теперь можно было ткнуть пальцем в FR-7 и сказать «вот, здесь написано». Это и был мой первый настоящий SRS. С тех пор я отношусь к нему не как к бюрократии, а как к единственному месту, где живёт правда о системе.

Что такое SRS и чем он не является

SRS — это документ, который полностью описывает что должна делать система и насколько хорошо, но молчит про как это реализовано. Это водораздел: SRS — про требования, а «как именно построить» — это уже дизайн, который живёт в HLD и LLD. Если в SRS появилось «используем PostgreSQL с индексом по полю created_at» — вы заехали в чужую зону, это решение, а не требование. Требование звучит иначе: «поиск брони по дате должен отрабатывать за < 300 мс».

SRS легко спутать с тремя соседними вещами, поэтому разведём их сразу.

ДокументОхватОтвечает на вопрос
User storyОдин маленький кусок ценностиЧто нужно одному пользователю и зачем
Спека на фичу (ТЗ)Одна фича целикомЧто и как сделать в этой фиче
SRSСистема целикомЧто система делает и каким должна быть
HLD / LLDСистема целикомКак система устроена внутри

То есть SRS и user story не конкуренты, а разные масштабы. В Agile-командах SRS целиком пишут редко — там живут user story и use case и лёгкая спека на фичу. SRS всплывает там, где система большая, заказчик внешний, цена ошибки высокая или нужен формальный документ под договор. Понимать его структуру полезно в любом случае: даже лёгкая спека — это ужатый SRS.

SRS = что, дизайн = как

Главная дисциплина при написании SRS — не сползать в решения. Каждый раз, когда хочется написать имя технологии, название таблицы или алгоритм, спросите себя: это требование к системе или способ его выполнить? Если способ — выньте и положите в HLD/LLD. SRS должен пережить смену стека.

Классическая структура SRS

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

  • 1. Введение — цель документа, охват системы (scope), глоссарий терминов и сокращений, ссылки на другие документы.
  • 2. Общее описание — контекст системы, основные функции крупными мазками, акторы и их роли, допущения и зависимости.
  • 3. Функциональные требования — что система делает, по пунктам с уникальными ID (FR-1, FR-2…).
  • 4. Нефункциональные требования — производительность, доступность, безопасность, и обязательно с числами.
  • 5. Внешние интерфейсы — API, интеграции, UI, аппаратные стыки.
  • 6. Ограничения — технологические, юридические, бюджетные рамки, которые сужают пространство решений.
  • 7. Открытые вопросы — что ещё не решено и кто решает.

Разница между третьим и четвёртым разделом — это разница между функциональными и нефункциональными требованиями: FR описывает что система делает («пользователь бронирует переговорку»), NFR — насколько хорошо («бронь сохраняется за < 1 секунды, система доступна 99.9%»). Новички почти всегда раздувают FR и забывают NFR, а потом удивляются, почему «вроде всё работает, но тормозит и падает».

Полный пример: SRS на сервис бронирования переговорок

Вот сквозной пример — компактный, но настоящий. Его можно скопировать и переделать под свою систему: структура от этого не сломается.

SRS: Сервис бронирования переговорных комнат «MeetRoom»
Версия 1.0 · Автор: Н. Миронов · Статус: на согласовании

──────────────────────────────────────────────
1. ВВЕДЕНИЕ
1.1 Цель документа
    Описать требования к сервису MeetRoom — внутреннему
    веб-сервису бронирования переговорных комнат офиса.
1.2 Scope (в границах)
    - Просмотр доступности комнат по дате и времени
    - Создание, изменение и отмена брони
    - Уведомление участников о брони
1.3 Out-of-scope (вне границ)
    - Бронирование рабочих мест и парковки
    - Интеграция с системой контроля доступа (СКУД) — этап 2
    - Оплата платных комнат
1.4 Глоссарий
    Бронь   — резерв комнаты на интервал времени за сотрудником
    Слот    — минимальный интервал бронирования, 30 минут
    Актор   — роль, взаимодействующая с системой

──────────────────────────────────────────────
2. ОБЩЕЕ ОПИСАНИЕ
2.1 Акторы
    - Сотрудник: бронирует, меняет и отменяет свои брони
    - Администратор: управляет списком комнат и их атрибутами
    - Календарь (внешняя система): принимает события о бронях
2.2 Допущения и зависимости
    - Аутентификация сотрудников через корпоративный SSO (OIDC)
    - Список комнат ведётся в MeetRoom, не импортируется извне
    - Часовой пояс системы — Europe/Moscow

──────────────────────────────────────────────
3. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
FR-1  Просмотр доступности
      Сотрудник выбирает дату и видит сетку комнат по слотам;
      занятые слоты помечены, свободные доступны для выбора.
FR-2  Создание брони
      Сотрудник выбирает свободный слот, указывает тему и
      число участников. Система проверяет, что слот свободен и
      вместимость комнаты >= числа участников, и создаёт бронь.
FR-3  Защита от двойного бронирования
      Если на момент сохранения слот уже занят другой бронью,
      система отклоняет запрос с сообщением «Слот уже занят»
      и предлагает ближайшие свободные слоты.
FR-4  Отмена брони
      Сотрудник отменяет только свою бронь. Отменённый слот
      немедленно становится доступен другим. Чужие брони
      отменять нельзя (кроме администратора).

──────────────────────────────────────────────
4. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
NFR-1 Производительность
      Сетка доступности на день (до 50 комнат) отображается
      за < 800 мс при 200 одновременных пользователях.
NFR-2 Доступность
      Сервис доступен 99.5% в рабочие часы (08:00–20:00 МСК),
      что эквивалентно не более ~18 минут простоя в месяц.
NFR-3 Надёжность данных
      Двойное бронирование одного слота недопустимо при любой
      конкурентной нагрузке (строгая консистентность брони).
NFR-4 Безопасность
      Доступ только аутентифицированным сотрудникам через SSO;
      сотрудник видит и меняет только свои брони.

──────────────────────────────────────────────
5. ВНЕШНИЕ ИНТЕРФЕЙСЫ
5.1 API (REST)
    GET  /rooms?date=2026-05-24      — сетка доступности
    POST /bookings                   — создать бронь
    DELETE /bookings/{id}            — отменить бронь
5.2 Интеграции
    - SSO: OpenID Connect, провайдер — корпоративный Keycloak
    - Календарь: исходящий вебхук booking.created / booking.cancelled

──────────────────────────────────────────────
6. ОГРАНИЧЕНИЯ
    - Только веб (десктоп + мобильный браузер), нативных
      приложений на этом этапе нет
    - Хранение персональных данных — на серверах в РФ (152-ФЗ)
    - Срок MVP — 2 месяца

──────────────────────────────────────────────
7. ОТКРЫТЫЕ ВОПРОСЫ
    OQ-1  Можно ли бронировать на нерабочие часы?  — ждём ответ HR
    OQ-2  Нужен ли лимит броней на сотрудника в день? — продакт
    OQ-3  Что делать с бронями уволенного сотрудника? — не решено

Обратите внимание на детали, которые отличают рабочий SRS от учебного. Out-of-scope прописан явно — это снимает половину споров на приёмке. У каждого требования уникальный ID, и на него можно сослаться в баг-трекере, тесте, обсуждении. NFR несут числа, а не слова: «99.5%» вместо «высокая доступность», «< 800 мс» вместо «быстро». А FR-3 («защита от двойного бронирования») — это тот самый случай, когда требование вскрывает дыру: в первой версии его не было, и оно появилось ровно потому, что при написании SRS возник вопрос «а что если два человека жмут на один слот одновременно?».

Открытые вопросы — самый честный раздел

Раздел «Открытые вопросы» с нумерацией (OQ-1, OQ-2) — недооценённая часть SRS. Он превращает «мы это потом решим» в трекаемый список с ответственным. Я довожу его до пустого перед стартом разработки: каждый OQ должен либо закрыться решением, либо явно стать out-of-scope. Незакрытый открытый вопрос — это бомба замедленного действия в спринте.

Откуда это взялось

Структуру SRS канонизировал стандарт IEEE 830 «Recommended Practice for Software Requirements Specifications», редакция 1998 года (первая версия — ещё 1984-й). Именно он задал разделы «введение / общее описание / конкретные требования» и идею делить требования на функциональные и нефункциональные. В 2011-м IEEE 830 официально заменили на ISO/IEC/IEEE 29148 — объединённый стандарт по работе с требованиями, который вобрал в себя не только структуру документа, но и процессы их сбора и сопровождения. На практике большинство до сих пор говорит «по IEEE 830», потому что именно его структура въелась в шаблоны.

Как это спрашивают на собесе

«Чем SRS отличается от user story?» — проверяют, понимаете ли разницу масштабов (система целиком против одного кусочка ценности) и не путаете ли формальность с сутью. «Какие разделы должны быть в SRS?» — ждут не зубрёжку по пунктам, а понимание, что должны быть и FR, и NFR, и границы (scope/out-of-scope). «Приведите пример хорошего и плохого нефункционального требования» — здесь топят тех, кто говорит «система должна быть быстрой»; хороший ответ содержит число и условие («ответ < 300 мс при 100 RPS»).

Частые вопросы

Чем SRS отличается от ТЗ?

В русской традиции «ТЗ» — размытый термин: им называют и лёгкую спеку на одну фичу, и толстый документ на всю систему. SRS — это конкретный жанр: полный документ требований к системе целиком, со структурой по IEEE 830 / ISO 29148. Можно сказать, что SRS — это формализованное, полное ТЗ на систему. Спека на отдельную фичу — это его уменьшенная версия с тем же набором разделов.

Нужен ли SRS в Agile-команде?

Полный SRS — редко. В Agile система описывается через поток user story и use case, а тяжёлый документ на всё противоречит идее коротких итераций. Но структура SRS остаётся полезной как чек-лист: даже эпик или фича выигрывают, если по ним явно прописаны границы, акторы, FR, NFR и открытые вопросы. SRS целиком оправдан там, где система большая, заказчик внешний или цена ошибки высока (медицина, финансы, госзаказ).

Как нумеровать требования в SRS?

Простыми устойчивыми ID: FR-1, FR-2 для функциональных, NFR-1 для нефункциональных, OQ-1 для открытых вопросов. Главное правило — ID не переиспользовать: если требование удалили, его номер не отдают новому, иначе ссылки в багах и тестах начнут врать. Удобно, когда ID говорит о типе (FR/NFR), это сразу подсказывает читателю природу требования.