Что такое SRS?

SRS: что это и зачем нужен

Определение SRS

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

SRS — это не просто бумажный документ. Это:

• Источник истины для всего проекта
• Договор между всеми сторонами
• Основание для тестирования и приёмки
• Защита от разногласий и претензий

Назначение SRS

1. Коммуникация между сторонами

Разные участники проекта говорят разными языками:

• Бизнес думает о ROI, функциях, процессах
• Разработчики думают о технологиях, архитектуре, ограничениях
• Тестировщики думают о сценариях и edge cases
• Менеджмент думает о сроках и бюджете

SRS переводит бизнес-требования в технический язык, доступный разработчикам.

2. Управление изменениями

Когда возникает вопрос о назначении, SRS даёт ответ. Это предотвращает расширение scope'а и несанкционированные изменения.

3. Базис для тестирования

QA использует SRS для создания тестовых сценариев. Каждое требование должно быть протестировано.

4. Управление рисками

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

Структура SRS

1. Введение

Цель документа

• Описание того, что будет разработано
• Для кого (аудитория)
• Что решает (проблема)

Область действия

• Что включено в проект
• Что исключено (out of scope)
• Ограничения проекта

Определения и аббревиатуры

• Глоссарий терминов
• Объяснение технических терминов

2. Общее описание

Перспектива продукта

• Место системы в большой картине
• Основные функции
• Краткое описание для непрофессионала

Функции продукта

• Список основных функций
• Связь с требованиями бизнеса

Типы и характеристики пользователей

Покупатель: технический уровень низкий, частота использования высокая Администратор: технический уровень средний, ежедневное использование

Ограничения

• Технические ограничения (performance, совместимость)
• Нормативные ограничения (законы, стандарты)
• Бизнес-ограничения (бюджет, сроки)

3. Специфические требования

3.1 Функциональные требования

REQ-001: Авторизация пользователя Описание: Система должна позволить пользователю авторизоваться по email и пароль Предусловие: Пользователь имеет аккаунт

Основной сценарий:

1. Пользователь переходит на страницу входа
2. Вводит email и пароль
3. Нажимает Войти
4. Система проверяет учётные данные
5. Если верно — пользователь авторизуется

Альтернативные сценарии:

• Если пароль неверен — сообщение об ошибке
• Если пользователь не существует — сообщение об ошибке
• Если пользователь заблокирован — информационное сообщение

Приоритет: CRITICAL

3.2 Нефункциональные требования

REQ-101: Performance

• Время загрузки страницы: менее 3 секунд
• Обработка 1000 одновременных пользователей
• Использование памяти: менее 512 MB

REQ-102: Безопасность

• Пароли хранятся в хешированном виде
• HTTPS для всех API запросов
• Двухфакторная аутентификация (опционально)

REQ-103: Совместимость

• Chrome 90+
• Firefox 88+
• Safari 14+
• Mobile (iOS 14+, Android 10+)

REQ-104: Доступность

• WCAG 2.1 Level AA
• Поддержка экранных дикторов
• Клавиатурная навигация

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

• Аналитические модели (DFD, ERD)
• Диаграммы Use Case
• Wireframes и макеты
• Детали интеграций
• Процессы бизнеса (BPMN)

Пример полного требования

ID: REQ-042 Название: Фильтрация товаров по цене

Описание: Пользователь должен иметь возможность отфильтровать товары по диапазону цены на странице каталога.

Предусловия:

• Пользователь находится на странице каталога
• Список товаров загружен

Основной сценарий:

1. Пользователь видит слайдер для цены
2. Вводит минимальную цену (например, 1000 руб)
3. Вводит максимальную цену (например, 5000 руб)
4. Нажимает Применить фильтр
5. Список товаров обновляется
6. URL изменяется (для возможности поделиться ссылкой)

Альтернативные сценарии:

• Если мин больше макс — сообщение об ошибке
• Если нет товаров в диапазоне — сообщение Товары не найдены
• Пользователь может очистить фильтр

Acceptance Criteria:

• Слайдер работает для диапазона 0-100,000
• Фильтр применяется за менее 1 сек
• Работает на мобильных устройствах
• Доступен для клавиатурной навигации

Приоритет: HIGH Оценка: 5 points

Best Practices для SRS

1. Написание требований

• Используй активный залог: Система должна
• Будь конкретным: Время ответа менее 500мс (не быстро)
• Одно требование = одна идея: Разбей сложные требования
• Используй измеримые критерии: Добавляй числа если возможно

2. Организация документа

• Используй единую нумерацию (REQ-001, REQ-002)
• Ссылайся на другие требования
• Группируй по категориям
• Добавляй таблицы для читаемости

3. Версионирование

Версия 1.0 — 2026-01-15 — Начальное описание Версия 1.1 — 2026-02-01 — Добавлены требования безопасности Версия 2.0 — 2026-02-20 — Переработаны требования производительности

4. Согласование

• SRS должен быть одобрен всеми ключевыми стейкхолдерами
• Используй совместное редактирование
• Проводи review встречи перед финализацией

5. Поддержка актуальности

• Обновляй SRS когда меняются требования
• Используй трассировку (какие требования реализованы)
• Архивируй старые версии

SRS vs Use Case vs User Story

Заключение

SRS — это один из самых важных документов в проекте. Хороший SRS:

• Предотвращает недопонимание
• Снижает переделки
• Облегчает тестирование
• Защищает от претензий
• Экономит время и деньги

Профессиональный BA должен уметь создавать чёткие, полные и актуальные SRS документы.