Продолжение темы с не самыми очевидными советами по юз кейсам. Сегодня — про постусловия и исключения.
3. Постусловия. Мы часто трактуем это как результат выполнения юз кейса, но чтобы сделать этот компонент практически полезным, стоит добавить пару уточнений. Вначале сформулируем: постусловия — это состояния решения после выполнения юз кейса.
По пунктам:
1) “… решения”. Как и с предусловиями, акцент нужно сделать на решении, а не на юзере или ином контексте. Напоминаю, что юз кейс — это инструкции команде разработки, т. е. требования к решению. Постусловие вида “Актер просмотрел список товаров” бессмысленно, т. к. мы не можем в этом убедиться, не реализовав трэкинг его очей. В чем мы можем убедиться, так это в том, что “Список товаров в системе отображен на экране”.
2) “СостояниЯ…” Это не просто результат выполнения юз кейса, а всякие-разные состояния, которые нам важно подчеркнуть, чтобы разработчики, тестировщики и прочие убедились в том, что это реализовано. Например, для логина это может быть такой список: “Актер аутентифицирован в системе; актер находится на домашней странице; запись об успешном входе добавлена в логи.” Все это должно быть прослеживаемо по шагам в сценариях, но здесь мы собираем воедино все те выходные состояния, которые считаем важными для итоговой наглядной суммаризации: “Бойцы, убедитесь, что по результатам выполнения юз кейса вот эти вещи — истина”.
3) Есть разные взгляды на то, актуальны постусловия только для успешного выполнения юз кейса (основной и альтернативные сценарии) или и для неуспешных тоже (исключительные сценарии). Тут просто имейте в виду, что никто не мешает делать так, как лучше работает для коммуникации требований команде. Мне вполне нравится подход подчеркнуть и те постусловия, которые я хочу явно вынести для читателей в контексте ряда исключительных сценариев. Например, для логина постусловием в случае неуспешного входа может быть “Запись о попытке логина добавлена в логи”. Важно только наглядно подчеркнуть, для каких сценариев какой набор постусловий актуален.
4. Исключительные сценарии:
Как искать исключения (т. е. то, что не приводит к успешному завершению юз кейса в отличие от основного и альтернативных)?
Понятно, что это важная штука в функциональных требованиях. Без них требования сформулировать весьма просто; исключительные же сценарии начинают напрягать нашу думалку. Если мы структурированно подали шаги всех успешных сценариев, то поиск исключений не должен вызвать проблем. Подход прост: смотрим на каждый шаг успешных сценариев и начинаем брейнстормить: “Что тут может пойти не так?” При этом важно помнить две штуки:
- Наша конечная задача в контексте детализации юз кейса — требования для команды. А потому релевантные для нас исключения — это те ситуации, в которые мы хотим вложить реакцию системы.
- Исключения — это не только “что-то пошло не так”. Это ещё и когда актер сам направил юз кейс в неуспешную сторону (типовой пример — отмена операции).
Пример: Войти в систему
1) Актер открывает страницу входа. Тут может упасть Интернет, в сервер может вдарить метеорит или в мире поднимется зомби-восстание (и актеру будет уже не до входа). Нас такие исключения волнуют? Нет, ибо мы не хотим / не можем обработать подобное реакцией системы.
2) Система отображает эту страницу. Аналогично. Едва ли тут что-то может пойти не так, не считая каких-то багов (система лежит и не может отдать страницу). Баги нас также не волнуют, т. к. это не требования, которые мы хотим вложить в поведение системы. Бонусом, правда, можно обдумать те редкие ситуации, когда мы костыльным образом вкладываем реакции системы на внутренние баги: например, зная, что в бизнес-логике часто происходят незначительные ошибки, мы вместо того, чтобы это пофиксить, добавляем сообщение вида “Операцию сделать не удалось — внутренняя ошибка”. При этом контекст таков, что пока такое сделать проще и дружелюбнее, чем оставить падения системы и упорно фиксить все эти баги до лучших времен.
3. Постусловия. Мы часто трактуем это как результат выполнения юз кейса, но чтобы сделать этот компонент практически полезным, стоит добавить пару уточнений. Вначале сформулируем: постусловия — это состояния решения после выполнения юз кейса.
По пунктам:
1) “… решения”. Как и с предусловиями, акцент нужно сделать на решении, а не на юзере или ином контексте. Напоминаю, что юз кейс — это инструкции команде разработки, т. е. требования к решению. Постусловие вида “Актер просмотрел список товаров” бессмысленно, т. к. мы не можем в этом убедиться, не реализовав трэкинг его очей. В чем мы можем убедиться, так это в том, что “Список товаров в системе отображен на экране”.
2) “СостояниЯ…” Это не просто результат выполнения юз кейса, а всякие-разные состояния, которые нам важно подчеркнуть, чтобы разработчики, тестировщики и прочие убедились в том, что это реализовано. Например, для логина это может быть такой список: “Актер аутентифицирован в системе; актер находится на домашней странице; запись об успешном входе добавлена в логи.” Все это должно быть прослеживаемо по шагам в сценариях, но здесь мы собираем воедино все те выходные состояния, которые считаем важными для итоговой наглядной суммаризации: “Бойцы, убедитесь, что по результатам выполнения юз кейса вот эти вещи — истина”.
3) Есть разные взгляды на то, актуальны постусловия только для успешного выполнения юз кейса (основной и альтернативные сценарии) или и для неуспешных тоже (исключительные сценарии). Тут просто имейте в виду, что никто не мешает делать так, как лучше работает для коммуникации требований команде. Мне вполне нравится подход подчеркнуть и те постусловия, которые я хочу явно вынести для читателей в контексте ряда исключительных сценариев. Например, для логина постусловием в случае неуспешного входа может быть “Запись о попытке логина добавлена в логи”. Важно только наглядно подчеркнуть, для каких сценариев какой набор постусловий актуален.
4. Исключительные сценарии:
Как искать исключения (т. е. то, что не приводит к успешному завершению юз кейса в отличие от основного и альтернативных)?
Понятно, что это важная штука в функциональных требованиях. Без них требования сформулировать весьма просто; исключительные же сценарии начинают напрягать нашу думалку. Если мы структурированно подали шаги всех успешных сценариев, то поиск исключений не должен вызвать проблем. Подход прост: смотрим на каждый шаг успешных сценариев и начинаем брейнстормить: “Что тут может пойти не так?” При этом важно помнить две штуки:
- Наша конечная задача в контексте детализации юз кейса — требования для команды. А потому релевантные для нас исключения — это те ситуации, в которые мы хотим вложить реакцию системы.
- Исключения — это не только “что-то пошло не так”. Это ещё и когда актер сам направил юз кейс в неуспешную сторону (типовой пример — отмена операции).
Пример: Войти в систему
1) Актер открывает страницу входа. Тут может упасть Интернет, в сервер может вдарить метеорит или в мире поднимется зомби-восстание (и актеру будет уже не до входа). Нас такие исключения волнуют? Нет, ибо мы не хотим / не можем обработать подобное реакцией системы.
2) Система отображает эту страницу. Аналогично. Едва ли тут что-то может пойти не так, не считая каких-то багов (система лежит и не может отдать страницу). Баги нас также не волнуют, т. к. это не требования, которые мы хотим вложить в поведение системы. Бонусом, правда, можно обдумать те редкие ситуации, когда мы костыльным образом вкладываем реакции системы на внутренние баги: например, зная, что в бизнес-логике часто происходят незначительные ошибки, мы вместо того, чтобы это пофиксить, добавляем сообщение вида “Операцию сделать не удалось — внутренняя ошибка”. При этом контекст таков, что пока такое сделать проще и дружелюбнее, чем оставить падения системы и упорно фиксить все эти баги до лучших времен.