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