Спецификация варианта использования
Диаграмма вариантов использования хорошо показывает, кто и зачем взаимодействует с системой, но она почти ничего не говорит о деталях поведения. За овалом “Оформить заказ” или “Записаться на консультацию” может скрываться длинный процесс с предусловиями, альтернативами, исключениями и бизнес-правилами.
Спецификация нужна именно для раскрытия этого смысла. Она не заменяет диаграмму, а объясняет выбранный вариант использования в текстовой форме. После спецификации можно строить процессную модель, уточнять предметные объекты и проверять, какие требования покрываются.
Типовая структура спецификации:
| Поле | Что фиксируется |
|---|---|
| Название | краткая цель в форме действия с результатом |
| Цель | зачем актор начинает взаимодействие |
| Основной актор | роль, которая инициирует сценарий |
| Заинтересованные лица | кто зависит от результата |
| Триггер | событие, запускающее взаимодействие |
| Предусловия | что должно быть истинно до начала |
| Основной сценарий | обычный успешный поток шагов |
| Альтернативные сценарии | допустимые варианты нормального выполнения |
| Исключительные сценарии | ошибки и ситуации, где цель не достигается полностью |
| Постусловия | что должно быть истинно после успеха |
| Минимальные гарантии | что сохраняется даже при неуспехе |
| Связанные требования | какие требования покрывает вариант использования |
| Связанные бизнес-правила | какие правила применяются в сценарии |
Спецификация особенно полезна для сложных целей, где одного названия недостаточно. Название “Оформить заказ” кажется понятным, пока не начинаются вопросы: кто может оформить заказ, какие данные нужны, когда заказ считается оформленным, что происходит при отсутствии товара, как обрабатывается ошибка оплаты, какие уведомления отправляются и какие правила ограничивают действие.
При этом спецификация не должна превращаться в техническое описание интерфейса, API или базы данных. На этом уровне важны действия участника, реакции системы, бизнес-условия и результат. Детали вроде эндпоинтов, SQL-запросов, контроллеров и таблиц появятся позже, когда сценарий будет переводиться в техническую модель.
Мини-пример для записи на консультацию:
| Поле | Значение |
|---|---|
| Название | Записаться на консультацию |
| Основной актор | Студент |
| Триггер | Студент хочет выбрать время консультации |
| Предусловия | Студент авторизован; у преподавателя есть открытые интервалы |
| Постусловия | Создана активная запись; студент и преподаватель получили уведомления |
| Минимальные гарантии | При ошибке запись не создаётся, занятый интервал не блокируется |
| Бизнес-правило | Нельзя создать две активные записи на одно и то же время |
Спецификация отличается от сценария тем, что содержит не только последовательность шагов. Сценарий — это один путь выполнения внутри спецификации. У одного варианта использования может быть основной сценарий, несколько альтернативных и несколько исключительных потоков. Поэтому сначала фиксируется целостная карточка взаимодействия, а затем подробно описываются потоки.