При подготовке к собеседованию системного аналитика полезно пройти одну задачу целиком: уточнить потребность, описать правила, связать данные с API и показать проверяемый результат. Так обнаруживаются пробелы, которые трудно заметить при заучивании определений UML, REST или SQL.
На Mentoring.digital разберём учебный сервис бронирования переговорных. Все условия придуманы для упражнения. Это не описание внедрённой системы и не задание конкретной компании. Используйте его, чтобы проверить связность собственного решения и подготовить вопросы интервьюеру.
Какие вопросы про требования стоит разобрать
Как отличить бизнес-потребность от функции?
«Сотрудники должны реже сталкиваться с занятыми переговорными» описывает желаемое изменение. «Пользователь создаёт бронь комнаты на интервал» описывает действие системы. Между ними нужно установить связь: почему выбранная функция поможет, какие правила необходимы и по каким данным оценивать результат.
Что делать с требованием «система должна быстро работать»?
Уточнить операцию, измерение, условия и критерий. Для поиска свободных комнат понадобятся согласованные время ответа, размер данных и нагрузка. Не назначайте произвольное число как обязательную норму. Пока условия не согласованы, такое требование нельзя одинаково проверить на разных стендах.
Чем пользовательская история отличается от сценария использования?
История кратко связывает роль, потребность и пользу. Сценарий использования позволяет подробнее описать предусловия, основной путь, альтернативы и результат. Для бронирования полезно перейти от короткой истории к веткам: свободно, занято, неверный интервал, недостаточно прав.
Начните кейс с вопросов, а не с таблиц
Исходная просьба звучит так: «Нужен сервис бронирования переговорных». До проектирования выясните:
- Кто создаёт и отменяет бронь: сотрудник, администратор или оба?
- Можно ли бронировать за другого человека и видеть сведения о чужой встрече?
- В какой временной зоне вводятся даты и как отображаются в другом офисе?
- Разрешены ли соседние интервалы, например 10:00–11:00 и 11:00–12:00?
- Есть ли повторяющиеся встречи, оборудование и ограничения вместимости?
- Что происходит после отмены, а что после закрытия комнаты на ремонт?
Для первой версии упражнения договоримся: только разовые брони, один владелец, одна комната, начало раньше конца. Соседние интервалы разрешены. Отменённая бронь не занимает комнату. Повторяющиеся встречи оставляем за пределами версии и явно фиксируем это ограничение.
Как связать модель данных с правилом пересечения
Достаточно трёх сущностей: пользователь, комната и бронь. У брони есть собственный идентификатор, ссылки на пользователя и комнату, начало, конец и статус. Внешний ключ помогает не ссылаться на несуществующую комнату. Проверка начала и конца отвечает за корректность одного интервала.
Но правило «в комнате не бывает двух активных броней на одно время» проверяет отношения между записями. Уникальность комбинации комнаты, начала и конца запрещает только полные совпадения. Интервалы 10:00–11:00 и 10:30–11:30 различны, хотя пересекаются.
new_start < existing_end
AND new_end > existing_startЭто условие пересечения для интервалов с разрешённым соседством. Проверять нужно ту же комнату и только статусы, занимающие время. На интервью объясните и гонку: две операции могут одновременно увидеть свободный интервал. Одной предварительной проверки перед вставкой недостаточно. Нужен согласованный механизм атомарного контроля в выбранной СУБД, например подходящее ограничение или сериализованная проверка с блокировкой. Конкретный способ выбирают вместе с разработчиками и проверяют конкурентным тестом.
Что должно быть в контракте API
Опишите назначение операции, авторизацию, поля запроса, результат и ошибки. Не доверяйте переданному клиентом владельцу без проверки прав: в нашем учебном контракте владелец берётся из авторизованной сессии.
POST /bookings
{
"room_id": 12,
"starts_at": "2026-11-02T10:00:00+03:00",
"ends_at": "2026-11-02T11:00:00+03:00"
}Для упражнения согласуем 201 при создании и 409 при конфликте с активной бронью. В успешном ответе нужны идентификатор, сохранённые поля и статус. Ошибка должна позволять клиенту отличить занятое время от неверного формата данных. Это выбранный контракт приложения, а не правило, что любой сервис обязан отвечать именно так на все ошибки.
В описании API зафиксируйте также обязательность полей, формат дат, допустимые статусы и пример каждого существенного ответа. Схема OpenAPI помогает записать контракт, но не заменяет описание конкурентного поведения и правил доступа.
Как ответить на вопрос о повторе после тайм-аута
Тайм-аут клиента не сообщает, была ли бронь создана. Сервер мог сохранить запись, но ответ не дошёл. Если клиент просто повторит POST, возможно повторное действие. Нужно договориться о безопасном восстановлении результата.
- Определите, как клиент обозначает одну попытку бронирования: например, отдельным ключом идемпотентности.
- Свяжите ключ с пользователем, входными данными и сохранённым результатом. Повтор той же операции должен возвращать согласованный результат.
- Задайте поведение для того же ключа с другим телом, параллельных повторов и истёкшего срока хранения ключа.
- Предусмотрите чтение статуса операции, если она может завершаться позже ответа.
Слово «идемпотентность» без этих правил не решает задачу. Также не стоит обещать надёжность только потому, что добавлена очередь: при асинхронном обмене нужно отдельно описать доставку, повторы, порядок и обработку неуспешных сообщений.
Какие критерии приёмки делают решение проверяемым
| Ситуация | Ожидаемое поведение в учебном контракте |
|---|---|
| Свободная комната, корректное время | Создана одна активная бронь с нужным владельцем |
| Пересечение с активной бронью | Отказ, новая бронь не появилась |
| Следующая встреча начинается в момент окончания предыдущей | Создание разрешено |
| Предыдущая бронь отменена | Её интервал больше не блокирует время |
| Два одновременных запроса на пересекающиеся интервалы | Не более одной активной брони |
| Повтор с тем же ключом и телом | Возвращён прежний результат, повторной записи нет |
| Другой пользователь отменяет чужую бронь без прав | Отказ без изменения записи |
Каждый критерий связан с конкретным правилом. Чтобы показать трассируемость, присвойте правилу идентификатор и свяжите его с операцией API и проверкой. Если правило меняется, будет видно, какие части описания и тестирования нужно пересмотреть.
Как тренироваться перед интервью
Сначала объясните задачу словами. Затем покажите сущности, один основной сценарий и две ошибки. Для последовательности вызовов подойдёт диаграмма взаимодействия; для бизнес-процесса с участниками и ветвлениями может пригодиться BPMN. Выбирайте нотацию под вопрос, а не для количества схем.
На курсах системного анализа можно согласовать практику требований и проектирования. А наставнику по системному анализу полезно принести свой контракт и попросить найти противоречия: где нет владельца правила, не определена ошибка или невозможно проверить результат.
На самом собеседовании отделяйте опыт от учебных решений. Если не знаете конкретный механизм СУБД, назовите требуемое свойство и способ проверки, вместо того чтобы выдавать предположение за гарантию.
