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

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

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

Как вы пишете 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 стоят между ними для описания процесса, а диаграмма состояний — правильный инструмент, когда у сущности есть жизненный цикл, например у заказа или заявки.

Что такое BRD, FRD и SRS? Чем они отличаются?

BRD фиксирует бизнес-потребности и цели на языке бизнеса — это «зачем». FRD переводит их в конкретное поведение системы — это «что». SRS это полная спецификация с функциональными и нефункциональными требованиями, ограничениями и интерфейсами, чаще для технической аудитории. Многие Agile-команды заменяют все три продуктовым бэклогом и лёгкими вспомогательными документами, оставляя формальные спецификации только там, где этого требует комплаенс.

Как вы проверяете, что требования понятны команде разработки?

Самый надёжный сигнал — вопросы на рефайнменте: молчание чаще означает, что команда не вникла, а не что всё понятно. Практические приёмы — попросить разработчика пересказать историю своими словами, разобрать критерии приёмки с QA до начала разработки и провести сессию example mapping или показать прототип, чтобы вытащить скрытые допущения. Всё найденное на этом этапе несравнимо дешевле, чем после реализации.