01
Сначала — границы задачи
В учебном интернет-магазине покупатель создаёт заказ и оплачивает его по ссылке. Доставка начинается после подтверждённой оплаты. Рассматриваем создание, ожидание платежа, успех и отказ; возвраты, скидки и резервирование остатков оставляем за границами примера.
В SAQA создайте систему «Интернет-магазин». Документ с границами и сценарием разместите у продукта «Заказы». Так описание будет связано с объектом, к которому относится.
Это учебная система. Адреса, API и правила заказа здесь — пример содержания, а не функции магазина внутри SAQA.
02
Покажите участников на карте
Разделите систему на продукты «Витрина», «Заказы», «Каталог», «Оплата», «Доставка» и «Уведомления». Внутри добавьте сервисы и свяжите их по взаимодействиям. На карте важны ответственность компонента и направление обмена; подробности запроса оставьте в описании связи.
| Откуда → куда | Что происходит |
|---|---|
| Витрина → Order API | Передаёт корзину и ключ повторного вызова. |
| Order API → Catalog API | Уточняет доступность и цену. |
| Order API → Payment API | Создаёт платёжную попытку. |
| Payment API → Order API | Сообщает результат оплаты отдельным подтверждением. |
| Order API → Доставка и уведомления | После успешной оплаты инициирует дальнейшие действия. |
03
Разделите создание заказа и результат оплаты
Постройте BPMN-процесс: создать заказ, получить результат оплаты, проверить результат. У шлюза две ветки: успешный платёж переводит заказ в paid, отказ оставляет pending_payment. На успешной ветке добавьте передачу в доставку и уведомление.
Для технического обмена создайте UML-диаграмму. В скачиваемом PlantUML показаны участники, вызовы и альтернативные ветки. Скопируйте исходный код в редактор UML SAQA и сохраните диаграмму.
Создание заказа и результат оплаты
SAQA помогает моделировать процесс. Нарисованная схема сама по себе не создаёт заказ и не выполняет платёж.
04
Запишите правила, которых нет на схеме
В спецификации зафиксируйте ограничения полей, статусы, ошибки и повторные вызовы. Например: quantity — положительное целое; итоговую стоимость определяет сервис, а не покупатель; повтор одного запроса не создаёт второй заказ.
Отдельно запишите поведение при повторном подтверждении оплаты. Иначе команда может согласовать защиту от второго заказа, но забыть про повторную доставку или уведомление. Готовый пример спецификации есть в материалах ниже.
- Основной путь: корректная корзина → pending_payment → подтверждение → paid.
- Отказ: платёж отклонён → заказ остаётся pending_payment.
- Повтор: тот же ключ и тело → исходный заказ; изменённое тело с тем же ключом → конфликт.
05
Подготовьте запрос для проверки контракта
В API-клиенте создайте запрос POST, укажите адрес своего тестового сервиса, заголовки Content-Type и Idempotency-Key и тело ниже. Сохраните запрос в коллекции Order API. Учебный api.example.com нужно заменить адресом вашей реализации.
| Проверка | Ожидается в примере |
|---|---|
| Новая корректная корзина | 201, один заказ pending_payment, ссылка на оплату. |
| Пустая корзина | 400, заказ не создан. |
| Товар недоступен | 409, заказ не создан. |
| Повтор с тем же ключом и телом | Исходный order_id, без второго заказа. |
{
"customer_id": "customer-001",
"items": [{ "sku": "SKU-042", "quantity": 2 }]
}201 подтверждает создание заказа, а не оплату. Сравнивайте фактический ответ тестового сервиса со спецификацией.
06
Сопоставьте контракт с данными
В ERD нужны три сущности: orders, order_items и payment_attempts. Строки заказа и платёжные попытки ссылаются на orders. В диалоге импорта SQL выберите PostgreSQL и вставьте содержимое checkout-schema.sql. После импорта проверьте поля и две связи.
Обозреватель БД помогает проверить фактические данные подключённой системы. Например, после запроса найдите созданный заказ и сравните его статус и сумму с ответом API. SQL-модель из материала описывает структуру, но не реализует все бизнес-правила.
SELECT order_id, status, total_minor, currency
FROM orders
WHERE order_id = 'ord-001';07
Передайте изменение в работу
Создайте канбан-доску у продукта «Заказы». Отдельные карточки: согласовать правила повтора, реализовать создание заказа, обработать подтверждение оплаты, проверить отказ и повтор. Укажите ответственных, сроки и подзадачи. Для технической карточки можно выбрать связанный сервис.
| Риск / участник | Как зафиксировать |
|---|---|
| Повторный платёж или повторная доставка | Риск: триггер, ответственный и план реакции; связь с сервисом и задачей проверки. |
| Владелец продукта | Согласует поведение отказа и повторной оплаты. |
| QA и поддержка | Уточняют наблюдаемое поведение и способ поиска заказа. |
08
Проверьте, что описание пригодно для команды
- По карте понятно, какие сервисы участвуют в заказе.
- BPMN и спецификация одинаково описывают успешную оплату и отказ.
- Для каждого критерия приёмки есть проверка и ожидаемый результат.
- Неизвестные условия записаны вопросами, а не скрыты в общих фразах.
- Участники получили нужные права на документы и инструменты.
МАТЕРИАЛЫ ДЛЯ РАБОТЫ
Продолжите на своём примере
Спецификация заказа
Заполненный пример: границы, сценарии, API, ошибки и критерии приёмки.
Чек-лист проверки заказа
Десять проверок по учебной спецификации и поля для фактического результата.
Обмен сообщениями
Исходный код sequence-диаграммы для редактора UML.
Структура данных заказа
Три таблицы и две связи для импорта в ERD; диалект PostgreSQL.
Тело запроса создания
Учебные входные данные для ручной настройки HTTP-запроса.
Учебные правила и данные нужно адаптировать к вашей системе. Набор не является готовой реализацией магазина.
Скачать полный набор ↓