Составление спецификации требований к ПО (SRS)

Сложность: hard Тема: REQ
SRS спецификация требования IEEE 830 ISO 29148

Контекст задачи

Вы выполнили серию задач по инженерии требований: от концепции проекта до проверки требований. Теперь пришло время собрать все результаты в единый артефакт — Спецификацию требований к программному обеспечению (SRS). SRS — это основной документ, который передаётся команде разработки и служит основой для оценки стоимости и сроков, планирования итераций, проектирования архитектуры и тестирования. Отсутствие SRS равносильно попытке построить дом без чертежей.

Формулировка

Составьте итоговую спецификацию требований к программному обеспечению (SRS), интегрируя результаты предыдущих задач. Документ должен соответствовать структуре IEEE 830 / ISO 29148.

Ожидаемый результат

Полная спецификация SRS, содержащая:

  1. Введение и общее описание (проблема, область, определения, аудитория, ограничения)
  2. Функциональные требования с приоритетами (MoSCoW)
  3. Нефункциональные требования (производительность, безопасность, надёжность)
  4. Описание внешних интерфейсов (UI, API, БД)
  5. Критерии приемки

Инструментарий

Методы и подходы:

  • Структура SRS по IEEE 830: 6 основных разделов
  • Интеграция артефактов из предыдущих задач
  • Приоритизация требований по MoSCoW (Must, Should, Could, Won’t)
  • Форматирование требований: однозначное, проверяемое, атомарное

Инструменты:

  • Шаблон SRS по IEEE 830
  • [Шаблон SRS по IEEE 830]
  • [Пример нефункциональных требований]
  • [Рекомендации IEEE 830]
  • Вопрос: Какой раздел SRS hardest написать — функциональные или нефункциональные требования? Почему?
  • Что откуда берётся в SRS:
Раздел SRS Откуда берём Источник
1.1 Цель Проблема и выгоды Концепция проекта
1.2 Область Целевая аудитория Концепция + контекстная диаграмма
2.2 Целевая аудитория Роли пользователей Use-case
3. Функциональные требования Use case + матрица Сценарии использования
4. Нефункциональные требования Анализ конкурентов Концепция
6. Критерии приемки Приоритеты MoSCoW Все задачи

📝 Критерии оценки

  • Документ соответствует структуре IEEE 830 (минимум 6 разделов)
  • Введение содержит цель, область применения, определения терминов
  • Описан продукт, целевая аудитория и ограничения
  • Функциональные требования сформулированы однозначно и проверяемо
  • Нефункциональные требования включают производительность, безопасность, надёжность
  • Описаны внешние интерфейсы (UI, API, БД)
  • Критерии приемки сформулированы в проверяемом формате
  • Требования проприоритезированы (MoSCoW)