Спецификация варианта использования

Что раскрывает спецификация

Диаграмма вариантов использования хорошо показывает, кто и зачем взаимодействует с системой, но она почти ничего не говорит о деталях поведения. За овалом “Оформить заказ” или “Записаться на консультацию” может скрываться длинный процесс с предусловиями, альтернативами, исключениями и бизнес-правилами.

Спецификация нужна именно для раскрытия этого смысла. Она не заменяет диаграмму, а объясняет выбранный вариант использования в текстовой форме. После спецификации можно строить процессную модель, уточнять предметные объекты и проверять, какие требования покрываются.

Структура спецификации

Типовая структура спецификации:

Поле	Что фиксируется
Название	краткая цель в форме действия с результатом
Цель	зачем актор начинает взаимодействие
Основной актор	роль, которая инициирует сценарий
Заинтересованные лица	кто зависит от результата
Триггер	событие, запускающее взаимодействие
Предусловия	что должно быть истинно до начала
Основной сценарий	обычный успешный поток шагов
Альтернативные сценарии	допустимые варианты нормального выполнения
Исключительные сценарии	ошибки и ситуации, где цель не достигается полностью
Постусловия	что должно быть истинно после успеха
Минимальные гарантии	что сохраняется даже при неуспехе
Связанные требования	какие требования покрывает вариант использования
Связанные бизнес-правила	какие правила применяются в сценарии

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

При этом спецификация не должна превращаться в техническое описание интерфейса, API или базы данных. На этом уровне важны действия участника, реакции системы, бизнес-условия и результат. Детали вроде эндпоинтов, SQL-запросов, контроллеров и таблиц появятся позже, когда сценарий будет переводиться в техническую модель.

Мини-пример

Мини-пример для записи на консультацию:

Поле	Значение
Название	Записаться на консультацию
Основной актор	Студент
Триггер	Студент хочет выбрать время консультации
Предусловия	Студент авторизован; у преподавателя есть открытые интервалы
Постусловия	Создана активная запись; студент и преподаватель получили уведомления
Минимальные гарантии	При ошибке запись не создаётся, занятый интервал не блокируется
Бизнес-правило	Нельзя создать две активные записи на одно и то же время

Спецификация и сценарии

Спецификация отличается от сценария тем, что содержит не только последовательность шагов. Сценарий — это один путь выполнения внутри спецификации. У одного варианта использования может быть основной сценарий, несколько альтернативных и несколько исключительных потоков. Поэтому сначала фиксируется целостная карточка взаимодействия, а затем подробно описываются потоки.

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