☀Объяснение: Это классический пример неполноты требований, когда описывается только «счастливый путь» (happy path), а поведение при сбоях и нештатных ситуациях остаётся за кадром. В реальной интеграции внешние системы могут не отвечать, выдавать ошибки, таймауты, возвращать некорректные данные. Если в требованиях не прописано, как система должна реагировать на такие события, разработчик принимает решение самостоятельно, и часто оно оказывается неоптимальным или противоречащим ожиданиям бизнеса. 1. Что такое требования к обработке исключений? Это часть нефункциональных требований (или расширение функциональных), которая явно описывает: Какие ошибки могут возникнуть (таймауты, некорректные ответы, недоступность сервисов). Как система должна их распознавать. Какие действия предпринимать (повторить запрос, откатить транзакцию, уведомить пользователя, зафиксировать инцидент). 2. Как должна была выглядеть правильная спецификация? Аналитик должен был добавить раздел «Обработка ошибок» к пользовательской истории или отдельное требование: UC-01: Перевод средств Успешный сценарий: деньги списываются, перевод помечается как выполненный, пользователь получает подтверждение. Таймаут шлюза (> 3 сек): система повторяет запрос 1 раз. Если повтор также таймаутит — перевод помечается как «требует проверки», деньги не списываются (или списываются, но с последующей компенсацией), пользователю показывается сообщение «Сервис временно недоступен, попробуйте позже». В лог фиксируется инцидент для ручного разбора. Без таких деталей разработчик может, например, реализовать автоматический повтор без ограничений, что создаст нагрузку на шлюз, или наоборот — при первой ошибке прервёт операцию, оставив перевод в неопределённом состоянии. 3. Реальный кейс В одном банке после запуска нового интернет-банкинга в часы пик 5% переводов «зависали» в статусе «в обработке». Выяснилось, что платёжный шлюз иногда отвечал дольше 30 секунд, и HTTP-клиент на стороне банка рвал соединение по таймауту. Поскольку в требованиях не было описано, что делать в такой ситуации, разработчик просто не обрабатывал этот сценарий — транзакция оставалась открытой, деньги не возвращались, пользователь не получал подтверждения. Потребовалась доработка через месяц после запуска, которая обошлась в 300 человеко-часов и репутационные потери. 4. Что должен сделать аналитик, чтобы избежать подобного? Выделить все точки интеграции и для каждой описать возможные сбои. Согласовать с бизнесом желаемое поведение: повторять запрос? сколько раз? с каким интервалом? что делать при исчерпании попыток? Зафиксировать обработку ошибок в виде таблицы или сценариев в формате Gherkin. Убедиться, что критерии приемки включают тесты на эмуляцию сбоев (таймауты, 5xx коды, некорректные данные). 5. Какой из вариантов ответа ближе всего? A (функциональные требования к интерфейсу): Не отражают обработку ошибок, только успешные сценарии. B (обработка исключительных ситуаций): Прямо соответствует упущенному. C (производительность): Касается времени работы, но не конкретно обработки сбоев. D (безопасность): В данном кейсе не применимо. Вывод: Полнота требований — это не только описание того, что система делает, но и того, как она ведёт себя, когда что-то идёт не так. Игнорирование обработки исключений — одна из главных причин сбоев на проде и недовольства пользователей. 🎯