Спецификация требований к ПО (SRS) · Конспекты по бизнес-анализу

Главные идеи#

Три структуры, которые вам встретятся#

Традиционная SRS в RUP на основе IEEE 830-1998. Сначала идут введение и общее описание (место продукта, функции, характеристики пользователей, ограничения, допущения — но без отдельных требований). Затем большой раздел «Конкретные требования» группирует функциональность, удобство использования, надёжность, производительность, сопровождаемость, проектные ограничения, документацию, покупные компоненты, интерфейсы (пользовательские, аппаратные, программные, коммуникационные), лицензирование, юридические уведомления и применимые стандарты.
SRS в RUP с вариантами использования. Маглинец описывает эту версию как контейнер: функциональные требования живут в модели вариантов использования, а SRS собирает их вместе с дополнительными спецификациями для требований к качеству, которые не относятся ни к одному отдельному варианту использования. Документ открывается обзором системы (действующие лица, варианты использования, диаграмма вариантов использования, допущения и зависимости).
Шаблон Вигерса и Битти в традиции IEEE 830: введение, общее описание, функции системы, требования к данным, внешние интерфейсы, атрибуты качества, интернационализация и локализация, прочие требования; глоссарий и аналитические модели вынесены в приложения.

Сколько нужно спецификаций?#

Вигерс и Битти отвергают правило «одна SRS на проект». Очень большой системе может понадобиться спецификация уровня системы и подчинённые спецификации программной и аппаратной частей; небольшие гибкие команды могут формировать SRS на каждую итерацию из инструмента управления требованиями. Авторы предостерегают от одного гигантского документа, где заодно хранятся оценки и планы тестирования (кошмар для управления версиями), от требований, которые живут только на стикерах (рано или поздно стикеры отваливаются от стены), и от скромной спецификации, разбитой на дюжину файлов, которые приходится держать согласованными.

Дайте каждому требованию метку#

На пункт маркированного списка нельзя сослаться в тест-кейсе, запросе на изменение или разговоре. Вигерс и Битти сравнивают три схемы:

Последовательные идентификаторы (UR-9, FR-26). Просто и стабильно; никогда не используйте повторно номер удалённого требования. Правда, группировки такие идентификаторы не показывают.
Иерархическая нумерация (3.2.4.3). Привычно, но хрупко: вставьте раздел — номера сдвинутся, и перекрёстные ссылки сломаются. Обходной путь — запретить вставки ради сохранения нумерации — авторы отвергают.
Иерархические текстовые метки, которые авторы приписывают Тому Гилбу (Booking.Slot.Conflict). Родитель — заголовок функции, а его потомки вместе покрывают эту функцию. Метки осмысленны и переживают реорганизацию, но получаются длинными, и чтобы они оставались уникальными, нужна дисциплина.

TBD — отслеживаемый пробел, а не укрытие#

Помечайте неизвестное как TBD (подлежит определению), назначайте каждому такому пункту владельца и срок и доводите его до закрытия. Нерешённые пробелы сами не исчезают: разработчики либо угадывают, либо ждут. Рядом со спецификацией ведите список вопросов: TBD, ожидающие решения, недостающая информация и неразрешённые конфликты. Маглинец описывает такой список как стандартное приложение.

Экраны в SRS: компромисс#

Экраны делают требования осязаемыми. Но они же подменяют требования дизайном, раздувают документ и слишком рано закрепляют интерфейс в головах читателей. Вигерс и Битти предлагают средний путь: включать концептуальные наброски с явной пометкой, что это наброски, — как ещё одно представление требований, а не их замену. В проектах доработки, где интерфейс уже существует, вполне разумно включить текущие экраны.

Аналог по ГОСТ#

В российских проектах для госсектора роль SRS играет техническое задание по ГОСТ 34.602-89. Маглинец отмечает, что в нём есть отдельные разделы о приёмке и о подготовке организации к вводу системы в действие, которых нет в шаблонах RUP и IEEE.

Как применять#

Выберите структуру. Если моделируете вариантами использования — структуру-контейнер; в остальных случаях — традиционную; для небольших гибких команд — отчёт из инструмента на каждую итерацию.
Решите, как делить. Одна SRS или спецификация системы плюс спецификации подсистем.
Выберите схему меток до того, как напишете первое требование.
Сначала напишите общее описание. Оно заставляет договориться о пользователях, ограничениях и допущениях.
Пишите требования, у каждого — метка и ссылка на источник (бизнес-цель, вариант использования или запрос заинтересованной стороны).
Поддерживайте список вопросов в рабочем состоянии. На каждой встрече по требованиям просматривайте открытые TBD.
Добавьте глоссарий и аналитические модели, которыми пользовались.
Зафиксируйте базовую версию SRS и поставьте её под управление изменениями, как предусмотрено планом управления требованиями.

Шаблон#

Шаблон

# Спецификация требований к ПО: <система>, версия <n>

## 1. Введение — назначение, целевые читатели, границы, соглашения, ссылки
## 2. Общее описание
- Место продукта — контекст, связанные системы
- Классы пользователей — кто и как пользуется
- Операционная среда — платформы, площадки
- Ограничения — проектные, технические, нормативные
- Допущения и зависимости — что должно оставаться верным
## 3. Функциональные требования — сгруппированы по функциям или вариантам использования; у каждого есть метка
## 4. Требования к данным — модель данных, словарь, сроки хранения, отчёты
## 5. Внешние интерфейсы — пользовательские, программные, аппаратные, коммуникационные
## 6. Атрибуты качества — удобство использования, производительность, надёжность, безопасность, сопровождаемость; в измеримом виде
## 7. Локализация — языки, форматы, часовые пояса (если нужно)
## 8. Прочие требования — юридические, лицензирование, установка
## Приложение А. Глоссарий
## Приложение Б. Аналитические модели — диаграммы, на которые есть ссылки выше
## Приложение В. Список вопросов — TBD с владельцем и сроком

Пример#

«Мастерская» (вымышленная сеть веломастерских) использует текстовые метки для функции записи на ремонт:

Booking.Slot.Select: клиент должен иметь возможность выбрать свободное окно для ремонта в выбранной мастерской.
Booking.Slot.Conflict: если другой клиент займёт окно раньше, система должна предложить три ближайших свободных окна.
Booking.Slot.Lead: самое раннее окно, доступное для записи, — TBD (владелец: владелец сети; срок: до ревью дизайна).

Метки сообщают каждому читателю, что эти требования относятся к выбору окна для записи, а у TBD есть ответственный и срок.

Источники и что почитать#

K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 10 (шаблон SRS, схемы меток, TBD, элементы интерфейса в SRS).
Шаблоны документов IBM Rational Unified Process (RUP): Software Requirements Specification (традиционная версия и версия с вариантами использования).
Ю. А. Маглинец. Анализ требований к информационным системам: конспект лекций. Красноярск: Сибирский федеральный университет, 2007. Лекция 6 (шаблон-контейнер RUP, список вопросов, сравнение с ГОСТ).