Что теряет аналитик, если описывает вариант использования только через основной успешный сценарий?
Он теряет альтернативные и исключительные потоки: отмены, отказы, повторные попытки, недоступность зависимостей и другие условия, при которых цель пользователя достигается иначе либо не достигается. В результате требования описывают идеальный путь, а разработанное решение оказывается неполным для реальной эксплуатации.
Варианты использования появились как способ описывать поведение системы через цели и взаимодействия пользователей, а не через внутреннюю реализацию. Такой подход решал проблему спецификаций, в которых подробно фиксировались функции системы, но не рассматривались реальные сценарии работы, ошибки и реакции участников.
Основной успешный сценарий показывает только последовательность действий при нормальных условиях. Реальный процесс содержит неполные данные, отказы, ограничения прав, тайм-ауты, отмены и повторные обращения.
Если эти ситуации не зафиксированы, команда вынуждена додумывать поведение системы. Разные участники могут принять разные решения, а ошибки обнаружатся поздно — на тестировании или после внедрения. Особенно опасны пропуски, связанные с финансовыми операциями, безопасностью, юридическими ограничениями и изменением состояния объекта.
После фиксации основной цели аналитик проверяет каждую значимую точку сценария: какие условия могут нарушить продолжение потока, какие данные могут оказаться недействительными, какие роли могут отказаться от действия и какие внешние зависимости могут быть недоступны.
Для каждого существенного отклонения описывают альтернативный поток, если цель достигается другим способом, либо исключительный поток, если выполнение прекращается или переходит в обработку ошибки. В описании нужно зафиксировать условие возникновения, реакцию системы, решение участника и итоговое состояние объекта.
Важно не превращать вариант использования в каталог всех мыслимых ошибок. Включают отклонения, которые меняют поведение системы, влияют на бизнес-результат, создают риск или требуют отдельного решения. Малозначимые детали можно оставить на уровне проектирования.
Полноту проверяют по нескольким источникам: интервью с исполнителями, анализу действующего процесса, бизнес-правилам, журналам ошибок, обращениям пользователей и проверке состояний объекта. Такой анализ связывает сценарии с требованиями и критериями приемки.
Компромисс состоит в выборе уровня детализации. Слишком краткое описание скрывает риски, а чрезмерно подробное затрудняет чтение и быстро устаревает. Практично подробно фиксировать потоки, которые меняют результат, права доступа, денежные расчёты, обязательства или состояние процесса.
Для оформления возврата товара команда описала только успешный путь: клиент выбирает заказ, оператор проверяет данные, система создаёт возврат.
Аналитик рассмотрел три варианта. Можно было оставить сценарий как есть — это быстро, но ошибки пришлось бы трактовать во время разработки. Можно было описать все возможные сбои — это давало бы полноту, но перегружало модель малозначимыми деталями. Третий вариант — выделить бизнес-значимые отклонения: срок возврата истёк, товар уже возвращён, заказ оплачен частично, проверка внешней платёжной системы недоступна.
Выбрали третий вариант. Для каждого отклонения определили действие системы и конечное состояние возврата: отказ, ожидание проверки или ручная обработка. В результате тестировщики получили проверяемые сценарии, а бизнес заранее согласовал правила спорных случаев.
Альтернативный поток — это допустимый вариант продолжения процесса, при котором цель сценария всё ещё может быть достигнута. Исключительный поток возникает при нарушении условия или ошибке и обычно приводит к отказу, остановке, повтору либо передаче на ручную обработку. Граница определяется не видом технической ошибки, а влиянием ситуации на достижение цели и итоговое состояние.
Да, если они влияют на результат или на переход сценария. Внешнюю систему не следует моделировать как внутреннюю часть решения, но её запрос, ответ, отказ или задержку нужно показать как взаимодействие с отдельным участником. Иначе останется неясным, что должна делать система при отсутствии ответа или при недействительном результате.
Исполнитель обычно хорошо знает свой участок, но может не видеть последующие последствия, ограничения другой роли или исключения, возникающие у клиента. Полноту проверяют с участниками, которые инициируют сценарий, принимают результат, обрабатывают отказ или отвечают за контроль. Дополнительно полезно сопоставить описание с регламентами, данными фактического процесса и историей ошибок.