Во многих проблемных проектах ошибка начинается не в коде. Она появляется раньше — в момент, когда бизнес говорит про результат, а команда слышит набор общих пожеланий.

Заказчик говорит: «нужен быстрый заказ». Менеджер понимает это как отдельную кнопку. Аналитик — как упрощенный сценарий оформления. Разработчик — как короткий путь в корзину. Все вроде делают одну задачу, но у каждого в голове разный продукт.

Для этого и нужен SRS — Software Requirements Specification. Это документ, который фиксирует, что именно должна делать система, в каких условиях, с какими ограничениями и по каким критериям результат считается правильным. Не набор общих пожеланий. Не список экранов. А рабочая спецификация, по которой можно оценивать, проектировать, разрабатывать, тестировать и принимать результат.

SRS нужен не ради формальности. Он нужен, чтобы не платить дважды — сначала за разработку, потом за переделку.

Что такое SRS на практике

SRS — это опорный документ проекта между бизнесом, аналитикой, разработкой, тестированием и поддержкой.

Он отвечает на 5 вопросов:

• что система должна делать;
• в каких сценариях это работает;
• какие есть ограничения;
• как проверить, что требование выполнено;
• что не входит в текущий объем.
  
  

Последний пункт особенно важен. Хороший SRS фиксирует не только состав работ, но и границы. Иначе проект начинает расползаться: «раз уж делаем это, давайте сразу еще вот это». На словах это мелочь. На практике — новые связи, новые риски, новая нагрузка на тестирование и поддержку.

Что SRS не должен в себя тащить

Частая ошибка — подменять требования техническими решениями.

Требование «система должна хранить историю операций 5 лет и позволять искать по номеру документа, дате, клиенту и статусу» — нормальное.

Требование «использовать PostgreSQL, Redis и микросервисную архитектуру» — уже не про требования, а про реализацию. Такие решения принимают позже, когда понятны нагрузка, контур, интеграции, требования к отказоустойчивости, бюджет и команда сопровождения.

SRS не должен отвечать на вопрос «как написать». Он должен точно отвечать на вопрос «что должно получиться».

Когда без SRS уже опасно

Полноценная спецификация нужна не в каждом проекте. Но без нее почти гарантированы конфликты, срывы и переделки, если:

• проект делает внешний подрядчик;
• в системе много ролей, сценариев и исключений;
• есть интеграции с другими системами;
• продукт влияет на деньги, документы, клиентские данные, логистику, платежи или доступы;
• решение будет жить долго и развиваться не одной командой;
• приемка должна идти по понятным критериям, а не по ощущениям.
  
  

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

Особенно это заметно в enterprise-среде и legacy. Там проблема почти никогда не в одной функции. Проблема в зависимостях, совместимости, старых данных, регламентных окнах, доступах и последствиях для соседних процессов.

Что бизнес получает от нормального SRS

1. Прогнозируемость. Когда требования зафиксированы, можно оценивать не «на глаз», а по составу функций, интеграций, ролей, исключений и ограничений.
   
   
2. Управляемость изменений. Если baseline-версии требований нет, любое изменение выглядит как «маленькое уточнение». Когда спецификация есть, видно, что меняется: логика, данные, интерфейсы, тесты, сроки, бюджет, поддержка.
   
   
3. Нормальная приемка. Без SRS продукт часто принимают по ощущениям. С ним — по согласованным критериям.
   
   
4. База для поддержки. После релиза документ нужен не меньше, чем до него. Новая команда, подрядчик поддержки, тестировщики, интеграторы — всем нужен единый источник понимания, как система должна работать.
   
   

«Большая часть дорогих доработок появляется не потому, что команда плохо пишет код. Они появляются потому, что в начале проекта никто не договорился, где заканчивается бизнес-требование и начинается предположение», — Алексей Постригайло, эксперт по системной интеграции, Энсайн.

Из чего должен состоять SRS

Не нужен культ шаблона. Но логика у хорошего документа почти всегда одна.

1. Цель и границы проекта. Какую бизнес-проблему решаем, кто пользователи, что входит в первую версию, а что остается за рамками.
   
   
2. Контекст и ограничения. В каком контуре работает система, какие есть внешние зависимости, ограничения по безопасности, доступам, инфраструктуре, релизным окнам и данным.
   
   
3. Функциональные требования. Что делает система, кто запускает сценарий, какие есть предусловия, шаги, проверки, результаты и ошибочные сценарии.
   
   
4. Нефункциональные требования. Производительность, доступность, отказоустойчивость, безопасность, аудит действий, масштабируемость, журналирование, архивирование, время восстановления.
   
   
5. Требования к данным и интеграциям. Какие сущности участвуют, откуда приходят данные, кто источник истины, что происходит при ошибке обмена, дублировании, тайм-ауте или конфликте версий.
   
   
6. Критерии приемки. Каждое важное требование должно быть проверяемым. Иначе это не требование, а пожелание.

Как писать требования, чтобы их не трактовали по-своему

Главное правило: требование должно быть однозначным, проверяемым и отделенным от соседнего.

• Плохо: «Система должна быстро загружаться и быть удобной».
• Лучше: «Для авторизованного пользователя страница списка заказов должна открываться не более чем за 2 секунды при нагрузке до 300 одновременных сессий».
• Плохо: «Система должна отправлять уведомления».
• Лучше: «При переходе заказа в статус «Передан в доставку» система должна отправить клиенту email и SMS, если в карточке заказа заполнены подтвержденные email и номер телефона. При ошибке отправки система должна записать событие в журнал и поставить задачу на повторную отправку».
  
  

Чем меньше слов вроде «удобно», «быстро», «гибко», «понятно», тем меньше пространства для споров.

Минимальный шаблон хорошего требования

Даже без сложного инструмента полезно держать единый формат:

ID: FR-012
Название: Создание заказа из корзины
Источник: Бизнес-требование BR-03
Приоритет: Must
Описание: Пользователь может оформить заказ из корзины
Предусловия: Пользователь авторизован, корзина не пуста, товары доступны к заказу
Основной сценарий: Пошаговое описание действий
Исключения: Товар недоступен, не прошла оплата, отсутствует адрес
Результат: Заказ создан, клиент получил подтверждение, данные переданы в учетную систему
Критерии приемки: Список проверяемых условий
Связанные требования: Уведомления, логирование, интеграция с оплатой

Кто должен участвовать в создании SRS

Ошибка — считать, что спецификацию пишет только аналитик.

Хороший SRS собирается на стыке ролей. Бизнес формулирует цель. Аналитик переводит ее в структуру и сценарии. Архитектор проверяет реализуемость. Разработка видит скрытый объем и зависимости. Тестирование помогает сделать требования проверяемыми. Поддержка подсказывает, где потом возникнут проблемы в эксплуатации.

Если документ пишет один человек в вакууме, он почти всегда получается или слишком общим, или слишком теоретическим.

Как выглядит рабочий процесс

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

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

После этого фиксируют требования и согласуют baseline — версию документа, от которой идет работа.

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

Где SRS чаще всего ломается

Чаще всего проблемы возникают в 5 местах:

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

Самая опасная ситуация — когда SRS формально есть, но фактически устарел. Команда разрабатывает по одному пониманию, тестирует по другому, а бизнес принимает по третьему.

Когда полноценный SRS не нужен

Избыточная документация тоже вредна.

Если задача маленькая, логика простая, команда компактная, контур понятный, а цена ошибки низкая, можно обойтись более легким форматом: user story, acceptance criteria, макеты и список ограничений.

Но здесь важно не обманывать себя. Часто проект называют «небольшой доработкой», хотя внутри уже есть интеграции, роли, права, данные, уведомления, история изменений и требования к отказоустойчивости. Это уже не маленькая задача. Это плохо описанный проект.

Подведем итоги

SRS — это способ убрать двусмысленность из проекта до того, как она превратится в переделки, конфликт по объему работ и проблемы в эксплуатации.

Чем сложнее система, чем больше в ней интеграций и чем дольше ей жить, тем выше цена плохих требований. В таких проектах спецификация — это инструмент управления риском.

Хороший SRS дает предсказуемость. Для бизнеса — в сроках и бюджете. Для команды — в границах задачи. Для поддержки — в понимании того, как система должна вести себя в реальном контуре.