Портфолио системного аналитика: учебный кейс с API и данными

Учебная задача: бронирование переговорной

Вымышленный пример. Все данные синтетические. Ниже проектирование и ручная проверка сценариев; работающий сервер и production-интеграция не заявляются.

Пользователь выбирает комнату и интервал. Для этого кейса принимаем правила: начало раньше окончания, активные бронирования одной комнаты не пересекаются, отменённые не занимают время. Интервал считаем полуоткрытым: начало включено, конец исключён, поэтому бронь 10:00–11:00 допускает следующую с 11:00. Это явное допущение примера.

Авторизацию, повтор с тем же ключом, рабочие часы и срок хранения нужно согласовать отдельно. Пока они остаются в журнале вопросов, а не скрыто подразумеваются.

Контракт создания и ошибки

POST /bookings
Content-Type: application/json
{
  "room_id": 7,
  "start_at": "2026-10-20T10:00:00+03:00",
  "end_at": "2026-10-20T11:00:00+03:00"
}

201 Created
{"id": 42, "status": "active"}

Опишите тип каждого поля, обязательность и формат времени. Наличие смещения в примере не заменяет решения о том, какой часовой пояс принимает система и как хранит момент времени.

• 400: неверный формат или конец не позже начала.
• 404: указанной комнаты нет.
• 409: допустимый интервал пересекается с активной бронью той же комнаты.

В схеме ошибки используйте стабильный код и понятное сообщение, например {"code": "slot_conflict", "message": "Время уже занято"}. Не раскрывайте в ответе личность автора другой брони.

В OpenAPI зафиксируйте не только успешный ответ, но и ошибки с примерами. В sequence diagram покажите приём запроса, проверку входа, поиск комнаты, атомарную проверку и запись, ответ. Диаграмма описывает контракт; сама по себе она не реализует обработку.

Модель данных и пересечение интервалов

Room(id, name, capacity)
Booking(id, room_id, start_at, end_at, status)
Booking.room_id → Room.id

Два активных интервала пересекаются, если:
new.start_at < existing.end_at
и existing.start_at < new.end_at

Проверьте одинаковую комнату, статус и сопоставимость времён. Для выбранного полуоткрытого правила 09:00–10:00 и 10:00–11:00 не конфликтуют; 09:30–10:30 и 10:00–11:00 конфликтуют.

Отдельно разберите два одновременных запроса. Предварительный SELECT и последующая независимая запись не гарантируют отсутствие двойной брони. Проверка и запись должны быть защищены подходящим для выбранной СУБД атомарным механизмом. В этом учебном материале такой механизм не реализован и конкурентный тест не выполнен.

Что показать и как проверить

1. README и правила. Цель, границы, допущение об интервалах, неизвестные решения и ваш вклад.
2. Связанные артефакты. ER-модель с ключами, контракт OpenAPI, sequence diagram и примеры запроса/ответа. Поля и статусы должны называться одинаково.
3. Таблица ручных проверок. Обычная бронь, нулевой/обратный интервал, отсутствующая комната, частичное и полное пересечение, касание границ, отменённая бронь.
4. Ограничения. Повторы, конкуренция, авторизация и эксплуатация не превращаются в «готовую систему» без реализации и проверки.

В портфолио полезна история решения: что сначала было неоднозначно, какой вопрос вы задали и как ответ изменил контракт. Не добавляйте чужие токены, реальные бронирования и внутренние схемы работодателя.

Для резюме сократите кейс до подтверждённых действий: пример резюме системного аналитика. Перед встречей разберите вопросы о контракте и данных.