Аналитика

На согласовании заказчик формулирует требование: «Система должна быть удобной». Как аналитик должен преобразовать его, чтобы результат можно было однозначно принять?

Стейкхолдеры требуют взаимоисключающие сценарии: с чего начать анализ конфликта?

Как аналитик локализует узкое место процесса по данным о его этапах?

В ходе согласования требований одно изменение затрагивает несколько ролей и регламентов. Как определить полный радиус его последствий до утверждения?

Команда проектирует новый процесс, не зафиксировав текущий. Какой ключевой риск это создаёт при согласовании целевой модели?

После внедрения решения KPI улучшился, но бизнес-эффект вызывает сомнения. Как проверить, что изменение вызвано именно решением?

В требовании смешаны ограничение бизнеса и поведение системы. Как разделить их так, чтобы изменение политики не требовало переписывать функциональность?

На встрече все участники названы «заказчиками». Как аналитику определить, кто вправе принять окончательное решение по требованию?

При проверке бэклога обнаружено требование без ссылки на бизнес-цель. Как трассируемость помогает принять решение о его судьбе?

Компания выбрала бизнес-решение по многокритериальной оценке. Как проверить устойчивость этого выбора к изменению весов критериев?

В модели процесса параллельные работы показаны последовательно. Какой риск для оценки бизнес-решения это создаёт?

Как обосновать порядок приоритизации требований при ограниченном ресурсе, не подменяя анализ влиянием стейкхолдера?

Представьте, что бизнес предлагает отложить выбор решения до получения ещё одного исследования. Как определить, оправдана ли его стоимость?

На воркшопе участники описывают процесс от действий отдела до его результата. По какому критерию аналитик должен провести границы модели?

В модели процесса не показан редкий, но обязательный маршрут. Как это искажает оценку бизнес-решения?

Объясните механизм, с помощью которого прототип снижает риск неверно понятых требований до начала разработки?

В спецификации правил скидки обнаружена следующая таблица. Какой дефект делает результат для части заказов неоднозначным?

rules:
  - when: {segment: new, amount: '>=10000'}
    discount: 10
  - when: {segment: new, amount: '>=5000'}
    discount: 5
  - when: {segment: new, amount: '>=10000'}
    discount: 15

После внедрения процесса среднее время обработки заявок не изменилось. Как аналитику проверить, не скрывает ли этот показатель разнонаправленные изменения по сегментам?

При моделировании входа в систему аналитик зафиксировал обязательную проверку личности для каждого успешного входа. Какую семантическую ошибку содержит модель?

@startuml
(Проверка личности) ..> (Вход в систему) : <<extend>>
@enduml

В двух отделах одно и то же понятие имеет разные названия. Как бизнес-аналитику устранить риск расхождения требований?