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