Junior Business Analyst — вопросы на собеседовании бизнес аналитика

В чём разница между функциональными и нефункциональными требованиями?

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

Как вы пишете user story? Что такое критерии приёмки?

User story строится по шаблону «как роль, я хочу действие, чтобы получить выгоду» — последняя часть важнее всего, потому что фиксирует «зачем» и позволяет команде предложить решение лучше. Критерии приёмки определяют готовность в проверяемых терминах, часто в формате Given-When-Then, покрывая основной сценарий, крайние случаи и ошибки. История без критериев — это приглашение трём людям понять её тремя разными способами.

Какие техники сбора требований вы используете?

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

Что делать, если стейкхолдеры дают противоречивые требования?

Нужно сделать конфликт явным, а не тихо выбрать одну сторону: зафиксировать обе позиции, аргументы за каждой и компромисс. Затем свести стейкхолдеров вместе с данными — цифрами использования, стоимостью, рисками — и получить решение от того, кто отвечает за результат. Ошибка в том, чтобы разрешить конфликт кулуарно: проигравшая сторона узнаёт об этом на приёмке, и работа уходит в отказ.

Что такое MoSCoW-приоритизация? Приведите пример.

MoSCoW раскладывает требования на Must have, Should have, Could have и Won't have в этот раз. Must — это то, без чего релиз не имеет ценности; Won't самая полезная категория, потому что делает исключения явными и останавливает тихое расползание скоупа. Распространённая дисциплина — держать Must примерно в шестидесяти процентах от ёмкости команды, чтобы осталось место под то, что неизбежно всплывёт по ходу.

Какие UML-диаграммы вы использовали? Когда use case, а когда sequence?

Диаграмма use case показывает, какие акторы взаимодействуют с какими возможностями системы — она хороша для разговоров о скоупе с бизнесом. Sequence-диаграмма показывает упорядоченные сообщения между компонентами во времени и адресована разработчикам, проектирующим взаимодействие. Activity и BPMN стоят между ними для описания процесса, а диаграмма состояний — правильный инструмент, когда у сущности есть жизненный цикл, например у заказа или заявки.