Ниже — практичный шаблон SRS, который можно использовать в учебных проектах, внедрении ИТ-систем, разработке ПО или автоматизации бизнес-процессов. Я бы не делал его слишком «академическим»: хорошая SRS должна быть не красивым документом, а рабочим инструментом согласования между заказчиком, аналитиком, архитектором, разработкой, тестированием и сопровождением.
Спецификация требований к программному обеспечению.
Software Requirements Specification, SRS
1. Общая информация о документе
1.1. Название проекта
Указывается полное название проекта, системы или продукта.
Пример:
«Система автоматизации обработки заявок клиентов»
или
«Модуль интеграции 1С:ERP с системой маркировки “Честный знак”».
1.2. Версия документа
Нужно фиксировать номер версии, дату изменения и ответственного за актуализацию.
Рекомендация:
Не ограничивайтесь названием файла вроде SRS_final_final_2.docx. Лучше вести таблицу версий прямо внутри документа.
1.3. Участники согласования
Здесь фиксируются роли и конкретные люди, которые отвечают за содержание требований.
Рекомендация:
SRS не должен согласовываться «вообще всеми». Важно заранее определить, кто имеет право принимать решение, а кто только комментирует.
2. Назначение и границы документа
2.1. Цель документа
Кратко описывается, зачем создаётся SRS.
Пример формулировки:
Настоящий документ описывает функциональные и нефункциональные требования к системе обработки заявок клиентов. Документ предназначен для согласования объёма разработки, проектирования архитектуры, оценки трудозатрат, подготовки тест-кейсов и последующей приёмки результата.
2.2. Область применения системы
Здесь нужно объяснить, где и кем будет использоваться система.
Пример:
Система используется сотрудниками отдела продаж, клиентского сервиса и руководителями подразделений для регистрации, обработки, контроля и анализа клиентских заявок.
2.3. Границы проекта
Очень важный раздел. Он отвечает на вопрос: что входит в проект, а что не входит.
Рекомендация:
Этот раздел защищает проект от расползания объёма. Часто конфликты возникают не из-за того, что требование плохо описано, а из-за того, что никто не зафиксировал, что оно не входит в текущий этап.
3. Общее описание системы
3.1. Краткое описание решения
Здесь даётся описание системы простым языком: что она делает и какую проблему решает.
Пример:
Система предназначена для централизованной обработки клиентских заявок. Она позволяет регистрировать обращения, назначать ответственных, отслеживать статусы, контролировать сроки исполнения и формировать отчёты по качеству обработки.
3.2. Пользователи и роли
Нужно описать основные группы пользователей.
Рекомендация:
Не описывайте роли слишком обобщённо. Роль «пользователь» почти бесполезна. Лучше фиксировать реальные рабочие роли: бухгалтер, менеджер склада, руководитель отдела продаж, методист, диспетчер, администратор.
3.3. Основные бизнес-процессы
Здесь можно перечислить процессы, которые поддерживает система.
Пример:
- Регистрация заявки.
- Проверка полноты данных.
- Назначение ответственного.
- Обработка заявки.
- Согласование результата.
- Закрытие заявки.
- Анализ качества обработки.
Рекомендация:
Для сложных проектов лучше добавить схему процесса: BPMN, блок-схему или хотя бы таблицу шагов. SRS не обязан быть только текстовым документом.
4. Функциональные требования
Это центральная часть SRS. Здесь описывается, что система должна делать.
Удобный формат — таблица требований.
Рекомендуемая структура одного требования
Каждое функциональное требование желательно описывать по единой логике:
ID: FR-001
Название: Создание заявки
Описание: Система должна позволять оператору создать новую заявку клиента.
Предусловия: Пользователь авторизован в системе и имеет роль «Оператор».
Основной сценарий:
- Пользователь открывает форму создания заявки.
- Заполняет обязательные поля.
- Нажимает кнопку «Сохранить».
- Система проверяет корректность данных.
- Система сохраняет заявку и присваивает ей номер.
Альтернативный сценарий:
Если обязательные поля не заполнены, система показывает сообщение об ошибке и не сохраняет заявку.
Критерии приёмки:
- заявка сохраняется в системе;
- заявке присваивается уникальный номер;
- дата и автор создания фиксируются автоматически;
- незаполненные обязательные поля подсвечиваются;
- пользователь получает сообщение об успешном сохранении.
Рекомендация:
Не пишите требование так: «Система должна быть удобной для обработки заявок». Это не функциональное требование, потому что его нельзя проверить. Лучше: «Пользователь должен иметь возможность отфильтровать заявки по статусу, дате создания и ответственному».
5. Нефункциональные требования
Нефункциональные требования описывают не то, что делает система, а то, как именно она должна это делать.
5.1. Производительность
5.2. Надёжность и доступность
Примеры требований:
- система должна быть доступна не менее 99,5% рабочего времени;
- данные заявки не должны теряться при обрыве соединения после сохранения;
- резервное копирование должно выполняться ежедневно.
5.3. Безопасность
Примеры требований:
- доступ к системе осуществляется только после авторизации;
- пользователь видит только те данные, которые доступны его роли;
- действия пользователей с заявками должны фиксироваться в журнале;
- парольная политика должна соответствовать внутренним требованиям компании.
5.4. Удобство использования
Примеры требований:
- основные действия по заявке должны быть доступны не более чем за 3 клика;
- обязательные поля должны быть визуально выделены;
- сообщения об ошибках должны объяснять причину ошибки и способ исправления;
- интерфейс должен быть доступен на русском языке.
Рекомендация:
Фраза «интерфейс должен быть интуитивно понятным» слабая. Она звучит правильно, но плохо проверяется. Лучше заменить её на конкретные параметры: количество шагов, наличие подсказок, единый стиль форм, понятные сообщения об ошибках.
6. Требования к данным
6.1. Основные сущности
Здесь описываются ключевые объекты системы.
6.2. Обязательные поля
6.3. История изменений
Нужно указать, какие изменения должны логироваться.
Пример:
Система должна сохранять историю изменений по следующим событиям: создание заявки, изменение статуса, изменение ответственного, добавление комментария, закрытие заявки.
7. Требования к интерфейсам
7.1. Пользовательский интерфейс
Здесь можно перечислить основные экраны системы.
7.2. Интеграции
Если система взаимодействует с другими системами, это нужно описать отдельно.
Рекомендация:
По интеграциям важно фиксировать не только «с чем интегрируемся», но и кто является источником мастер-данных. Например, клиент создаётся в CRM, а в 1С только используется. Или наоборот.
8. Бизнес-правила
Бизнес-правила описывают ограничения и логику работы системы.
Примеры:
Рекомендация:
Бизнес-правила лучше отделять от функциональных требований. Функциональное требование отвечает на вопрос «что пользователь может сделать», а бизнес-правило — «при каких условиях и с какими ограничениями».
9. Ограничения и допущения
9.1. Ограничения
Здесь фиксируются технические, организационные и нормативные ограничения.
Примеры:
- система должна работать в инфраструктуре заказчика;
- используются только браузеры Chrome и Edge последних двух версий;
- интеграция должна выполняться без изменения типовой конфигурации 1С;
- персональные данные должны храниться на территории РФ;
- разработка выполняется в рамках бюджета и сроков, утверждённых в договоре.
9.2. Допущения
Допущения — это условия, которые считаются верными на момент подготовки SRS.
Примеры:
- заказчик предоставит тестовый доступ к 1С до начала этапа разработки;
- структура справочника клиентов будет согласована до начала интеграции;
- пользователи пройдут обучение до промышленного запуска;
- исторические данные мигрируют только за последние 2 года.
Рекомендация:
Допущения обязательно нужно выносить в отдельный раздел. Иначе они остаются в голове у аналитика, а потом превращаются в конфликт: исполнитель считал одно, заказчик ожидал другое.
10. Приоритеты требований
Для приоритизации можно использовать простую шкалу.
Пример:
Рекомендация:
Не ставьте всем требованиям Must. Если всё обязательно, приоритизация не работает. Хорошая SRS помогает не только описать желания, но и принять решение, что действительно важно для первого релиза.
11. Критерии приёмки
Этот раздел связывает требования с проверкой результата.
Рекомендация:
Каждое важное требование должно быть проверяемым. Если по требованию невозможно написать тест-кейс, значит оно описано слишком расплывчато.
12. Матрица трассируемости требований
Матрица трассируемости показывает связь между бизнес-целями, требованиями, разработкой и тестированием.
Рекомендация:
Матрица особенно полезна в средних и крупных проектах. Она помогает понять, зачем нужно каждое требование. Если требование не связано ни с одной бизнес-целью, стоит проверить, действительно ли оно нужно.
13. Глоссарий
Рекомендация:
Глоссарий нужен не для красоты. Он снижает риск, что заказчик, аналитик и разработчик используют одни и те же слова в разных смыслах.
14. Приложения
В приложения можно вынести материалы, которые перегружают основной документ:
- схемы бизнес-процессов;
- макеты экранов;
- диаграммы состояний;
- описание API;
- ER-диаграммы;
- таблицы справочников;
- примеры отчётов;
- протоколы интервью;
- решения архитектурного комитета.
Общие рекомендации по заполнению SRS
1. Пишите требования так, чтобы их можно было проверить
Плохая формулировка:
Система должна быть удобной и современной.
Хорошая формулировка:
Пользователь должен иметь возможность создать заявку не более чем за 3 последовательных шага при условии, что данные клиента уже есть в справочнике.
2. Разделяйте желания, требования и решения
Частая ошибка — сразу писать техническое решение вместо потребности.
Плохо:
Нужно сделать кнопку синего цвета в правом верхнем углу.
Лучше:
Пользователь должен иметь возможность быстро создать новую заявку из списка заявок. Расположение и внешний вид элемента управления определяются на этапе проектирования интерфейса.
3. Не смешивайте бизнес-требования и системные требования
Бизнес-требование:
Сократить среднее время обработки заявки с 3 дней до 1 дня.
Системное требование:
Система должна автоматически уведомлять ответственного о новой заявке в течение 1 минуты после назначения.
4. Используйте уникальные идентификаторы
Каждое требование должно иметь ID: FR-001, NFR-001, BR-001.
Это помогает ссылаться на требования в переписке, задачах, тест-кейсах и протоколах согласования.
5. Фиксируйте не только штатные, но и исключительные сценарии
Важно описывать, что происходит при ошибках:
- пользователь не заполнил обязательное поле;
- интеграция недоступна;
- данные не прошли проверку;
- пользователь не имеет прав;
- запись уже была изменена другим пользователем.
6. Не превращайте SRS в свалку
Если в документ начинают попадать коммерческие условия, протоколы совещаний, длинные переписки, технические догадки и несогласованные идеи, SRS становится нечитаемым.
Лучше держать структуру так:
- в SRS — согласованные требования;
- в приложениях — схемы, макеты, таблицы;
- в backlog — идеи и будущие улучшения;
- в протоколах — история обсуждений.
7. Обязательно согласуйте критерии приёмки
SRS без критериев приёмки часто приводит к спору в конце проекта: исполнитель считает, что требование выполнено, а заказчик — что «он ожидал другое».
Поэтому рядом с каждым важным требованием должен быть ответ на вопрос:
Как мы поймём, что это сделано правильно?