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