В чем суть:
Легко описать базовые успешные сценарии поведения системы. Когда юзер делает X или наступает событие Y — вот как по шагам должна реагировать система. Некоторые юзер стори на этом у людей и заканчиваются (да что уж там — у некоторых бизнес-анализ на этом начинается и заканчивается… а потом удивляемся, почему на нас девелоперы смотрят
Воспользуюсь примером из своей же статьи про юз кейсы, ибо юз кейсы — это как раз прекрасный способ не упустить такие сценарии (если юз кейсы не близки, представьте, что вы пишете юзер стори — думается, ваши критерии приемки не сильно отличаются от описанного ниже). Итак, черновой основной cценарий юз кейса Снять наличные для системы Банкомат:
1. Актер вставляет банковскую карту в банкомат.
2. Система предлагает актеру ввести ПИН-код карты.
3. Актер вводит ПИН-код и подтверждает ввод.
4. Система отображает список доступных операций с банковской картой.
5. Актер инициирует операцию снятия наличных средств.
6. Система предлагает актеру указать сумму для снятия средств.
7. Актер выбирает интересующий его вариант суммы из отображенных на экране.
8. Система отправляет запрос вторичному актеру на вычет запрошенной суммы из баланса актера на счету, привязанном к текущей карте.
9. Система получает подтверждение о вычете суммы со счета актера от вторичного актера.
10 Система выдает в слот для наличных средств запрошенную актером сумму.
11. Система печатает чек, отражающий детали выполненной операции по снятию наличных средств.
Собственно, простейшая ошибка, которую вы можете совершить касательно поведения системы, — это не подумать о том, что может пойти не так.
Как не сделать ошибку? А довольно просто: возьмите каждый шаг базового сценария (если вы, конечно, не в форме эссе это описывали, а систематизировали, как выше, плюс атомаризировали шаги). И спросите свое критическое мышление: а что в шаге может пойти не так, как заложено сценарием? Желательно пока что ограничиться действиями актёра в системе и событиями системы (включая ее внешние зависимости), а не рандомными факторами окружающей среды (например, актер палец сломал о клавишу банкомата или банкомат провалился под землю из-за внезапно начавшегося землетрясения). Да, там тоже могут лежать требования разного вида, но это уже более продвинутый вариант.
3: Человек может ввести код неверно? А может он не цифровую клавишу нажать, а что-нибудь типа Enter случайно?
8, 9: Бабосиков на счету может не хватить? Сервис проверки этого факта может не быть доступен (ну вот сломался и лежит)? Сетка, по которой надо запросы на проверку отправить, может отвалиться?
10. Налички может не хватить?
11. Бумаги может не оказаться? А краски?
Человек на любом шаге до завершения операции может захотеть отменить ее?
После того, как вы поднатужились и крепко подумали, далее нужно:
а) Решить, будете ли вы что-то с каждым ответвлением делать или же забьете на это. Второй вариант, конечно, так себе, но бывают вопросы бюджетов, сроков, приоритетов и пр.
б) Если таки нужно сие учесть, то решить, как: предотвратить внештатную ситуацию ИЛИ обработать ее по факту наступления. Тут есть общее rule of thumb: предотвращение ошибки лучше уведомления о ней по факту совершения. Но опять-таки иногда в игру вступают бюджеты, сроки, ограничения технологий и пр. факторы.