Это учебное собеседование по системному анализу. Конкретная компания и кандидат здесь не указаны: формат нужен, чтобы последовательно пройти основные вопросы позиции. Мы собрали правильные ответы и добавили простые примеры, которые помогают не заучивать определения, а понимать смысл.
На интервью системного аналитика обычно проверяют четыре слоя: требования, моделирование, данные и интеграции. Сильный ответ начинается с короткого определения, продолжается примером и заканчивается объяснением, зачем это нужно проекту.
Чем системный аналитик отличается от бизнес-аналитика
Короткий ответ: системный аналитик переводит потребность бизнеса в требования к информационной системе. Бизнес-аналитик чаще исследует процессы, проблемы и ожидаемую ценность изменений.
Граница между ролями зависит от компании. Поэтому не стоит отвечать так, будто существует единственно верное разделение. Лучше назвать основной фокус и сразу добавить оговорку.
Системный аналитик уточняет данные, интеграции, ограничения, API, состояния и ошибки. Например, бизнес хочет ускорить оформление заказа. Бизнес-аналитик описывает проблемный процесс и целевой результат, а системный — какие данные запросит сервис, как проверит остатки и что вернёт при недоступности оплаты.
Каким должно быть хорошее требование
Короткий ответ: требование должно быть однозначным, полным в своём контексте, проверяемым, выполнимым и связанным с целью.
Фраза «система должна работать быстро» не годится: у неё нет измеримого критерия. Лучше написать: «95% запросов поиска должны завершаться не дольше чем за 800 мс при нагрузке 500 запросов в секунду». Теперь команда понимает условие, а тестировщик может его проверить.
Функциональные требования описывают поведение системы: например, пользователь может восстановить пароль. Нефункциональные задают свойства и ограничения: время ответа, доступность, безопасность, объём нагрузки.
Валидация отвечает на вопрос «мы описали то, что действительно нужно пользователю?». Верификация — «требование сформулировано корректно и соответствует правилам?». На практике нужны обе проверки.
Чем User Story отличается от Use Case
Короткий ответ: User Story кратко фиксирует потребность и ценность, а Use Case подробно раскрывает взаимодействие пользователя с системой.
User Story удобно строить так: «Как клиент, я хочу сохранить адрес, чтобы быстрее оформлять следующие заказы». Для неё нужны критерии приёмки: что считать сохранением, какие поля обязательны, что происходит при ошибке.
Use Case включает участников, предусловия, основной сценарий, альтернативы и результат. Он полезен, когда одного предложения уже недостаточно. Например, при оплате нужно описать успешный путь, отказ банка, повторный запрос и истечение времени ожидания.
Для оценки User Story часто используют INVEST: независимость, обсуждаемость, ценность, оцениваемость, небольшой размер и проверяемость. На интервью достаточно раскрыть смысл критериев на одном примере.
Когда использовать BPMN, а когда UML
Короткий ответ: BPMN лучше показывает бизнес-процесс, а UML — структуру системы и взаимодействие её частей.
В BPMN важно понимать события, задачи, шлюзы, пулы и дорожки. Пул отделяет участника процесса, а дорожка показывает роль или подразделение внутри участника. Шлюз управляет ветвлением: например, заявка либо проходит автоматическую проверку, либо уходит специалисту.
Пул отделяет участника процесса, а дорожки распределяют действия между ролями внутри него. Источник: Object Management Group.
В UML на системных интервью часто спрашивают диаграмму последовательности. Она показывает участников и порядок сообщений во времени. На примере входа в систему можно показать клиент, API, сервис авторизации и базу данных, включая неверный пароль и временную блокировку.
Хорошая диаграмма не обязана быть большой. Она должна быстро отвечать на вопрос, кто что делает и где возникают развилки.
Зачем нормализовать базу данных
Короткий ответ: нормализация уменьшает дублирование и защищает данные от противоречий.
Если имя клиента хранится в каждой строке заказа, его изменение придётся повторить много раз. При нормализации клиент хранится отдельно, а заказ ссылается на него по идентификатору. Это снижает риск, что в разных строках останутся разные значения.
Денормализация тоже бывает полезна. В аналитическом чтении можно заранее сохранить вычисленный итог, чтобы не собирать его из многих таблиц на каждый запрос. Цена такого ускорения — более сложное обновление данных.
Репликация создаёт копии данных для доступности и чтения, а шардирование делит данные между узлами. Это разные задачи, и на интервью важно не смешивать их.
Всегда ли микросервисы лучше монолита
Короткий ответ: нет. Микросервисы дают независимое развитие частей системы, но добавляют сетевые сбои, сложность данных и эксплуатации.
Монолит часто проще запустить, тестировать и изменять небольшой командой. Микросервисы оправданы, когда появились устойчивые границы предметных областей, разный профиль нагрузки или необходимость независимых релизов.
Если операция затрагивает несколько сервисов, обычной транзакции одной базы уже недостаточно. Паттерн Saga разбивает процесс на локальные шаги и предусматривает компенсирующие действия. Например, при отмене заказа нужно вернуть резерв товара и отменить платёж.
Сильный ответ содержит компромисс: какую проблему решает архитектура и какую новую сложность создаёт.
Типичная ошибка. Предлагать микросервисы как признак зрелой системы без данных о команде, нагрузке и границах предметной области. Получается дорогая распределённая система без подтверждённой пользы.
Как лучше. Сначала назовите проблему монолита, которую уже нужно решить, затем проверьте организационные и технические условия. Если независимые релизы и масштабирование пока не нужны, модульный монолит может быть сильнее.
Что важно знать про REST и HTTP
Короткий ответ: нужно понимать ресурсы, методы HTTP, коды ответа, идемпотентность и контракт API.
GET читает данные, POST обычно создаёт ресурс или запускает действие, PUT полностью заменяет представление ресурса, PATCH меняет часть, DELETE удаляет. Метод считается идемпотентным, если повтор одного и того же запроса не меняет итог после первого выполнения. Это особенно важно при повторной отправке из-за сетевого сбоя.
Контракт API должен описывать входные данные, успешный ответ и ошибки. OpenAPI помогает хранить это описание в машиночитаемом виде. Webhook работает в обратную сторону: система сама отправляет событие на заранее указанный адрес, вместо того чтобы клиент постоянно спрашивал об изменениях.
Получил бы кандидат оффер
Короткий ответ: определить это нельзя, потому что перед нами учебный формат без реального кандидата и решения компании.
Материал показывает хороший объём теории, но реальное интервью дополнительно проверило бы уточняющие вопросы, практические случаи и умение защищать принятое решение. Если кандидат способен объяснить эти темы своими словами и связать их с проектом, теоретическую часть он, скорее всего, пройдёт уверенно.
Проверить такую готовность можно в тренажёре собеседований ЮНИКОД: он помогает пройти вопросы по профессии, увидеть пробелы и повторить именно слабые темы.
Источники
частые вопросы
Короткие ответы
Что чаще всего спрашивают у Junior системного аналитика?
Обычно проверяют работу с требованиями, BPMN и UML, основы баз данных, HTTP и REST, а также понимание архитектуры и интеграций. Набор тем зависит от продукта и задач конкретной команды.
Нужно ли системному аналитику уметь программировать?
Для большинства Junior-позиций важнее понимать данные, API, ограничения систем и уметь точно описывать логику. Навык чтения кода полезен, но полноценная разработка обычно не является главной обязанностью.
Как отвечать, если не знаешь точного определения?
Скажите, как вы понимаете задачу, приведите практический пример и обозначьте, что именно хотите уточнить. Такой ответ лучше попытки угадать термин без связи с реальной системой.
