Продолжение темы с не самыми очевидными советами по юз кейсам. Сегодня — про постусловия и исключения.

3. Постусловия. Мы часто трактуем это как результат выполнения юз кейса, но чтобы сделать этот компонент практически полезным, стоит добавить пару уточнений. Вначале сформулируем: постусловия — это состояния решения после выполнения юз кейса.

По пунктам:

1) “… решения”. Как и с предусловиями, акцент нужно сделать на решении, а не на юзере или ином контексте. Напоминаю, что юз кейс — это инструкции команде разработки, т. е. требования к решению. Постусловие вида “Актер просмотрел список товаров” бессмысленно, т. к. мы не можем в этом убедиться, не реализовав трэкинг его очей. В чем мы можем убедиться, так это в том, что “Список товаров в системе отображен на экране”.

2) “СостояниЯ…” Это не просто результат выполнения юз кейса, а всякие-разные состояния, которые нам важно подчеркнуть, чтобы разработчики, тестировщики и прочие убедились в том, что это реализовано. Например, для логина это может быть такой список: “Актер аутентифицирован в системе; актер находится на домашней странице; запись об успешном входе добавлена в логи.” Все это должно быть прослеживаемо по шагам в сценариях, но здесь мы собираем воедино все те выходные состояния, которые считаем важными для итоговой наглядной суммаризации: “Бойцы, убедитесь, что по результатам выполнения юз кейса вот эти вещи — истина”.

3) Есть разные взгляды на то, актуальны постусловия только для успешного выполнения юз кейса (основной и альтернативные сценарии) или и для неуспешных тоже (исключительные сценарии). Тут просто имейте в виду, что никто не мешает делать так, как лучше работает для коммуникации требований команде. Мне вполне нравится подход подчеркнуть и те постусловия, которые я хочу явно вынести для читателей в контексте ряда исключительных сценариев. Например, для логина постусловием в случае неуспешного входа может быть “Запись о попытке логина добавлена в логи”. Важно только наглядно подчеркнуть, для каких сценариев какой набор постусловий актуален.


4. Исключительные сценарии:

Как искать исключения (т. е. то, что не приводит к успешному завершению юз кейса в отличие от основного и альтернативных)?

Понятно, что это важная штука в функциональных требованиях. Без них требования сформулировать весьма просто; исключительные же сценарии начинают напрягать нашу думалку. Если мы структурированно подали шаги всех успешных сценариев, то поиск исключений не должен вызвать проблем. Подход прост: смотрим на каждый шаг успешных сценариев и начинаем брейнстормить: “Что тут может пойти не так?” При этом важно помнить две штуки:

- Наша конечная задача в контексте детализации юз кейса — требования для команды. А потому релевантные для нас исключения — это те ситуации, в которые мы хотим вложить реакцию системы.

- Исключения — это не только “что-то пошло не так”. Это ещё и когда актер сам направил юз кейс в неуспешную сторону (типовой пример — отмена операции).

Пример: Войти в систему

1) Актер открывает страницу входа. Тут может упасть Интернет, в сервер может вдарить метеорит или в мире поднимется зомби-восстание (и актеру будет уже не до входа). Нас такие исключения волнуют? Нет, ибо мы не хотим / не можем обработать подобное реакцией системы.

2) Система отображает эту страницу. Аналогично. Едва ли тут что-то может пойти не так, не считая каких-то багов (система лежит и не может отдать страницу). Баги нас также не волнуют, т. к. это не требования, которые мы хотим вложить в поведение системы. Бонусом, правда, можно обдумать те редкие ситуации, когда мы костыльным образом вкладываем реакции системы на внутренние баги: например, зная, что в бизнес-логике часто происходят незначительные ошибки, мы вместо того, чтобы это пофиксить, добавляем сообщение вида “Операцию сделать не удалось — внутренняя ошибка”. При этом контекст таков, что пока такое сделать проще и дружелюбнее, чем оставить падения системы и упорно фиксить все эти баги до лучших времен.