Что такое SRS (Software Requirements Specification)? Когда его применяют?

SRS (Software Requirements Specification): определение и применение

Что такое SRS

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

Основное назначение SRS

• Определить границы проекта — чётко обозначить, что входит в scope, а что нет
• Согласовать требования — получить одобрение от всех заинтересованных сторон
• Руководство разработкой — служить источником истины для разработчиков
• Базис тестирования — основа для создания тест-планов
• Юридическая защита — документальное подтверждение договорённостей

Структура типового SRS

1. Введение (Introduction)

• Назначение документа
• Область применения
• Определения, аббревиатуры, ссылки

2. Общее описание (Overall description)

• Перспектива продукта (место в экосистеме)
• Функции продукта
• Характеристики пользователей
• Ограничения

3. Требования (Requirements)

• Функциональные требования — что система должна делать
• Нефункциональные требования:
  • Производительность
  • Безопасность
  • Надёжность
  • Масштабируемость
  • Интеграция
• Пользовательские интерфейсы
• Системные интерфейсы

4. Приложения

• Прототипы экранов
• Диаграммы
• Матрица прослеживаемости требований

Когда применяется SRS

Проекты с явным спецификацией требований:

• Крупные корпоративные системы
• Государственные контракты (часто обязательно по регламенту)
• Критичные системы (здравоохранение, финансы, авиация)
• Проекты с чётким бюджетом и сроками

Контекст применения:

• Начало проекта — перед архитектурой и разработкой
• Выход на новый рынок — при разработке новых продуктов
• Изменение требований — при существенных корректировках
• Передача в aутсорс — когда нужно минимизировать неоднозначность

Когда SRS может быть избыточным

• Agile/Lean проекты — требования возникают постепенно, вместо полного SRS используют user stories
• Стартапы с MVP — идёт быстрое экспериментирование
• Внутренние инструменты — низкий риск, прямое взаимодействие с заказчиком
• Апгрейды существующих систем — часто хватает документа об изменениях

Формат SRS

Стандартный формат: IEEE 830-1998 (или более современный IEEE 29148:2018)

Однако практически каждая компания адаптирует SRS под свои процессы:

• Сокращённые версии для Agile
• Встроенные в wiki или confluence
• Комбинированные с диаграммами (C4, BPMN)

Пример фрагмента SRS

3.2.1 Функциональное требование FR-001
Наименование: Аутентификация пользователя
Описание: Система должна предоставлять возможность входа через:
  - Email и пароль
  - OAuth 2.0 (Google, GitHub)
  - SAML для корпоративной сети

Приёмочные критерии:
  - Вход выполняется за менее 2 секунд
  - Пароль передаётся только по HTTPS
  - Поддержка 2FA (двухфакторной аутентификации)

Приоритет: Высокий (MUST HAVE)

Заключение

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