Software Requirements Specification

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

Назначение и цели

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

• Основа для проектирования и разработки. Разработчики используют SRS как эталон для создания архитектуры, написания кода и модульного тестирования.
• Базис для тестирования. Команда тестирования на основе SRS разрабатывает тестовые сценарии для проверки соответствия продукта требованиям.
• Средство коммуникации. SRS служит единым источником истины для всех заинтересованных сторон (стейкхолдеров), включая заказчика, менеджеров, аналитиков, разработчиков и тестировщиков.
• Инструмент управления изменениями. Любые изменения в требованиях вносятся в SRS, что позволяет отслеживать историю и контролировать версии.

Структура документа

Стандарт ISO/IEC/IEEE 29148:2018 (заменивший устаревший IEEE 830-1998) рекомендует типовую структуру SRS, которая может адаптироваться под конкретный проект. Как правило, документ включает следующие разделы:

Введение

• Назначение документа. Определение целевой аудитории и области применения SRS.
• Область действия. Описание того, что входит и что не входит в рамки разрабатываемого ПО.
• Определения, акронимы и сокращения. Глоссарий терминов, используемых в документе.
• Ссылки. Перечень других документов, стандартов или источников, на которые опирается SRS.
• Обзор документа. Краткое описание структуры и содержания.

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

• Перспектива продукта. Место разрабатываемого ПО в экосистеме: его взаимосвязь с другими системами, аппаратным обеспечением, пользователями.
• Функции продукта. Краткое перечисление основных функциональных возможностей.
• Характеристики пользователей. Описание типов пользователей (ролей) и их уровня квалификации.
• Ограничения. Технические, нормативные, бюджетные или временные рамки проекта.
• Допущения и зависимости. Предположения, сделанные при составлении требований, и внешние факторы, влияющие на проект.

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

Этот раздел — ядро SRS. Он делится на две основные категории:

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

Функциональные требования описывают конкретное поведение системы, её реакции на входные данные и выполняемые действия. Они формулируются в виде утверждений «система должна [действие] при [условии]». Примеры:

• Система должна позволять пользователю авторизоваться по логину и паролю.
• Система должна отправлять уведомление на электронную почту при регистрации нового пользователя.
• Система должна генерировать отчёт по продажам за указанный период в формате PDF.

Для наглядности функциональные требования часто группируются по модулям или пользовательским сценариям и могут быть представлены в виде вариантов использования (use cases) или диаграмм.

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

Нефункциональные требования описывают атрибуты качества системы и ограничения. Они не связаны напрямую с конкретными функциями, но определяют, насколько хорошо система их выполняет. Ключевые категории:

• Производительность. Время отклика, пропускная способность, количество одновременно обслуживаемых пользователей.
• Надёжность. Время безотказной работы, вероятность сбоя, механизмы восстановления.
• Доступность. Процент времени, в течение которого система должна быть работоспособна (например, 99,9%).
• Безопасность. Требования к аутентификации, авторизации, шифрованию данных, защите от несанкционированного доступа.
• Удобство использования (Usability). Требования к интерфейсу, обучению пользователей, документации.
• Переносимость. Возможность работы на разных операционных системах, браузерах или аппаратных платформах.
• Сопровождаемость. Требования к модульности кода, наличию комментариев, документации для разработчиков.

Приложения

В этот раздел выносятся вспомогательные материалы: диаграммы потоков данных, прототипы интерфейсов, описание алгоритмов, словарь данных, бизнес-правила.

Процесс разработки SRS

Создание SRS — итеративный процесс, включающий несколько этапов:

1. Сбор требований. Аналитик проводит интервью с заказчиком и пользователями, изучает существующую документацию, анализирует бизнес-процессы.
2. Анализ и моделирование. Выявленные требования структурируются, проверяются на непротиворечивость и полноту. Создаются модели (например, диаграммы вариантов использования в UML).
3. Спецификация. Требования записываются в формализованном виде согласно выбранному шаблону.
4. Валидация. Документ проверяется всеми заинтересованными сторонами на предмет соответствия их ожиданиям. Обнаруженные ошибки и несоответствия устраняются.
5. Утверждение. После согласования SRS утверждается заказчиком и руководителем проекта, после чего становится базой для дальнейшей работы.

Критерии качества SRS

Хорошо написанный SRS должен соответствовать следующим принципам (согласно IEEE 830):

• Корректность. Каждое требование должно отражать реальную потребность заказчика.
• Недвусмысленность. Каждое требование должно иметь единственное толкование.
• Полнота. Документ должен описывать все существенные требования, включая реакции на все возможные входные данные и ситуации.
• Непротиворечивость. Требования не должны противоречить друг другу.
• Ранжированность по важности и стабильности. Требования должны быть разделены на обязательные (must-have), желательные (should-have) и возможные (could-have).
• Проверяемость. Каждое требование должно быть сформулировано так, чтобы можно было однозначно определить, выполнено оно или нет, с помощью тестирования, инспекции или анализа.
• Модифицируемость. Структура документа должна позволять легко вносить изменения без нарушения целостности.
• Отслеживаемость. Каждое требование должно иметь уникальный идентификатор и быть связано с источником (например, запросом заказчика) и последующими артефактами (дизайном, кодом, тестами).

Инструменты для создания SRS

Для разработки и управления SRS используются различные инструменты:

• Текстовые редакторы и процессоры. Microsoft Word, Google Docs, LibreOffice Writer — простые средства для небольших проектов.
• Специализированные системы управления требованиями (Requirements Management Tools). IBM Engineering Requirements Management DOORS, Jama Connect, Polarion ALM, Visure Requirements. Эти инструменты обеспечивают версионирование, отслеживание связей, управление изменениями и генерацию отчётов.
• Универсальные платформы для совместной работы. Confluence, Notion, Jira (с плагинами для требований) — позволяют вести требования в виде wiki-страниц или задач, обеспечивая прозрачность для команды.
• Инструменты моделирования. Enterprise Architect, Visual Paradigm, Sparx Systems — используются для создания диаграмм, которые затем включаются в SRS.

Проблемы и критика

Несмотря на широкое распространение, SRS имеет ряд недостатков:

• Объём и сложность поддержки. Для крупных проектов SRS может достигать сотен страниц, что затрудняет его актуализацию. Любое изменение в требованиях требует внесения правок в документ и повторного согласования.
• Избыточная формализация. В некоторых проектах (особенно в agile-методологиях, таких как Scrum) полный SRS считается излишним. Вместо него используются пользовательские истории (user stories) и критерии приёмки, которые хранятся в бэклоге продукта.
• Проблема «замороженных» требований. Если SRS утверждён слишком рано, он может не отражать изменяющиеся потребности рынка или заказчика, что приводит к созданию продукта, не соответствующего ожиданиям.
• Сложность проверки нефункциональных требований. Атрибуты качества, такие как «удобство использования» или «надёжность», часто формулируются субъективно и трудно поддаются объективной проверке.

Связь с другими документами

SRS является частью более широкого набора документации по требованиям. Он тесно связан с:

• Бизнес-требованиями (Business Requirements Document, BRD). Описывают цели и задачи проекта с точки зрения бизнеса, не углубляясь в технические детали.
• Системными требованиями (System Requirements Specification, SyRS). Для сложных систем, включающих аппаратное и программное обеспечение, SyRS описывает требования к системе в целом, а SRS — только к её программной части.
• Планом тестирования (Test Plan). Тест-план и тест-кейсы разрабатываются на основе SRS для проверки соответствия продукта требованиям.
• Документом архитектуры (Software Architecture Document, SAD). Описывает, как требования из SRS будут реализованы на уровне архитектуры.

Источники

• ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering.
• IEEE Std 830-1998 — IEEE Recommended Practice for Software Requirements Specifications.
• Wiegers, K., Beatty, J. (2013). Software Requirements. 3rd Edition. Microsoft Press.
• Sommerville, I. (2015). Software Engineering. 10th Edition. Pearson.
• Leffingwell, D., Widrig, D. (2003). Managing Software Requirements: A Use Case Approach. 2nd Edition. Addison-Wesley.