Pepelen
← Системный анализ: API, интеграции и данные

Урок

Сквозной кейс: от истории к спецификации интеграции

По пользовательской истории «Ромашки» составить мини-спецификацию — системные требования, измеримое НФТ, контракт метода, событие, последовательность вызовов, затронутые статусы и SQL-проверку — и самопроверить её по чек-листу курса.

1 / 7

Собираем всё вместе

Спецификация — согласованный комплект

Настоящая задача системного аналитика — не отдельная диаграмма, а согласованный комплект, где одно не противоречит другому. Пример — отмена заказа из первого урока курса: • на диаграмме состояний перехода из in_delivery (в доставке) в cancelled (отменён) нет; • в требовании: «в статусах in_delivery и delivered (доставлен) сервис заказов отказывает в отмене»; • в контракте POST /v1/orders/{orderId}/cancel — ответ 409 с currentStatus; • в SQL-проверке: отменённых заказов, которые курьер успел забрать (picked_up_at IS NOT NULL), — 0 строк. Разные отказы — разные коды: мешает текущий статус — 409, данные нарушают правило (адрес вне зоны доставки) — 422, ресурса нет — 404. Формат ошибки один на весь API — Problem Details. Порядок работы над спецификацией — в шагах ниже. Перед сдачей проверьте себя по чек-листу частых ошибок курса: • описан только успех, отказов нет; • «быстро» вместо перцентиля, порога и нагрузки; • глагол в пути (/changeAddress) вместо метода; • в контракте только 200, а ошибка — в теле; • «брокер доставит ровно один раз», и дубли никто не отбрасывает; • событие-команда (ChangeAddress) вместо факта; • список значений в одной ячейке таблицы; • «= NULL» вместо IS NULL.
От истории к спецификации
  1. 1
    Системные требования

    Компонент, действие, данные, условие и отказ

  2. 2
    НФТ

    Метрика, порог и нагрузка

  3. 3
    Контракт

    Метод, путь, тело, все коды, формат ошибки, идемпотентность

  4. 4
    Интеграции

    Что синхронно, что событием; событие — факт с eventId и ключом сообщения

  5. 5
    Последовательность

    Шаги «кто → кому: что» с веткой отказа

  6. 6
    Статусы

    В каких статусах действие разрешено и что отвечаем в остальных

  7. 7
    Данные и проверка

    Поля и таблицы; SQL-запрос, который ищет нарушения

Конспект урока
Спецификация — согласованный комплект
Настоящая задача системного аналитика — не отдельная диаграмма, а согласованный комплект, где одно не противоречит другому. Пример — отмена заказа из первого урока курса: • на диаграмме состояний перехода из in_delivery (в доставке) в cancelled (отменён) нет; • в требовании: «в статусах in_delivery и delivered (доставлен) сервис заказов отказывает в отмене»; • в контракте POST /v1/orders/{orderId}/cancel — ответ 409 с currentStatus; • в SQL-проверке: отменённых заказов, которые курьер успел забрать (picked_up_at IS NOT NULL), — 0 строк. Разные отказы — разные коды: мешает текущий статус — 409, данные нарушают правило (адрес вне зоны доставки) — 422, ресурса нет — 404. Формат ошибки один на весь API — Problem Details. Порядок работы над спецификацией — в шагах ниже. Перед сдачей проверьте себя по чек-листу частых ошибок курса: • описан только успех, отказов нет; • «быстро» вместо перцентиля, порога и нагрузки; • глагол в пути (/changeAddress) вместо метода; • в контракте только 200, а ошибка — в теле; • «брокер доставит ровно один раз», и дубли никто не отбрасывает; • событие-команда (ChangeAddress) вместо факта; • список значений в одной ячейке таблицы; • «= NULL» вместо IS NULL.