Software Requirements Specification (SRS) — спецификация требований к программному обеспечению.
Введение
Цикл разработки программного обеспечения включает этапы: планирование, проектирование архитектуры, создание SRS, дизайн и др. Заказчики и разработчики часто используют разную терминологию. Клиент описывает внешнее поведение системы, а программисты фокусируются на внутренних характеристиках. Бизнес-аналитик или системный аналитик помогает преодолеть этот разрыв, переводя потребности клиента в задачи для разработчиков. SRS — документ, содержащий информацию о поведении системы, её функциях, выдерживаемой нагрузке и т.д. Его создают системные аналитики для объяснения разработчикам, что необходимо реализовать.
Структура SRS
Типичная структура SRS (на английском языке):
- Introduction: Введение и цель
- Overall Description: Общее описание
- System Features: Функции системы
- System Interfaces: Интерфейсы системы
- Non-functional Requirements: Нефункциональные требования
- Appendices: Приложения
- Glossary: Словарь терминов
- Index: Индекс
Базовые требования к SRS
Основные требования к документу:
- Краткость и четкость: Описание должно быть кратким и понятным.
- Отсутствие двусмысленности: Текст должен интерпретироваться однозначно.
- Простота: Используйте простой и понятный язык.
- Диаграммы потоков данных (DFD): Необходимо наглядно отобразить входные и выходные данные системы.
- Детализация: Требования должны быть однозначными и достаточно подробными для понимания функционала.
Разделы SRS и их содержимое
Рассмотрим подробнее каждый раздел:
Introduction
- Purpose: Описание приложения или продукта.
- Conventions: Описание технических терминов и соглашений, используемых в документе. Определения должны быть простыми и понятными.
- References: Полные и подробные ссылки на использованную литературу и другие источники.
Overall Description
- Product Features: Общее описание функций продукта. Желательно включить DFD, показывающую общее взаимодействие системы.
- Operational Environment: Описание среды работы продукта (ОС, версии компиляторов, базы данных, серверы, оборудование и т.д.).
- Design and Implementation Constraints: Ограничения на разработку (язык программирования, базы данных, стандарты кодирования, ограничения, накладываемые средой или бизнес-логикой).
- User Documentation: Описание необходимой пользовательской документации.
System Features
Для каждой функции (feature):
- Unique Identifier: Уникальный идентификатор.
- Description: Подробное описание функции, её цели и приоритета.
- Trigger: Условия запуска функции и её поведение при запуске.
- Functional Requirements: Подробное описание работы функции, обработки ошибок, отображения данных и сохранения информации.
System Interfaces
Описание взаимодействия системы с внешним миром (API, обмен данными и т.д.). Для систем с несколькими ролями рекомендуется создавать отдельный документ для каждой роли. Включение use cases и user stories может быть полезно.
Non-functional Requirements
Требования, которые нельзя описать как функциональные возможности. Например:
- Performance: Требования к производительности (скорость обработки запросов и т.д.).
- Software Quality Attributes: Требования к качеству кода (тестирование, метрики качества).
- Security: Требования безопасности.
Appendices
Дополнительные материалы (описания протоколов, поясняющие концепции и т.д.).
Glossary
Словарь терминов.
Index
Индекс.
SRS не является обязательным, но может значительно помочь в средних и больших проектах. Его использование демонстрирует профессионализм разработчика или системного аналитика.