Вопросы на собеседовании системного аналитика

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

«Спрошу, какая операция должна быть быстрой, сколько пользователей работает одновременно и какое время ответа приемлемо. В требование запишу, что поиск по каталогу отвечает за 2 секунды при 500 одновременных пользователях».

Сервис доступен в часы пик продаж, а поиск и оплата укладываются в заданное время. Платёжные и паспортные данные хранятся защищённо, доступ к ним выдаётся по ролям. Одно место не продаётся дважды, даже если два человека нажали «купить» одновременно. Цифры я уточню у бизнеса, эксплуатации и службы безопасности.

Сначала выясню, какую проблему решаем и как поймём, что решили, кто пользователи и где границы задачи. Если просят баннер в личном кабинете, вопросы будут такими: «Кому и зачем показываем баннер? Кто меняет текст? Что будет, если пользователь его закроет? Как поймём, что баннер сработал?»

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

User story — это короткая потребность от лица пользователя, например «Как покупатель, я хочу сохранить корзину, чтобы вернуться к покупке позже». Use case по шагам описывает работу пользователя с системой вместе с альтернативными ветками и ошибками. Для сложного процесса с ветвлениями берут use case, а для небольшой доработки хватает истории.

Её пишут по шаблону «Как <роль>, я хочу <действие>, чтобы <ценность>» и добавляют условия готовности. Например: «Как покупатель, я хочу видеть статус доставки в личном кабинете, чтобы не звонить в поддержку. Готово, если статус обновляется после каждого события у службы доставки». Без части «чтобы» непонятно, зачем делать историю.

Техническое задание — это документ с требованиями к системе и порядком её создания, по нему ведут разработку и принимают результат. По ГОСТ 34.602-2020 в число обязательных разделов входят общие сведения, цели и назначение системы, характеристика объектов автоматизации, требования к системе, порядок контроля и приёмки, требования к документированию и источники разработки.

ГОСТ 34.602 описывает ТЗ на автоматизированную систему в целом. ГОСТ 19.201-78 описывает ТЗ на программу или программное изделие. ГОСТ 34.602-2020 действует с 1 января 2022 года и заменил ГОСТ 34.602-89, поэтому ссылаться на 89-й уже некорректно.

BPMN — это нотация для описания бизнес-процессов. Диаграмма строится из событий, задач, шлюзов для ветвлений и потоков между ними, а участников показывают пулы и дорожки. Оформление заказа клиентом будет стартовым событием, проверка наличия задачей, а развилка «есть товар или нет» шлюзом.

Ромб — это шлюз, точка, где поток расходится или сходится. Исключающий шлюз пускает процесс по одной ветке («оплата прошла или нет»), а параллельный запускает все ветки сразу («собрать заказ и выставить счёт»). Параллельные ветки потом собирают таким же шлюзом.

«BPMN беру для процесса с людьми, ролями и решениями, например чтобы показать, как заявка проходит через отделы. UML нужен для устройства системы. Диаграмма последовательности показывает, какие сервисы друг другу пишут и в каком порядке, а диаграмма классов показывает сущности и связи».

Сначала уточняю участников, начало и конец процесса. Потом рисую основной путь, где покупатель оформил заказ, система проверила наличие, покупатель оплатил, склад собрал и передал заказ в доставку. Затем добавляю ветки на случай, если товара нет, оплата не прошла или покупатель отменил заказ.

Синхронный вызов рисуют сплошной стрелкой с закрашенным наконечником, а ответ на него пунктирной стрелкой обратно. Асинхронный вызов рисуют стрелкой с открытым наконечником, потому что отправитель не ждёт ответа. Брокер сообщений рисуют отдельным участником.

Sequence показывает, кто кому и в каком порядке отправляет сообщения. Диаграмма активности показывает последовательность действий с ветвлениями и параллельными потоками, а участники в ней вторичны. По форме она похожа на BPMN, но чаще описывает логику внутри системы, а BPMN описывает процесс для бизнеса.

«Вот клиент оформил заказ. Дальше система проверяет, есть ли товар. Если есть, идём к оплате, а если нет, отправляем письмо с извинениями». После объяснения спрошу, всё ли совпадает с тем, как у заказчика работает на самом деле, потому что так и всплывают забытые ветки.

INNER JOIN оставляет только строки, у которых нашлась пара в обеих таблицах. LEFT JOIN оставляет все строки левой таблицы, а где пары нет, подставляет NULL. Если соединить клиентов с заказами через INNER JOIN, останутся только клиенты с заказами, а LEFT JOIN вернёт всех клиентов.

Соединю клиентов с заказами через LEFT JOIN и оставлю строки, где заказа не нашлось: «SELECT c.id, c.name FROM clients c LEFT JOIN orders o ON o.client_id = c.id WHERE o.id IS NULL». То же можно сделать через NOT EXISTS.

WHERE фильтрует строки до группировки, а HAVING фильтрует группы после неё, поэтому в HAVING пишут условия на агрегаты. Клиентов, у которых больше пяти оплаченных заказов, найдёт запрос «SELECT client_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY client_id HAVING COUNT(*) > 5».

Сначала уточню, считать ли последние 30 дней или прошлый календарный месяц и в каком поле хранится дата регистрации. Для PostgreSQL запрос может выглядеть так: «SELECT id, email, created_at FROM users WHERE created_at >= CURRENT_DATE - INTERVAL '1 month'».

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

Транзакция — это группа операций, которая выполняется целиком или не выполняется совсем. ACID обозначает её свойства: атомарность (всё или ничего), согласованность (данные остаются допустимыми), изолированность (параллельные транзакции не мешают друг другу) и долговечность (подтверждённое изменение переживёт сбой). Списание и зачисление при переводе идут одной транзакцией, иначе при сбое между ними деньги исчезнут.

Нормализация — это разбиение данных по таблицам так, чтобы каждый факт хранился в одном месте. Если адрес клиента записан в каждом заказе, после переезда заказы покажут разные адреса, поэтому адрес держат в таблице клиентов.

Денормализуют, когда чтение важнее записи, как в отчётах, витринах и аналитических хранилищах. Часть данных дублируют, чтобы читать одним запросом, а копии обновляют задачей по расписанию или по событию. Например, в отчёте по заказам имя клиента хранят прямо в строке заказа.

Сначала уточню, что продаёт магазин и нужна ли история цен. Потом выделю книги, авторов, покупателей, заказы и позиции заказа. Связь книг и авторов многие-ко-многим разверну промежуточной таблицей «книга — автор». Позиция ссылается на заказ и книгу и хранит количество и цену на момент покупки, иначе старые заказы «подорожают» вместе с каталогом.

GET получает ресурс, POST отправляет данные на обработку, чаще всего для создания, PUT создаёт или полностью заменяет ресурс, PATCH меняет его частично, DELETE удаляет. На заказах «GET /orders/15» получает заказ, «POST /orders» создаёт, «PATCH /orders/15» меняет адрес доставки, а «DELETE /orders/15» отменяет заказ.

PUT заменяет ресурс целиком, и поле, которого нет в теле запроса, пропадёт или сбросится. PATCH применяет набор изменений вроде «поменяй адрес», и остальное остаётся как было.

Метод идемпотентен, если несколько одинаковых запросов дают на сервере тот же результат, что и один. По RFC 9110 идемпотентны GET, HEAD, OPTIONS, TRACE, PUT и DELETE, а POST и PATCH нет. Два PUT с адресом доставки оставят тот же адрес, а два POST на создание заказа без защиты создадут два заказа.

Можно, так делают, когда фильтры поиска не помещаются в строку запроса. Но GET по стандарту безопасный (ничего не меняет) и идемпотентный (повтор даёт тот же результат), и клиенты и прокси знают, что его можно повторить, а POST таких гарантий не даёт. Создавать что-то через GET уже ошибка, потому что GET не должен ничего менять на сервере.

Коды 2xx означают успех, например 200 OK, 201 Created и 204, когда тела ответа нет. Коды 4xx сообщают об ошибке клиента, например 400 о неверном запросе, 401 об отсутствии действующих учётных данных, 403 о запрете доступа, 404 о ненайденном ресурсе, 409 о конфликте с его состоянием. Коды 5xx сообщают о сбое сервера, например 500 и 503. После 4xx запрос обычно нужно исправить, а после 503 его можно повторить через паузу.

По RFC 9110 401 Unauthorized означает, что у запроса нет действующих учётных данных, например токен не передан или истёк, и нужно войти. 403 Forbidden означает, что сервер знает, кто вы, но отказывает в доступе. Запрос к профилю без токена получит 401, а обычный пользователь, который запросил админку, получит 403.

SOAP — это протокол обмена XML-сообщениями со строгим контрактом в WSDL. REST — это архитектурный стиль, в котором ресурсы доступны по адресам, действия выражаются методами HTTP, а данные чаще идут в JSON. «Если партнёр отдаёт только SOAP-сервис, интегрируюсь по его WSDL, а своё новое API делаю на REST, потому что он проще».

В контракт входит всё, что нужно клиенту и серверу, чтобы договориться без созвона. Это адрес и метод, параметры, тело запроса и ответа с типами и обязательностью полей, коды ответа и формат ошибок, способ аутентификации и ограничения вроде частоты запросов. Описывают контракт обычно в OpenAPI (Swagger).

Сначала уточню, нужно ли только чтение или ещё создание и правка книг. «GET /books» возвращает список с постраничной выдачей по параметрам «page» и «size» и общее количество книг. «GET /books/{id}» возвращает одну книгу или 404, если её нет. Дальше опишу поля книги, фильтры по автору и жанру и ответ 400 на неверные параметры.

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

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

Брокер принимает сообщения от одной системы и доставляет другим, так что отправителю не нужно знать получателей и ждать их. Если получатель упал, сообщение подождёт в очереди. Например, событие «заказ оплачен» забирают склад, рассылка и аналитика, каждый в своём темпе.

RabbitMQ — это брокер очередей, в котором сообщение после подтверждения удаляется. Kafka — это распределённый журнал событий, где сообщения хранятся заданное время, а потребители читают их со своей позиции и могут перечитать. Поэтому RabbitMQ подходит для задач, которые надо выполнить и забыть, а Kafka для потоков событий, которые читают несколько систем.

Определю, сколько ждём ответа и сколько раз с какими паузами повторяем. Если повторы не помогли, сообщение уходит в очередь для разбора, а ответственный получает уведомление. Отдельно опишу, что видит пользователь, потому что «Заказ принят, подтверждение придёт в течение часа» лучше бесконечной загрузки.

Идемпотентный PUT или DELETE можно повторить автоматически, RFC 9110 это разрешает, если связь оборвалась до ответа. Для POST на создание заказа с системой-получателем договариваются об уникальном идентификаторе операции в запросе. Получив тот же идентификатор второй раз, система не создаёт новый заказ и отвечает так же, как в первый.

Монолит — это одно приложение с общей базой, которое выкатывают целиком. На старте его проще разрабатывать, но с ростом трудно менять по частям. Микросервисы — это небольшие сервисы со своими данными, которые общаются по API или через брокер. Их развивают независимо, но интеграций становится больше, а транзакция через несколько сервисов превращается в отдельную задачу.

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

Читаю по шагам вслух. Допустим, функция на Python обходит список заказов, для заказов со статусом «paid» прибавляет сумму к итогу и возвращает его. Тогда ответ будет таким: «Функция считает сумму оплаченных заказов». Незнакомую конструкцию так и называю незнакомой и предполагаю по названию, что она делает.

«Последние два года я системный аналитик в команде платежей. Описывал интеграции с банками по REST и через Kafka, писал постановки и контракты в OpenAPI. Самым заметным проектом был перевод возвратов на асинхронную схему, после него обращений в поддержку о зависших возвратах стало меньше. Хочу больше проектирования, поэтому откликнулся на вашу вакансию».

Опишите, что было сложно, например противоречивые требования, старая система без документации или жёсткий срок. Потом расскажите, что вы сделали лично, с кем поговорили и какое решение предложили, и закончите итогом, лучше с цифрой.

Разберусь, что изменилось и почему это срочно, и вместе с командой оценю, что сдвинется. Владельцу продукта предложу варианты: «Можем взять в этот спринт, но выгрузка для бухгалтерии уедет в следующий. Или делаем в следующем спринте». Договорённость зафиксирую в требованиях.

Выясню у каждого, какую задачу он решает, и покажу всем, где противоречие и во что обходится каждый вариант. Допустим, продажам нужна короткая анкета, а юристам все поля для договора. Тогда предложу короткую анкету на входе, а остальные поля запросить перед договором. Если договориться не получится, вынесу решение владельцу продукта.

Выслушаю аргументы и пойму, о чём спор. Если о способе реализации, у разработчика часто больше знаний, и решение можно поменять, пока оно закрывает требование. Если о самом требовании, вернусь к цели и данным, а при необходимости позову заказчика или архитектора. Итог зафиксирую в постановке.

«Перед стартом разбираю постановку с разработчиками и тестировщиком, вопросы записываю в задачу. Потом участвую в приёмке и после релиза проверяю, что поведение совпало с требованиями».

«В текущей команде я в основном пишу постановки по готовым решениям, а хочу участвовать в проектировании. У вас в вакансии это основная часть работы».