Сценарий использования
Это часть большого документа, который описывает, как должна работать система или продукт. Сценарий использования объясняет, какие действия выполняет пользователь и как система должна на них реагировать.
Зачем нужен
Для того, чтобы перевести разрозненные требования в последовательность действий и реакций системы, понятную для всех участников проекта. В отличие от простых списков требований, сценарии использования описывают требования в динамике, показывая взаимодействие акторов с системой шаг за шагом. Это повышает ясность требований и снижает риск недопонимания между аналитиками, заказчиками и командой разработки.
Когда применять
Когда нужно понять, как пользователь будет взаимодействовать с системой. Сценарий использования фокусируется на том, что должна делать система, не уходя в детали реализации. Это понятное описание функциональных требований, которое могут использовать разработчики, тестировщики и дизайнеры при создании продукта.
Когда не работает
- Когда нужно описать внутреннюю логику системы, потому что Сценарий использования фокусируется исключительно на том, как пользователь взаимодействует с системой, и не покрывает технические детали или внутренние процессы. Если необходимо зафиксировать, как реализуются бэкенд-процессы — этот инструмент будет недостаточным.
- Если важны нефункциональные требования. Сценарий использования не учитывает характеристики производительности, безопасности, отказоустойчивости или масштабируемости. Он может описать, как пользователь покупает билет, но не покажет, что система должна выдерживать тысячи одновременных обращений или обеспечивать шифрование данных.
- Когда нужно отразить временные зависимости и параллелизм. Сценарий использования не показывает, какие действия происходят одновременно, с какой задержкой выполняются события или как распределяется время между шагами. Это делает его непригодным для описания систем, где критична временная координация.
Как применять
Когда сценарии согласованы, они становятся отличной основой для формализации функциональных требований. Каждый сценарий трансформируется в набор требований к системе: интерфейсам, логике, взаимодействиям между пользователем и системой. Далее сценарии используются в тестировании: они ложатся в основу тест-кейсов. Это позволяет заранее учесть все возможные ситуации и повысить надёжность системы. Также сценарии использования активно применяются в UI/UX-дизайне. Каждый шаг взаимодействия пользователя с системой, описанный в сценарии использования, должен быть логически отображён в интерфейсе. Дизайнеры используют их как основу для построения пользовательских потоков, проектирования экранов, диалогов, обработчиков ошибок и переходов между этапами. Благодаря этому интерфейс становится интуитивным и отражает логику работы, которую ожидает пользователь.
Детальное описание
Строгого международного стандарта шаблона для сценариев использования не существует – формат может немного различаться в зависимости от компании или проекта. Однако обычно описание каждого сценария оформляется в виде структурированной таблицы или разделов, включающих ряд обязательных полей. Ниже приведён рекомендуемый формат финальной таблицы для сценария использования с пояснениями по каждому разделу:
| Название | Короткое и понятное название сценария. Обычно формулируется как “Глагол + существительное”, отражая действие и цель. |
| Описание | Небольшой абзац, описывающий суть варианта использования. Здесь можно указать цель сценария (что пытается достичь пользователь) и общий контекст. |
| Участники | Основное действующее лицо (актор) и все дополнительные участники |
| Предусловие | Описание состояния системы до начала выполнения сценария. Предусловия – это условия, которые должны выполняться, чтобы конкретный сценарий имел смысл. |
| Триггер | Что провоцирует выполнение этого сценария. |
| Основной успешный сценарий | Последовательность шагов, в результате которой пользовательская цель достигается. Этот раздел часто оформляют в виде пронумерованного списка действий: попеременно действия акторов и системы, ведущие к успешному исходу. Каждый шаг должен быть чётко сформулирован: что делает пользователь и как реагирует система. Основной сценарий описывает “счастливый путь” – то есть ситуацию, когда всё идет правильно и ни одна ветвь не отклоняется от нормы. |
| Альтернативные сценарии | Все предусмотренные ответвления (варианты) от основного потока, при которых развитие событий отличается, но цель может быть в итоге достигнута другим способом. Альтернативные сценарии обычно возникают из условий “если/иначе” на определённых шагах основного сценария. |
| Негативные сценарии | Описания ситуаций, когда цель не достигается из-за ошибочных действий или сбоев. Обычно негативные сценарии представляют собой особые случаи альтернатив. Выделение их в отдельный раздел подчёркивает внимание на обработке ошибок и исключений. Формат описания такой же: условие ошибки и дальнейшие шаги системы/пользователя. |
| Конечное состояние | Состояние системы после выполнения сценария (будь то успешного или альтернативного/негативного). Постусловия описывают, что изменилось в системе. |
| Критерии приемки | Явные критерии, по которым можно судить, что сценарий реализован правильно и цель достигнута. По сути, это набор условий, которые должны быть выполнены, чтобы заказчик принял реализацию сценария. Критерии приемки часто пересекаются с постусловиями и результатами, но формулируются с точки зрения проверки/теста. |
Пример
| Название | Регистрация нового пользователя |
| Описание | Пользователь заполняет регистрационную форму на сайте, система сохраняет нового пользователя и предоставляет ему доступ к личному кабинету. |
| Участники | Незарегистрированный пользователь (основной), Система (как участник взаимодействия). |
| Предусловие | Пользователь находится на странице регистрации. Пользователь не имеет учётной записи. |
| Триггер | Пользователь решил создать новую учётную запись (нажал “Регистрация”). |
| Основной успешный сценарий | 1. Пользователь заполняет форму регистрации (имя, email, пароль) и отправляет её. 2. Система проверяет корректность введённых данных (формат email, сложность пароля и т. д.). 3. Система сохраняет нового пользователя в базе данных. 4. Система отправляет письмо с подтверждением регистрации на email пользователя. 5. Система отображает пользователю сообщение об успешной регистрации и инструкции по подтверждению аккаунта. |
| Альтернативные сценарии | 2a. Система обнаруживает, что указанный email уже существует. 2b. Система отображает сообщение “Пользователь с таким email уже зарегистрирован” и предлагает восстановить пароль. 2c. Сценарий завершается неуспешно: регистрация не выполнена (пользователь может либо закрыть форму, либо инициировать восстановление пароля). |
| Негативные сценарии | 1a. Система не получила данные формы из-за сбоя сети. 1b. Система выводит пользователю сообщение “Ошибка соединения. Повторите попытку позже.” 1c. Сценарий прерван: пользователь не зарегистрирован. |
| Конечное состояние | При успешном сценарии – новый пользователь создан в системе, учётная запись в статусе “требуется подтверждение email”. При альтернативном/негативном – новый пользователь не создан (система без изменений). |
| Критерии приемки | Пользователь с уникальным email может успешно зарегистрироваться и его данные сохраняются. Система проверяет валидность email и пароля; при ошибках показывает понятные подсказки. Пользователь получает email с подтверждающей ссылкой. |