Ответ.

SRS — структурированный документ, описывающий все требования к разрабатываемой системе. Его задача максимально однозначно и полно "перевести" бизнес-ожидания на язык проектной группы. Основные разделы:

1. Введение (цели, область применения, терминология)
2. Описание продукта и бизнес-контекст
3. Описания пользователей и их ролей
4. Функциональные требования (use cases, user stories)
5. Нефункциональные требования (безопасность, производительность, юзабилити)
6. Ограничения
7. Интерфейсы
8. Внешние зависимости
9. Критерии приёмки требований
10. Словарь терминов

Ключевые особенности:

• SRS содержит как функциональные, так и нефункциональные требования.
• Требования формулируются однозначно, с минимальной двусмысленностью.
• В SRS обязательно отражаются сценарии использования, ограничения, критерии успешного результата.

Для контроля полноты и качества аналитик использует чек-листы валидации, шаблоны, стандарты IEEE 830 и регулярное согласование с ключевыми стейкхолдерами.

Вопросы с подвохом.

Является ли достаточно описать только user stories для полноценной SRS?

Нет. User stories демонстрируют функциональную сторону, но не охватывают нефункциональные требования, ограничения, интерфейсы, сценарии исключений и критерии приёмки.

Можно ли использовать разные термины для одного и того же сущности в документе?

Нет. Нужно обязательно поддерживать единообразие терминологии: для этого создаётся словарь терминов и проводится перекрёстная рецензия документа.

Должна ли SRS включать в себя требования к безопасности и производительности?

Да. Нефункциональные требования критично важны: их отсутствие приводит к техническому долгу или невозможности эксплуатации системы.

Типовые ошибки и анти-паттерны

• Недостаточная детализация требований, отсутствие примеров и критериев приёмки.
• Использование неоднозначных формулировок: "быстро", "удобно", "надёжно" без числовых характеристик.
• Игнорирование нефункциональных требований.

Пример из жизни

Негативный кейс

SRS написана только на основе user stories, забыты требования по производительности и безопасности.

Плюсы:

• Быстрая подготовка документации.

Минусы:

• Проект не прошёл аудит по безопасности, не выдерживает необходимого количества одновременных пользователей.

Положительный кейс

SRS охватывает полный перечень необходимых атрибутов — функционал, нефункциональные требования, критерии приёмки, глоссарий.

Плюсы:

• Готовность к аудиту, понятные требования для всех участников, высокая управляемость изменений.

Минусы:

• Увеличение трудозатрат на подготовку и согласование документации.