Урок 03.02: Структура SRS — спецификация требований к ПО
Цель урока
Изучить стандарт IEEE 830 для построения документа SRS (Software Requirements Specification), освоить структуру ключевых разделов (Введение, Общее описание, Специфические требования) и получить практические навыки написания требований без двусмысленностей — научиться заменять слова-паразиты («быстро», «удобно», «эффективно») на проверяемые формулировки.
Ключевые понятия
- SRS (Software Requirements Specification) — документ, описывающий, что должна делать система и в каких условиях; основной артефакт системного аналитика
- IEEE 830 — стандарт IEEE для структуры SRS (на смену пришёл ISO/IEC/IEEE 29148, но структура 830 остаётся де-факто стандартом в индустрии)
- Функциональное требование — описание поведения системы (что система должна делать)
- Нефункциональное требование — ограничение на поведение системы (как система должна это делать)
- TRACE (Трассируемость) — свойство требований: каждое требование должно быть связано с источником и реализацией
- Двусмысленность (Ambiguity) — свойство текста, допускающее неоднозначную интерпретацию; главный враг SRS
1. Что такое SRS и зачем он нужен?
1.1. Определение
SRS (Software Requirements Specification) — это формальный документ, который:
- Фиксирует договорённость между заказчиком и командой разработки о том, что будет делать система
- Является основой для проектирования, разработки и тестирования
- Служит точкой отсчёта при оценке изменений (change requests)
1.2. Кто и когда пишет SRS?
| Роль | Что делает |
|---|---|
| Системный аналитик | Пишет основное содержание, структурирует, согласует |
| Архитектор | Консультирует по реализуемости, пишет раздел архитектурных ограничений |
| Product Owner / Заказчик | Утверждает, подписывает — принимает ответственность за полноту |
| QA | Использует SRS для написания тест-кейсов |
| Разработчик | Читает SRS, уточняет детали, реализует |
Когда пишется:
- В Waterfall: до начала проектирования, весь SRS целиком
- В Agile: обычно SRS целиком не пишут. Заменяют набором User Stories + Acceptance Criteria. Однако для regulatory проектов (банки, медицина) SRS пишут и в Agile, но урезанный — только на текущую версию.
1.3. Почему стандарт IEEE 830 — а не «как Бог на душу положит»?
Стандарт IEEE 830 даёт проверенную структуру, которая гарантирует, что документ будет полным, непротиворечивым и читаемым. Он не обязателен к буквальному копированию (вы можете адаптировать), но его логика проверена десятилетиями.
Альтернативный стандарт: ISO/IEC/IEEE 29148:2018 — пришёл на смену 830, но концептуально та же структура.
2. Полная структура SRS по IEEE 830
2.1. Оглавление (рекомендованная структура)
1. Введение
1.1 Цель документа
1.2 Область применения (Scope)
1.3 Определения, акронимы, сокращения
1.4 Ссылки
1.5 Обзор документа
2. Общее описание
2.1 Контекст системы
2.2 Функции системы (краткий обзор)
2.3 Характеристики пользователей
2.4 Ограничения (Constraints)
2.5 Допущения и зависимости
3. Специфические требования (ключевой раздел!)
3.1 Функциональные требования
3.2 Нефункциональные требования
3.2.1 Требования к производительности (Performance)
3.2.2 Требования к безопасности (Security)
3.2.3 Требования к надёжности (Reliability)
3.2.4 Требования к доступности (Availability)
3.2.5 Требования к интерфейсам (Interface)
3.2.6 Требования к данным (Data)
3.3 Модели и диаграммы (ссылочно)
4. Приложения
A. Глоссарий
B. Диаграммы (UML, BPMN, ERD)
C. Матрица трассировки
2.2. Детальный разбор каждого раздела
3. Раздел 1: Введение
1.1. Цель документа
Назначение: Объяснить, для кого и зачем написан этот SRS.
Одна фраза: «Этот документ описывает функциональные и нефункциональные требования к системе [Название], версия [X.X]. Предназначен для команды разработки, QA и заказчика».
Совет: Не пишите абстрактно. Укажите, что будет после утверждения: «После утверждения SRS является основой для проектирования и тестирования».
1.2. Область применения (Scope)
Назначение: Определить границы системы — что ВХОДИТ в проект, а что НЕ входит.
| Хороший пример Scope | ❌ Плохой Scope |
|---|---|
| «Система включает модули: управление заказами, каталог товаров, корзина, оплата, личный кабинет. НЕ включает: CRM, бухгалтерский учёт, интеграцию с 1С» | «Система автоматизирует работу интернет-магазина» |
Правило: Scope — это не список функций. Scope — это границы. Чётко обозначьте, что НЕ входит в систему (Out of Scope). Это предотвратит «расползание» требований (scope creep).
1.3. Определения, акронимы, сокращения
Назначение: Единый язык для всех участников проекта.
| Термин | Определение |
|---|---|
| CRM | Customer Relationship Management — система управления взаимоотношениями с клиентами |
| Пользователь | Физическое лицо, зарегистрированное в системе |
| Заказ | Совокупность товаров, выбранных пользователем для покупки |
| Статус заказа | Текущее состояние обработки заказа (Новый → Подтверждён → Отгружен → Доставлен) |
1.4. Ссылки
Назначение: Перечислить документы, на которые ссылается SRS.
- Vision Document v1.2 от 15.01.2026
- Регламент работы отдела продаж (внутренний документ)
- 152-ФЗ «О персональных данных»
- ГОСТ 34.602-2020
1.5. Обзор документа
Назначение: Кратко описать, что содержит каждый раздел.
«Раздел 2 содержит общее описание системы — контекст, пользователей, ограничения. Раздел 3 — детальные функциональные и нефункциональные требования. В приложениях — глоссарий и диаграммы».
Совет: Не делайте обзор длиннее 1 абзаца. Его никто не читает, но он нужен для формальной полноты.
4. Раздел 2: Общее описание
Раздел не содержит детальных требований. Он создаёт контекст — чтобы читатель понимал, в какой среде работает система и для кого она делается.
2.1. Контекст системы
Назначение: Показать, как система вписывается в существующий ландшафт.
Что должно быть:
- Внешние системы, с которыми взаимодействует новая система
- Потоки данных (кто что передаёт)
- Внешние интерфейсы (пользователь, администратор, внешние API)
Рекомендуемый формат: Диаграмма контекста (контекстная диаграмма DFD или Use Case Diagram уровня системы).
Текстом:
«Система "Интернет-магазин" взаимодействует с: 1) Платёжным шлюзом (Сбербанк) — для проведения оплат; 2) Службой доставки (СДЭК) — для передачи данных oт отправлениях; 3) 1С:Бухгалтерия — для синхронизации остатков и закрывающих документов».
2.2. Функции системы (общий обзор)
Назначение: Кратко (1–2 абзаца) описать, что делает система. Не детали! Только «для топ-менеджмента».
«Система позволяет пользователю просматривать каталог, добавлять товары в корзину, оформлять и оплачивать заказы. Администратор может управлять товарами, заказами и пользователями. Менеджер видит дашборд с аналитикой продаж».
Важно: Это НЕ функциональные требования. Это саммари. Детали — в разделе 3.
2.3. Характеристики пользователей
Назначение: Описать, кто будет работать с системой: роль, уровень подготовки, частота использования.
| Роль | Описание | Техническая грамотность | Частота использования |
|---|---|---|---|
| Посетитель | Незарегистрированный пользователь, просматривает каталог | Низкая (умеет пользоваться браузером) | 1 раз / месяц |
| Клиент | Зарегистрированный пользователь, оформивший хотя бы 1 заказ | Средняя | 2 раза / неделю |
| Администратор | Сотрудник компании, управляющий каталогом | Высокая (техническая) | Ежедневно |
| Менеджер | Сотрудник отдела продаж | Средняя | Ежедневно |
Зачем это нужно: Разные пользователи требуют разного UX и разной документации. Кассир не будет читать 100-страничный SRS, а администратор — не будет пользоваться «интуитивным интерфейсом для домохозяек».
2.4. Ограничения (Constraints)
Назначение: Зафиксировать внешние ограничения, которые команда не может изменить.
| Тип ограничения | Пример |
|---|---|
| Технологические | «Серверная часть реализуется на Java 17 + Spring Boot 3.x» |
| Бюджетные | «Разработка не должна превышать 2000 часов» |
| Временны́е | «MVP должен быть сдан до 01.09.2026» |
| Регуляторные | «Система должна соответствовать 152-ФЗ» |
| Интеграционные | «Система должна обмениваться данными с 1С по REST API» |
| Аппаратные | «Сервер — 4 vCPU, 16 GB RAM, SSD 100 GB» |
2.5. Допущения и зависимости
Назначение: Перечислить, что мы считаем верным (допущения), и от чего зависит проект (зависимости).
Примеры допущений:
- «Пользователи имеют доступ к интернету со скоростью не менее 1 Мбит/с»
- «Заказчик предоставляет доступ к API 1С не позднее 30 дней с начала проекта»
- «Все 15 менеджеров отдела продаж владеют компьютером на уровне уверенного пользователя»
Зачем это нужно: Если допущение нарушится — это основание для change request. Если зависимость не выполнена — это не вина команды.
5. Раздел 3: Специфические требования (ядро SRS)
Это самый большой и важный раздел. Здесь находится детальное описание того, что должна делать система.
5.1. Как нумеровать требования
Каждое требование должно иметь уникальный ID и приоритет.
| ID | Формат | Пример |
|---|---|---|
| Функциональные | FR-001, FR-002 ... | FR-012 |
| Нефункциональные | NFR-001, NFR-002 ... | NFR-007 |
| Интерфейсные | IR-001, IR-002 ... | IR-003 |
| Бизнес-правила | BR-001, BR-002 ... | BR-001 |
Приоритеты (распространённые схемы):
| Схема | Категории | Использование |
|---|---|---|
| High / Medium / Low | Высокий → без требования система не может быть запущена. Средний → важное улучшение. Низкий → «было бы хорошо». | Чаще всего в SRS |
| MoSCoW | Must / Should / Could / Won't | Для приоритизации с заказчиком |
| P1 — P5 | P1 (критический) — P5 (желательно) | В крупных проектах |
5.2. Функциональные требования (FR)
Каждое ФТ содержит:
- ID (уникальный)
- Название (коротко)
- Описание (что система должна делать)
- Приоритет (H / M / L)
- Источник (откуда взялось требование: интервью, регламент, стейкхолдер)
Пример оформления:
| ID | Название | Описание | Приоритет | Источник |
|----|---------|--------|-----------|---------|
| FR-001 | Авторизация по email | Система должна позволять пользователю авторизоваться по email и паролю. При неверном пароле — ошибка 401. После 5 неудачных попыток — блокировка на 15 минут. | High | Интервью с РОП от 15.01 |
| FR-002 | Создание заказа | Авторизованный пользователь должен иметь возможность создать заказ, выбрав товары из каталога, указав адрес доставки и способ оплаты. | High | Vision Document v1.2 |
| FR-003 | Поиск товаров | Система должна предоставлять поиск товаров по названию и артикулу. Результаты должны отображаться по мере ввода (автокомплит). | Medium | Интервью с менеджером |
Важно: Каждое описание ФТ должно быть однозначным и проверяемым. Никаких «должен поддерживать», «должен давать возможность» — пишите конкретный сценарий.
5.3. Нефункциональные требования (NFR)
Оформляются аналогично, но с дополнительной категорией (FURPS+).
| ID | Категория | Описание | Приоритет | Источник |
|---|---|---|---|---|
| NFR-001 | Производительность | 95-й перцентиль времени загрузки страницы каталога не превышает 2 секунд | High | Архитектор |
| NFR-002 | Безопасность | Пароль должен содержать не менее 8 символов, минимум одну заглавную букву и одну цифру | High | Политика безопасности |
| NFR-003 | Доступность | Система должна быть доступна 99.5% времени в месяц (за исключением плановых окон обслуживания) | Medium | SLA |
6. Практические советы: как писать требования без двусмысленностей
6.1. Слова-паразиты, которые нужно удалить из SRS
Это красные флаги — если вы их видите в тексте требования, значит, формулировка непроверяемая.
| Слово-паразит | Почему плохо | ❌ Плохо | ✅ Хорошо |
|---|---|---|---|
| «быстро» | Нет метрики | «Система должна быстро загружать отчёт» | «Система должна загружать отчёт объёмом до 1000 строк не более чем за 3 секунды» |
| «удобно» | Субъективно | «Интерфейс должен быть удобным для пользователя» | «Пользователь должен выполнить сценарий "Создание заказа" не более чем за 3 клика и 60 секунд» |
| «эффективно» | Непонятно, в чём эффективность | «Система должна эффективно обрабатывать заказы» | «Система должна обрабатывать до 100 заказов в минуту без потери производительности» |
| «надёжно» | Не по чек-листу | «Система должна надёжно хранить данные» | «Система должна обеспечить RTO ≤ 1 час, RPO ≤ 15 минут» |
| «оптимально» | Нет критерия оптимума | «Система должна оптимально распределять нагрузку» | «Система должна балансировать запросы между экземплярами сервиса по алгоритму Round Robin» |
| «поддерживать» | Непонятно, что значит | «Система должна поддерживать форматы PDF, DOCX» | «Система должна принимать на вход файлы формата PDF и DOCX размером до 10 МБ» |
| «возможность» | Слишком размыто | «Система должна предоставлять возможность поиска» | «Система должна выполнять поиск по полям: название, артикул; результаты отображаются в течение 1 секунды» |
| «и т.д.» / «и тому подобное» | Незаконченное требование | «Пользователь может настроить цвет, шрифт, расположение и т.д.» | «Пользователь может настроить: 1) цвет фона, 2) размер шрифта (12–16px), 3) расположение панели (слева / снизу)» |
Золотое правило: Если в требовании есть прилагательное или наречие, задайте вопрос: «Как это проверить?» Если не можете ответить — переформулируйте.
6.2. Чек-лист формулировки одного требования
Любое требование (и ФТ, и НФТ) должно проходить проверку-тест по трём вопросам:
- Однозначно? — Все читатели поймут его одинаково? (нет слов-паразитов)
- Проверяемо? — Можно написать тест-кейс, который подтвердит / опровергнет выполнение?
- Измеримо? — Есть численные критерии? (скорость, количество, частота)
Проверяем на примере:
❌ «Система должна быстро обрабатывать большое количество заказов»
- Однозначно? Нет. «Быстро» — для кого-то 5 минут, для кого-то 5 секунд.
- Проверяемо? Нет. QA не знает, какой результат считать PASS.
- Измеримо? Нет.
✅ «Система должна обрабатывать до 500 заказов в минуту с временем обработки одного заказа не более 2 секунд (измеряется на тестовом стенде с характеристиками: 4 vCPU, 16 GB RAM, PostgreSQL)»
- Однозначно? Да.
- Проверяемо? Да: нагрузочный тест на 500 заказов.
- Измеримо? Да: 2 секунды на заказ.
6.3. Используйте «shall» / «must» — избегайте «should» / «may» / «could»
В SRS важно различать уровень обязательности:
| Глагол | Значение | Пример |
|---|---|---|
| shall / must (должен) | Обязательное требование | «Система должна отправлять email при регистрации» |
| should (следует) | Рекомендация, необязательно | «Системе следует использовать кеширование для ускорения загрузки» |
| may / could (может) | Опция | «Система может предоставлять экспорт в PDF» |
Совет: Для SRS используйте только shall. «Should» и «may» лучше вынести в отдельный раздел «Пожелания» или «Будущие версии».
6.4. Пишите активным залогом
| ❌ Пассивный залог | ✅ Активный залог |
|---|---|
| «Пароль должен быть введён пользователем» | «Пользователь должен ввести пароль» |
| «Заказ может быть создан после выбора товаров» | «Система должна создать заказ после того, как пользователь выбрал товары» |
| «Данные будут сохранены в БД» | «Система должна сохранить данные в БД» |
Почему активный залог лучше: он однозначно указывает, кто выполняет действие (пользователь или система).
6.5. Каждое требование — законченная мысль
| ❌ Размазано | ✅ Чётко одно требование |
|---|---|
| «Система должна обрабатывать заказы и отправлять уведомления и формировать отчёты» | FR-004: Система должна обрабатывать заказы (создание, изменение, отмена). FR-012: Система должна отправлять email-уведомления. FR-034: Система должна формировать отчёты по продажам. |
Правило: Одно требование = одна строка/пункт. Если в пункте есть союз «и» — проверьте, не нужно ли разбить на два.
6.6. Избегайте ссылок «как указано выше» / «см. раздел X» как единственного описания
Плохо:
FR-042: Система должна обрабатывать возвраты как указано в разделе 3.2.
Хорошо:
FR-042: Система должна обрабатывать возвраты по следующему алгоритму: пользователь открывает заказ → нажимает «Возврат» → система проверяет, что заказ в статусе «Доставлен» и прошло не более 14 дней → ... (полный алгоритм).
Каждое требование должно быть самодостаточным насколько это возможно.
7. Практический шаблон SRS (упрощённый, для начала работы)
Адаптируйте под свой проект этот структурированный шаблон:
# SRS: [Название проекта]
Версия: 1.0 | Дата: [дата] | Автор: [ФИО]
## 1. Введение
### 1.1 Цель документа
### 1.2 Область применения (Scope)
### 1.3 Определения
### 1.4 Ссылки
## 2. Общее описание
### 2.1 Контекст системы ([ссылка на контекстную диаграмму])
### 2.2 Функции системы (обзор)
### 2.3 Пользователи
| Роль | Краткое описание |
|------|-----------------|
| ... | ... |
### 2.4 Ограничения
### 2.5 Допущения
## 3. Специфические требования
### 3.1 Функциональные требования
| ID | Название | Описание | Приоритет | Источник |
|----|---------|--------|-----------|---------|
| FR-001 | | | | |
### 3.2 Нефункциональные требования
| ID | Категория | Описание | Приоритет | Источник |
|----|-----------|----------|-----------|---------|
| NFR-001 | | | | |
## 4. Приложения
### 4.1 Глоссарий
### 4.2 UML / BPMN диаграммы ([ссылки])
### 4.3 Матрица трассировки
8. Типичные ошибки SRS (с примерами)
| Ошибка | ❌ Пример | ✅ Исправление | Почему это плохо |
|---|---|---|---|
| Двусмысленность | «Система должна обрабатывать данные быстро» | «Система должна обрабатывать 1000 записей не более чем за 2 секунды» | Невозможно проверить |
| Противоречие | FR-001: «Только авторизованный пользователь может смотреть каталог». FR-005: «Посетитель может смотреть каталог без авторизации» | Убрать противоречие | Разработчик не знает, как реализовать |
| Неполнота | «Система должна обрабатывать заказы» — не сказано, что значит «обрабатывать» | «Система должна позволять создавать, просматривать, изменять и отменять заказы» | Разработчик может реализовать только «создание», думая, что это и есть «обработка» |
| Орфография / стиль | «Система должна быть безопасной, потому что это важно для нас» | «Система должна хранить пароли в захешированном виде (bcrypt)» | Субъективно, не по делу |
| Пропущенные исключения | FR-012: «Email отправляется при регистрации». Нет сценария «email-сервер недоступен» | ... + «Если SMTP-сервер недоступен, система должна сохранить письмо в очередь и повторить через 5 минут (максимум 3 попытки), затем уведомить администратора» | В production — потерянные письма |
9. SRS в Agile: адаптация
В Agile-проектах SRS обычно не пишут как монолитный документ. Но для проектов с регуляторными требованиями он всё равно нужен.
Компромиссный подход:
| Вместо... | Используйте... |
|---|---|
| SRS на 100 страниц перед стартом | SRS Light — только разделы 1, 2 + список эпиков |
| Описания каждой функции детально | User Stories в бэклоге |
| Всех требований сразу | Требования на текущую версию (MVP) + roadmap на будущее |
Когда SRS обязателен даже в Agile:
- Разработка для госзаказчика
- Медицинские системы (FDA)
- Финансовые системы (банки, страхование)
- Системы с критичностью безопасности (авионика, АСУ ТП)
Вопросы для самопроверки
- Из каких 4 основных разделов состоит SRS по IEEE 830?
- Что должно быть указано в разделе «Область применения» (Scope)? Почему важно указывать, что НЕ входит?
- Чем функциональные требования отличаются от нефункциональных? Приведите по одному примеру из SRS для интернет-магазина.
- Какие 4 слова-паразита нужно удалить из SRS? Почему? Для каждого напишите исправленный вариант.
- Какие три вопроса нужно задать к каждому требованию, чтобы проверить его качество?
- Почему в SRS нужно писать активным залогом? Приведите пример плохой и хорошей формулировки.
- Что такое Scope Creep? Как SRS помогает с ним бороться?
Практическое задание
Кейс: Вы аналитик в проекте «Внутренний портал для отдела кадров (HR)». Система должна автоматизировать:
- Подачу заявок на отпуск
- Согласование заявок руководителем
- Учёт больничных
- Формирование табеля рабочего времени
Задание 1. Используя структуру IEEE 830, напишите для этого проекта:
- Раздел 1.1: Цель документа (1–2 предложения)
- Раздел 1.2: Область применения (Scope) — что входит, что НЕ входит (3–5 пунктов «In», 2–3 пункта «Out of Scope»)
- Раздел 2.3: Характеристики пользователей — 4 роли с описанием и уровнем подготовки
Задание 2. Возьмите следующий «сырой» список фраз от заказчика и переформулируйте их в корректные функциональные и нефункциональные требования по стандарту SRS:
Фразы заказчика:
- «Система должна быстро считать количество дней отпуска»
- «Уведомления должны приходить вовремя и быть удобными»
- «Заявка на отпуск должна проходить согласование эффективно»
- «Система должна надёжно работать и не терять данные»
Для каждой фразы:
- Укажите, что в ней плохо (какая двусмысленность?)
- Напишите корректное требование (с ID, проверяемой формулировкой)
Задание 3. Дополните свой SRS двумя функциональными требованиями (FR) и двумя нефункциональными требованиями (NFR) для описанного выше HR-портала. Используйте формат таблиц из урока.
Формат: Один файл (md) с тремя разделами.
Дополнительные материалы
- Стандарт: IEEE 830-1998 (оригинал) — доступен по запросу
- Стандарт: ISO/IEC/IEEE 29148:2018 — современная замена 830
- Книга: «Software Requirements» — Karl Wiegers, Joy Beatty (главы 8–12 — детально про SRS)
- Книга: Karl Wiegers — «More About Software Requirements» (конкретные приёмы)
- Чек-лист: IEEE 830 checklist — готовый шаблон для проверки SRS (можно найти по запросу)
- Статья: «How to Write a Software Requirements Specification (SRS)» — Perforce
- Шаблон: SRS Template в Confluence (Atlassian) — готовый шаблон с ieee-разделами