Перейти к основному содержимому

200 вопросов по системному анализу

В РАЗРАБОТКЕЛАБОРАТОРИЯНЕ ОБЯЗАТЕЛЬНО

200 вопросов по системному анализу​

Основы профессии системного аналитика​

Вопрос​

Что такое системный аналитик?

Ответ​

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

Вопрос​

Какова основная цель работы системного аналитика?

Ответ​

Основная цель — обеспечить соответствие разрабатываемой системы реальным потребностям заинтересованных сторон (stakeholders), минимизировать риски недопонимания и гарантировать, что результат проекта решает поставленные бизнес-задачи.

Вопрос​

В чём отличие системного аналитика от бизнес-аналитика?

Ответ​

Бизнес-аналитик фокусируется на оптимизации бизнес-процессов и стратегических целях компании, тогда как системный аналитик занимается технической реализацией требований: описывает функциональность, взаимодействие компонентов, интеграции и архитектурные решения.

Вопрос​

Какие ключевые навыки необходимы системному аналитику?

Ответ​

Ключевые навыки включают: сбор и анализ требований, владение нотациями моделирования (UML, BPMN), понимание жизненного цикла ПО, базовые знания архитектуры систем, SQL, принципов проектирования API, а также soft skills — коммуникация, эмпатия, способность задавать уточняющие вопросы.

Вопрос​

На каких этапах жизненного цикла проекта участвует системный аналитик?

Ответ​

Системный аналитик активно участвует на этапах инициации, анализа требований, проектирования и частично — тестирования. В Agile он может быть вовлечён на всех итерациях для уточнения задач и поддержки команды.

Сбор и классификация требований​

Вопрос​

Что такое требования?

Ответ​

Требования — это формализованные описания того, что система должна делать, как она должна себя вести, какие ограничения на неё накладываются и какие качества она должна обладать.

Вопрос​

Какие виды требований вы знаете?

Ответ​

Основные виды требований:

  • Функциональные — описывают действия системы (например, «пользователь может войти через email»).
  • Нефункциональные — описывают качество системы (производительность, безопасность, масштабируемость).
  • Бизнес-требования — цели организации.
  • Технические требования — ограничения на архитектуру, технологии, инфраструктуру.

Вопрос​

Что такое SMART-требования?

Ответ​

SMART — это критерии формулировки требований: Specific (конкретное), Measurable (измеримое), Achievable (достижимое), Relevant (релевантное), Time-bound (ограниченное по времени). Такие требования снижают риск двусмысленности.

Вопрос​

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

Ответ​

Методы включают интервью, анкетирование, наблюдение (shadowing), анализ существующих документов, проведение воркшопов, создание прототипов и анализ конкурентов. Выбор метода зависит от контекста проекта и доступности стейкхолдеров.

Вопрос​

Что такое заинтересованные стороны (stakeholders)?

Ответ​

Заинтересованные стороны — это все лица или группы, чьи интересы затрагиваются проектом: заказчики, пользователи, разработчики, тестировщики, юристы, операционные команды и другие.

Документирование требований​

Вопрос​

Какие форматы документирования требований вы применяете?

Ответ​

Форматы варьируются от классических спецификаций (SRS — Software Requirements Specification) до гибких артефактов: user stories, use cases, acceptance criteria, BPMN-диаграмм, UML-диаграмм, таблиц решений и экранных макетов.

Вопрос​

Что такое User Story?

Ответ​

User Story — это краткое описание функциональности с точки зрения пользователя, оформленное по шаблону: «Как [роль], я хочу [цель], чтобы [выгода]». Пример: «Как покупатель, я хочу фильтровать товары по цене, чтобы быстрее найти подходящий вариант».

Вопрос​

Что входит в Acceptance Criteria для User Story?

Ответ​

Acceptance Criteria — это список условий, при выполнении которых задача считается завершённой. Они должны быть конкретными, проверяемыми и однозначными. Пример: «Фильтр отображает только товары в указанном диапазоне цен».

Вопрос​

Что такое Use Case?

Ответ​

Use Case — это описание последовательности действий между актёром (пользователем или системой) и системой для достижения конкретной цели. Он включает основной сценарий, альтернативные и исключительные потоки.

Вопрос​

Когда предпочтительнее использовать Use Case вместо User Story?

Ответ​

Use Case предпочтителен при сложных сценариях с множеством ветвлений, условиями и взаимодействиями между системами. User Story лучше подходит для Agile-проектов с простыми, атомарными задачами.

Моделирование процессов и систем​

Вопрос​

Что такое BPMN?

Ответ​

BPMN (Business Process Model and Notation) — это стандартизированная графическая нотация для моделирования бизнес-процессов. Она включает элементы: события, задачи, шлюзы, потоки, пулы и дорожки.

Вопрос​

Какие основные элементы BPMN вы знаете?

Ответ​

Основные элементы:

  • События (начало, промежуточные, конец)
  • Задачи (обычные, сервисные, пользовательские)
  • Шлюзы (параллельные, исключающие, инклusive)
  • Последовательные и сообщениями потоки
  • Пулы и дорожки для разделения ролей

Вопрос​

Что такое UML?

Ответ​

UML (Unified Modeling Language) — это язык визуального моделирования объектно-ориентированных систем. Он используется для описания структуры (классы, компоненты) и поведения (диаграммы последовательности, деятельности).

Вопрос​

Какие диаграммы UML чаще всего использует системный аналитик?

Ответ​

Наиболее востребованы:

  • Диаграммы прецедентов (use case diagrams)
  • Диаграммы последовательности (sequence diagrams)
  • Диаграммы классов (class diagrams)
  • Диаграммы деятельности (activity diagrams)

Вопрос​

В чём разница между диаграммой деятельности UML и BPMN?

Ответ​

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

Анализ текущего и целевого состояния​

Вопрос​

Что означают термины «As Is» и «To Be»?

Ответ​

«As Is» — это описание текущего состояния системы или процесса. «To Be» — это целевое состояние после внедрения изменений. Анализ «As Is → To Be» помогает выявить пробелы и определить объём работ.

Вопрос​

Как вы проводите анализ «As Is»?

Ответ​

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

Вопрос​

Зачем нужен Gap Analysis?

Ответ​

Gap Analysis (анализ разрывов) выявляет расхождения между текущим и желаемым состоянием. Он помогает определить, какие функции нужно добавить, изменить или удалить, а также оценить риски и стоимость изменений.

Вопрос​

Как вы представляете результаты анализа «To Be»?

Ответ​

Результаты представляются в виде моделей (BPMN/UML), спецификаций требований, прототипов интерфейсов, архитектурных схем и дорожных карт внедрения. Цель — дать всем участникам единое понимание будущей системы.

Вопрос​

Может ли «To Be» включать несколько этапов?

Ответ​

Да. Часто «To Be» разбивается на этапы: MVP (минимально жизнеспособный продукт), затем итерации с расширением функционала. Это позволяет быстрее получить ценность и снизить риски.

Управление бэклогом и приоритезация​

Вопрос​

Что такое Product Backlog?

Ответ​

Product Backlog — это упорядоченный список всех известных требований к продукту, выраженных в виде задач, историй или эпиков. Он живой документ, постоянно уточняемый и переприоритезируемый.

Вопрос​

Как вы приоритезируете задачи в бэклоге?

Ответ​

Используются методы: MoSCoW (Must, Should, Could, Won’t), Value vs Effort, WSJF (Weighted Shortest Job First), RICE (Reach, Impact, Confidence, Effort). Приоритеты согласовываются с Product Owner и стейкхолдерами.

Вопрос​

Что такое MVP?

Ответ​

MVP (Minimum Viable Product) — это версия продукта с минимальным набором функций, достаточным для проверки гипотезы ценности у реальных пользователей. Цель — получить обратную связь с минимальными затратами.

Вопрос​

Как определить состав MVP?

Ответ​

Состав MVP определяется через выявление ключевых пользовательских сценариев, без которых продукт не решает основную проблему. Все остальное откладывается на последующие итерации.

Вопрос​

Что такое эпик (Epic)?

Ответ​

Эпик — это крупная пользовательская история, которую невозможно реализовать за одну итерацию. Он разбивается на более мелкие задачи или истории для планирования спринтов.

Работа с данными и интеграциями​

Вопрос​

Какие типы интеграций вы знаете?

Ответ​

Основные типы:

  • Синхронные (REST/SOAP API)
  • Асинхронные (очереди: RabbitMQ, Kafka)
  • Пакетные (ETL-процессы)
  • Через файловые обмены (CSV, XML)
  • Через shared database (не рекомендуется)

Вопрос​

Что такое ETL?

Ответ​

ETL (Extract, Transform, Load) — это процесс извлечения данных из источников, их преобразования (очистка, агрегация, нормализация) и загрузки в целевую систему, например, хранилище данных.

Вопрос​

Как вы описываете интеграционные интерфейсы?

Ответ​

Описание включает: формат данных (JSON/XML), методы API (GET/POST), endpoint’ы, схемы запросов и ответов, коды ошибок, политики авторизации, частоту вызовов и SLA (время ответа, доступность).

Вопрос​

Что такое OLAP?

Ответ​

OLAP (Online Analytical Processing) — это подход к анализу многомерных данных, используемый в BI-системах. Он позволяет выполнять сложные агрегации, срезы и свёртки по измерениям (время, регион, продукт).

Вопрос​

Как системный аналитик работает с BI-требованиями?

Ответ​

Аналитик собирает метрики и отчёты, которые нужны бизнесу, определяет источники данных, логику расчётов, периодичность обновления и формат представления. Он также участвует в проектировании витрин данных (data marts).

SQL и работа с базами данных​

Вопрос​

Зачем системному аналитику знать SQL?

Ответ​

SQL позволяет самостоятельно проверять данные в источниках, уточнять структуру таблиц, валидировать логику расчётов и писать запросы для прототипирования отчётов или анализа «As Is».

Вопрос​

Какие базовые SQL-операции должен знать аналитик?

Ответ​

Обязательны: SELECT, JOIN (INNER, LEFT), WHERE, GROUP BY, HAVING, ORDER BY, агрегатные функции (COUNT, SUM, AVG). Также полезны подзапросы и оконные функции.

Вопрос​

Приведите пример SQL-запроса для получения активных пользователей за последний месяц.

Ответ​

SELECT user_id, email, last_login
FROM users
WHERE last_login >= CURRENT_DATE - INTERVAL '30 days'
  AND status = 'active';

Вопрос​

Что такое нормализация БД?

Ответ​

Нормализация — это процесс приведения структуры базы данных к форме, минимизирующей дублирование и зависимости. Обычно применяются первая (1NF), вторая (2NF) и третья (3NF) нормальные формы.

Вопрос​

Когда допустима денормализация?

Ответ​

Денормализация применяется в хранилищах данных и OLAP-системах для повышения производительности чтения. Жертвуются требования к целостности ради скорости агрегации.

Взаимодействие и коммуникация​

Вопрос​

Как вы работаете с конфликтующими требованиями от разных стейкхолдеров?

Ответ​

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

Вопрос​

Как вы объясняете технические ограничения нетехническим стейкхолдерам?

Ответ​

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

Вопрос​

Как вы убедитесь, что разработчик правильно понял задачу?

Ответ​

Провожу трёхстороннюю встречу (аналитик–разработчик–тестировщик), использую примеры и acceptance criteria, прошу разработчика переформулировать задачу своими словами.

Вопрос​

Что вы делаете, если требование невозможно реализовать?

Ответ​

Обсуждаю с Product Owner’ом альтернативы: упрощение, замена подхода, откладывание. Документирую ограничение и его причины (технические, временные, бюджетные).

Вопрос​

Как вы поддерживаете актуальность документации?

Ответ​

Храню документацию в системе контроля версий (например, Confluence с историей изменений), связываю её с задачами в трекере, провожу регулярные ревью и обновляю при изменении требований.

Проектирование требований и архитектурное мышление​

Вопрос​

Что такое функциональная декомпозиция?

Ответ​

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

Вопрос​

Как вы оцениваете полноту требований?

Ответ​

Полноту проверяют через покрытие всех пользовательских ролей, сценариев использования, бизнес-правил и исключительных ситуаций. Применяются техники: сквозная трассировка (traceability), перекрёстная проверка с заинтересованными сторонами, сравнение с конкурентами.

Вопрос​

Что такое traceability matrix?

Ответ​

Traceability matrix — это таблица, связывающая требования с источниками (бизнес-целями), тестами, артефактами реализации и документацией. Она обеспечивает прослеживаемость: от идеи до кода и проверки.

Вопрос​

Какие ошибки чаще всего допускают при формулировке требований?

Ответ​

Типичные ошибки:

  • Расплывчатость («система должна быть быстрой»)
  • Противоречивость
  • Избыточность
  • Смешение функциональных и нефункциональных требований
  • Отсутствие измеримых критериев принятия

Вопрос​

Что такое «железобетонное требование»?

Ответ​

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

Моделирование данных и домена​

Вопрос​

Что такое предметная область (domain)?

Ответ​

Предметная область — это совокупность реальных объектов, процессов, правил и отношений, которые система должна отражать или поддерживать. Пример: «банковские переводы», «управление складом».

Вопрос​

Как вы моделируете предметную область?

Ответ​

Моделирование включает:

  • Интервью с экспертами
  • Анализ существующих документов и систем
  • Построение глоссария терминов
  • Создание диаграмм классов или ER-диаграмм
  • Выявление ключевых сущностей, атрибутов и связей

Вопрос​

Что такое ER-диаграмма?

Ответ​

ER-диаграмма (Entity-Relationship Diagram) — это графическое представление структуры данных, показывающее сущности (таблицы), их атрибуты и связи между ними (один-к-одному, один-ко-многим).

Вопрос​

Как вы определяете границы системы?

Ответ​

Границы определяются через:

  • Актёров (кто взаимодействует с системой)
  • Входы и выходы (данные, события)
  • Интеграции с внешними системами
  • Бизнес-процессы, которые система поддерживает

Вопрос​

Что такое контекстная диаграмма?

Ответ​

Контекстная диаграмма — это диаграмма уровня 0 в нотации DFD (Data Flow Diagram), показывающая систему как единый процесс и её взаимодействие с внешними актёрами и системами.

Работа с нефункциональными требованиями​

Вопрос​

Приведите примеры нефункциональных требований.

Ответ​

Примеры:

  • Производительность: «Система обрабатывает 1000 запросов в секунду»
  • Доступность: «99.9% uptime»
  • Безопасность: «Все пароли хранятся в хэшированном виде»
  • Масштабируемость: «Поддержка до 1 млн пользователей»
  • Юзабилити: «Новый пользователь выполняет регистрацию за ≤3 клика»

Вопрос​

Как вы собираете нефункциональные требования?

Ответ​

Используются:

  • Вопросники по категориям (производительность, безопасность и т.д.)
  • Анализ SLA текущих систем
  • Benchmark’и конкурентов
  • Технические ограничения инфраструктуры
  • Юридические и нормативные требования

Вопрос​

Что такое SLO и SLI?

Ответ​

SLI (Service Level Indicator) — метрика качества сервиса (например, время ответа).
SLO (Service Level Objective) — целевое значение этой метрики (например, 95% запросов должны отвечать за <200 мс).

Вопрос​

Как вы проверяете выполнение нефункциональных требований?

Ответ​

Через:

  • Нагрузочное тестирование (JMeter, Gatling)
  • Пентесты (для безопасности)
  • Мониторинг (Prometheus, Grafana)
  • Аудит логов и метрик
  • Ручную проверку юзабилити

Вопрос​

Можно ли игнорировать нефункциональные требования на старте проекта?

Ответ​

Нет. Игнорирование приводит к техническому долгу, невозможности масштабироваться, уязвимостям и плохому пользовательскому опыту. Даже MVP должен удовлетворять базовым нефункциональным критериям.

Интеграции и API​

Вопрос​

Как вы описываете API для разработчиков?

Ответ​

Описание включает:

  • OpenAPI/Swagger-спецификацию
  • Примеры запросов и ответов
  • Коды ошибок
  • Схемы валидации
  • Политики авторизации
  • Ограничения скорости (rate limiting)

Вопрос​

Что такое idempotency в API?

Ответ​

Idempotency — свойство операции, при котором повторный вызов с теми же параметрами не изменяет результат. Например, повторный POST с уникальным idempotency-key не создаёт дубликат.

Вопрос​

Как вы тестируете интеграции?

Ответ​

Тестирование включает:

  • Мокирование внешних сервисов (WireMock, MockServer)
  • Проверку обработки ошибок (таймауты, 5xx)
  • Валидацию форматов и схем
  • Тестирование идемпотентности и порядка сообщений
  • E2E-сценарии с реальными системами в staging-среде

Вопрос​

Что такое contract testing?

Ответ​

Contract testing — это проверка соответствия между потребителем и поставщиком API на основе заранее согласованного контракта (например, в формате Pact). Он гарантирует, что изменения не сломают интеграцию.

Вопрос​

Как вы выбираете протокол интеграции: REST, gRPC, SOAP, Kafka?

Ответ​

Выбор зависит от:

  • Синхронности (REST/gRPC — синхронные, Kafka — асинхронный)
  • Производительности (gRPC быстрее REST)
  • Поддержки типов (gRPC использует Protocol Buffers)
  • Сложности (SOAP — тяжеловесный, REST — простой)
  • Требований к надёжности доставки (Kafka гарантирует delivery)

Работа в Agile и Scrum​

Вопрос​

Какова роль системного аналитика в Scrum-команде?

Ответ​

Аналитик участвует в refinement’е бэклога, пишет и уточняет user stories, работает с Product Owner’ом над приоритетами, поддерживает команду во время спринта при возникновении вопросов по требованиям.

Вопрос​

Что вы делаете на refinement-сессии?

Ответ​

На refinement’е:

  • Разбиваем эпики на задачи
  • Уточняем acceptance criteria
  • Оцениваем сложность (story points)
  • Выявляем зависимости и риски
  • Согласовываем mock-данные и дизайн

Вопрос​

Как вы обеспечиваете готовность задачи к спринту?

Ответ​

Задача считается готовой, если:

  • Есть чёткое описание и цель
  • Прописаны acceptance criteria
  • Утверждён макет/прототип (если нужен)
  • Есть доступ к данным или мокам
  • Все зависимости учтены

Вопрос​

Что такое Definition of Ready (DoR)?

Ответ​

Definition of Ready — это чек-лист условий, которым должна соответствовать задача, чтобы попасть в спринт. Пример: «Есть acceptance criteria», «Дизайн утверждён», «API-контракт согласован».

Вопрос​

Как вы работаете с техническим долгом в требованиях?

Ответ​

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

Продвинутая аналитика и проектирование​

Вопрос​

Что такое CQRS?

Ответ​

CQRS (Command Query Responsibility Segregation) — это паттерн, разделяющий операции записи (commands) и чтения (queries) на разные модели. Это позволяет оптимизировать производительность, масштабируемость и сложность.

Вопрос​

Что такое Event Sourcing?

Ответ​

Event Sourcing — это подход, при котором состояние системы восстанавливается путём воспроизведения последовательности событий (events), а не хранения текущего состояния. Каждое изменение фиксируется как неизменяемое событие.

Вопрос​

Как вы проектируете систему с учётом будущего масштабирования?

Ответ​

Проектирование включает:

  • Разделение на микросервисы по bounded context
  • Использование очередей для асинхронной обработки
  • Кэширование частых запросов
  • Горизонтальное масштабирование stateless-компонентов
  • Чёткое определение SLA для каждого компонента

Вопрос​

Что такое bounded context в DDD?

Ответ​

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

Вопрос​

Как вы применяете Domain-Driven Design в работе аналитика?

Ответ​

Аналитик:

  • Создаёт глоссарий домена вместе с экспертами
  • Выявляет агрегаты и корневые сущности
  • Моделирует процессы через ubiquitous language
  • Помогает команде понять бизнес-логику, а не только UI

Работа с данными и аналитическими системами​

Вопрос​

Что такое витрина данных (data mart)?

Ответ​

Витрина данных — это подмножество хранилища данных (data warehouse), ориентированное на конкретную бизнес-область (например, финансы или маркетинг). Она содержит агрегированные и очищенные данные для отчётности.

Вопрос​

Как вы проектируете ETL-процесс?

Ответ​

Проектирование включает:

  • Идентификацию источников и целей
  • Определение частоты загрузки (real-time, batch)
  • Логику трансформации (очистка, объединение, агрегация)
  • Обработку ошибок и повторных попыток
  • Мониторинг и алертинг

Вопрос​

Что такое медленно меняющиеся измерения (SCD)?

Ответ​

SCD (Slowly Changing Dimensions) — это подход к обработке изменений в справочниках (измерениях) в хранилищах данных. Тип 1 — перезапись, Тип 2 — добавление новой версии с датой актуальности.

Вопрос​

Как вы описываете метрики для BI-системы?

Ответ​

Описание включает:

  • Название и описание метрики
  • Формулу расчёта (например, «Выручка = SUM(цена * количество)»)
  • Гранулярность (по дням, клиентам, регионам)
  • Источники данных
  • Частоту обновления

Вопрос​

Что такое OLTP и чем он отличается от OLAP?

Ответ​

OLTP (Online Transaction Processing) — системы для обработки транзакций в реальном времени (например, CRM).
OLAP (Online Analytical Processing) — системы для анализа исторических данных (например, Power BI).
OLTP оптимизирован под запись, OLAP — под чтение и агрегацию.

Безопасность и соответствие​

Вопрос​

Какие требования безопасности вы всегда включаете?

Ответ​

Обязательные требования:

  • Аутентификация и авторизация
  • Шифрование данных при передаче (TLS) и хранении
  • Валидация и санитизация ввода (защита от XSS, SQLi)
  • Аудит действий пользователей
  • Соответствие GDPR/ФЗ-152 (если применимо)

Вопрос​

Что такое принцип наименьших привилегий?

Ответ​

Принцип наименьших привилегий гласит: пользователь или система должны иметь только те права, которые необходимы для выполнения их задачи. Это снижает риски при компрометации.

Вопрос​

Как вы учитываете безопасность при проектировании API?

Ответ​

Учитываются:

  • Использование OAuth2 / JWT
  • Rate limiting
  • Валидация входных данных
  • Логирование всех запросов
  • Разделение прав доступа по ролям

Вопрос​

Что такое threat modeling?

Ответ​

Threat modeling — это методика выявления потенциальных угроз безопасности на этапе проектирования. Используются техники: STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege).

Вопрос​

Как вы работаете с требованиями соответствия (compliance)?

Ответ​

Требования соответствия (например, PCI DSS, HIPAA) фиксируются как отдельные пункты в спецификации. Проводится анализ gap’ов, внедряются контрольные механизмы, артефакты сохраняются для аудита.

Управление требованиями и изменениями​

Вопрос​

Что такое управление требованиями?

Ответ​

Управление требованиями — это процесс сбора, анализа, документирования, проверки, приоритезации и контроля изменений требований на протяжении всего жизненного цикла проекта.

Вопрос​

Как вы отслеживаете изменения в требованиях?

Ответ​

Изменения фиксируются через систему управления требованиями (например, Jira, Confluence, Polarion). Каждое изменение проходит оценку влияния, согласование со стейкхолдерами и обновление связанных артефактов.

Вопрос​

Что такое baseline требований?

Ответ​

Baseline — это зафиксированная версия набора требований, утверждённая на определённом этапе проекта. Она служит точкой отсчёта для сравнения и управления изменениями.

Вопрос​

Как вы работаете с запросами на изменение (Change Request)?

Ответ​

Каждый Change Request проходит:

  • Описание причины и содержания
  • Анализ влияния на сроки, бюджет и архитектуру
  • Согласование с Product Owner и технической командой
  • Обновление документации и бэклога

Вопрос​

Что такое конфигурационное управление требованиями?

Ответ​

Конфигурационное управление — это практика контроля версий всех артефактов проекта (включая требования), обеспечения их целостности и прослеживаемости между версиями.

Работа с легаси и миграциями​

Вопрос​

Как вы анализируете легаси-систему?

Ответ​

Анализ включает:

  • Изучение исходного кода и документации
  • Интервью с текущими пользователями и поддержкой
  • Анализ логов и метрик использования
  • Построение карты компонентов и зависимостей
  • Выявление «болезненных» мест и технического долга

Вопрос​

Что такое стратегия Strangler Fig?

Ответ​

Strangler Fig — это паттерн миграции, при котором новая система постепенно заменяет функциональность старой, оборачивая её и перехватывая трафик. Это снижает риски полной перезаписи.

Вопрос​

Как вы определяете scope миграции?

Ответ​

Scope определяется через:

  • Бизнес-ценность функций
  • Частоту использования
  • Сложность поддержки
  • Зависимости от других модулей
  • Соответствие современным стандартам безопасности и производительности

Vопрос​

Какие риски миграции вы всегда учитываете?

Ответ​

Ключевые риски:

  • Потеря данных
  • Нарушение интеграций
  • Деградация производительности
  • Отсутствие обратной совместимости
  • Снижение доверия пользователей из-за багов

Вопрос​

Как вы тестируете миграцию?

Ответ​

Тестирование включает:

  • Сравнение результатов старой и новой системы на одинаковых входах
  • Тестирование граничных условий и ошибок
  • Проверку целостности данных после переноса
  • E2E-сценарии с реальными пользователями в staging-среде

Этические и правовые аспекты​

Вопрос​

Какие этические дилеммы могут возникнуть у системного аналитика?

Ответ​

Примеры:

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

Вопрос​

Как вы учитываете GDPR / ФЗ-152 при проектировании?

Ответ​

Требования включают:

  • Минимизацию сбора персональных данных
  • Шифрование при хранении и передаче
  • Возможность удаления данных по запросу
  • Ведение журнала согласий
  • Назначение ответственного за защиту данных

Вопрос​

Что такое privacy by design?

Ответ​

Privacy by design — это принцип проектирования систем с учётом защиты приватности с самого начала, а не как дополнительный слой. Он включает анонимизацию, минимизацию данных и прозрачность.

Вопрос​

Как вы документируете юридические ограничения?

Ответ​

Юридические ограничения фиксируются как отдельные нефункциональные требования с указанием:

  • Нормативного акта
  • Обязательности (must/have to)
  • Метода проверки соответствия
  • Ответственного за аудит

Вопрос​

Может ли аналитик отказаться от реализации требования по этическим причинам?

Ответ​

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

Продвинутые методы моделирования​

Вопрос​

Что такое диаграмма состояний (State Machine Diagram)?

Ответ​

Диаграмма состояний показывает возможные состояния объекта и переходы между ними в ответ на события. Она полезна для моделирования жизненного цикла заказа, сессии пользователя, устройства IoT.

Вопрос​

Когда вы используете диаграмму компонентов?

Ответ​

Диаграмма компонентов применяется при проектировании архитектуры, чтобы показать:

  • Модули системы
  • Их зависимости
  • Интерфейсы взаимодействия
  • Границы развёртывания

Вопрос​

Что такое доменная модель (Domain Model)?

Ответ​

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

Вопрос​

Как вы создаёте глоссарий предметной области?

Ответ​

Глоссарий создаётся совместно с бизнес-экспертами:

  • Фиксируются термины и определения
  • Указываются синонимы и контексты
  • Разрешаются противоречия в трактовках
  • Обновляется при появлении новых понятий

Вопрос​

Что такое Event Storming?

Ответ​

Event Storming — это воркшоп-метод моделирования бизнес-процессов через выявление событий (events), команд, агрегатов и политик. Он помогает быстро понять сложную доменную область и выявить границы микросервисов.

Интеграция с DevOps и тестированием​

Вопрос​

Как системный аналитик участвует в CI/CD?

Ответ​

Аналитик:

  • Пишет acceptance criteria, пригодные для автоматизации
  • Участвует в написании BDD-сценариев (Gherkin)
  • Проверяет, что автоматические тесты покрывают бизнес-требования
  • Анализирует падения тестов, связанные с недопониманием требований

Вопрос​

Что такое living documentation?

Ответ​

Living documentation — это документация, которая автоматически обновляется при изменении кода или тестов. Примеры: Swagger/OpenAPI для API, Allure Reports для тестов, автоматически генерируемые диаграммы.

Вопрос​

Как вы обеспечиваете traceability до тестов?

Ответ​

Каждое требование получает уникальный ID (например, REQ-123). Этот ID указывается в:

  • User story
  • Acceptance criteria
  • Тест-кейсах
  • Отчётах о покрытии Это позволяет отследить, какие тесты проверяют каждое требование.

Вопрос​

Что такое тестовый оракул?

Ответ​

Тестовый оракул — это механизм или правило, позволяющее определить, является ли результат работы системы корректным. Для аналитика это часто формула расчёта, бизнес-правило или эталонное значение.

Вопрос​

Как вы работаете с тестировщиками?

Ответ​

Совместная работа включает:

  • Совместный refinement задач
  • Уточнение граничных условий и негативных сценариев
  • Проверку тест-кейсов на соответствие требованиям
  • Анализ дефектов на предмет недостаточной детализации требований

Архитектурные паттерны и решения​

Вопрос​

Что такое микросервисная архитектура?

Ответ​

Микросервисная архитектура — это подход, при котором система состоит из маленьких, слабосвязанных сервисов, каждый из которых:

  • Отвечает за одну бизнес-возможность
  • Имеет собственную базу данных
  • Может развёртываться независимо
  • Общается через чётко определённые API

Вопрос​

Как вы определяете границы микросервиса?

Ответ​

Границы определяются через:

  • Bounded Context (DDD)
  • Высокую связанность внутри, низкую — между
  • Единый жизненный цикл данных
  • Автономность команды, поддерживающей сервис

Вопрос​

Что такое шина данных (Data Bus)?

Ответ​

Шина данных — это архитектурный паттерн, при котором компоненты обмениваются сообщениями через централизованный канал (например, Kafka). Это обеспечивает loose coupling и масштабируемость.

Вопрос​

Как вы выбираете между REST и gRPC?

Ответ​

Выбор зависит от:

  • Языковой экосистемы (gRPC лучше для strongly-typed языков)
  • Требований к производительности (gRPC быстрее за счёт бинарного формата)
  • Необходимости поддержки браузеров (REST + JSON проще)
  • Сложности контракта (gRPC использует Protocol Buffers)

Вопрос​

Что такое API Gateway?

Ответ​

API Gateway — это единая точка входа для клиентов, которая:

  • Маршрутизирует запросы к микросервисам
  • Обрабатывает аутентификацию и rate limiting
  • Агрегирует данные из нескольких сервисов
  • Преобразует протоколы (например, REST → gRPC)

Работа с данными и аналитикой​

Вопрос​

Что такое data lineage?

Ответ​

Data lineage — это отслеживание происхождения данных, их преобразований и перемещений по системам. Это критично для аудита, отладки и обеспечения качества данных.

Вопрос​

Как вы проектируете витрину данных для аналитиков?

Ответ​

Проектирование включает:

  • Выявление ключевых метрик и измерений
  • Нормализацию источников
  • Создание звёздчатой или снежинчатой схемы
  • Оптимизацию под частые запросы (агрегаты, индексы)

Вопрос​

Что такое slowly changing dimension Type 2?

Ответ​

SCD Type 2 сохраняет историю изменений, добавляя новую запись с новым surrogate key и полями valid_from / valid_to. Это позволяет анализировать данные в историческом контексте.

Вопрос​

Как вы обеспечиваете качество данных в ETL?

Ответ​

Методы включают:

  • Валидацию на этапе извлечения (nulls, форматы, диапазоны)
  • Логирование ошибок и частичных загрузок
  • Подсчёт метрик качества (полнота, точность, согласованность)
  • Автоматические алерты при отклонениях

Вопрос​

Что такое data contract?

Ответ​

Data contract — это соглашение между продюсером и потребителем данных о структуре, формате, семантике и SLA. Он предотвращает «поломку» downstream-систем при изменении источника.

Безопасность и надёжность​

Вопрос​

Как вы проектируете систему с учётом отказоустойчивости?

Ответ​

Подходы:

  • Репликация и failover
  • Circuit breaker для внешних вызовов
  • Retry с экспоненциальной задержкой
  • Graceful degradation при частичных сбоях
  • Chaos engineering для проверки устойчивости

Вопрос​

Что такое defence in depth?

Ответ​

Defence in depth — это стратегия многоуровневой защиты, при которой безопасность обеспечивается на нескольких слоях: сетевом, прикладном, уровне данных и физическом.

Вопрос​

Как вы описываете требования к аудиту?

Ответ​

Требования к аудиту включают:

  • Журналирование всех критических операций
  • Хранение логов не менее X дней
  • Защита от модификации (write-once storage)
  • Возможность восстановления последовательности действий

Вопрос​

Что такое zero trust architecture?

Ответ​

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

Вопрос​

Как вы учитываете безопасность при проектировании интеграций?

Ответ​

Учитываются:

  • Шифрование канала (TLS)
  • Аутентификация по сертификатам или OAuth2
  • Ограничение IP-адресов источников
  • Валидация входящих данных
  • Минимальные права доступа

Международные стандарты и методологии​

Вопрос​

Какие международные стандарты применяются к требованиям?

Ответ​

Основные стандарты:

  • ISO/IEC/IEEE 29148 — руководство по формулировке требований
  • BABOK (Business Analysis Body of Knowledge) — свод практик бизнес- и системного анализа
  • PMBOK — управление проектами, включая сбор требований
  • IREB CPRE — сертификация по инженерии требований

Вопрос​

Что рекомендует ISO/IEC/IEEE 29148 по структуре требования?

Ответ​

Стандарт рекомендует, чтобы каждое требование было:

  • Уникально идентифицируемо
  • Чётко сформулировано без двусмысленностей
  • Проверяемо
  • Согласовано со стейкхолдерами
  • Приоритезировано
  • Прослеживаемо до источника

Вопрос​

Как вы применяете BABOK в работе?

Ответ​

BABOK используется как справочник для:

  • Выбора техник сбора требований
  • Определения типов артефактов (user story, use case)
  • Оценки компетенций аналитика
  • Планирования коммуникаций со стейкхолдерами

Вопрос​

Что такое Requirements Engineering?

Ответ​

Requirements Engineering — это дисциплина, охватывающая весь цикл работы с требованиями: от выявления и анализа до верификации, валидации и управления изменениями.

Вопрос​

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

Ответ​

Оценка проводится по моделям типа CMMI или ISO/IEC 33000, проверяя наличие:

  • Стандартизированных шаблонов
  • Процедур согласования
  • Инструментов управления
  • Метрик качества требований
  • Обучения сотрудников

Работа с распределёнными и кросс-функциональными командами​

Вопрос​

Как вы обеспечиваете понимание требований в распределённой команде?

Ответ​

Методы:

  • Единая система документации (Confluence, Notion)
  • Видеозаписи refinement’ов
  • Глоссарий общих терминов
  • Асинхронные уточнения через комментарии к задачам
  • Регулярные демо и walkthrough’и

Вопрос​

Как вы работаете с time zone differences?

Ответ​

Подходы:

  • Фиксация ключевых решений в письменном виде
  • Использование перекрывающихся «окон связи»
  • Запись встреч и сессий
  • Чёткие SLA на ответы по требованиям (например, 24 часа)

Вопрос​

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

Ответ​

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

Вопрос​

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

Ответ​

Координация включает:

  • Разделение по доменным зонам ответственности
  • Единые шаблоны и правила оформления
  • Регулярные peer review требований
  • Центральный глоссарий и реестр решений

Вопрос​

Как вы предотвращаете дублирование требований?

Ответ​

Используются:

  • Централизованный бэклог
  • Поиск по ключевым словам перед созданием новой задачи
  • Traceability matrix
  • Автоматические проверки уникальности ID требований

Soft Skills и коммуникация​

Вопрос​

Как вы задаёте уточняющие вопросы?

Ответ​

Использую технику 5 Why, открытые вопросы («Что именно вы имеете в виду под “быстро”?»), переформулирование («Вы хотите сказать, что…?») и примеры («Например, если пользователь сделает X, система должна…?»).

Вопрос​

Как вы работаете с неохотным стейкхолдером?

Ответ​

Подхожу через ценность: объясняю, как его участие снизит риски и сэкономит время. Предлагаю короткие форматы (15-минутный звонок, анкета). Демонстрирую предварительные результаты для вовлечения.

Вопрос​

Как вы управляете ожиданиями заказчика?

Ответ​

Регулярно:

  • Демонстрирую прогресс (демо, прототипы)
  • Формулирую ограничения честно и заранее
  • Предоставляю альтернативы при невозможности реализации
  • Документирую договорённости

Вопрос​

Как вы реагируете на изменение приоритетов в середине спринта?

Ответ​

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

Вопрос​

Как вы развиваете эмпатию к пользователям?

Ответ​

Практикую:

  • Наблюдение за реальными пользователями
  • Анализ отзывов и обращений в поддержку
  • Создание персонажей (personas)
  • Мысленное прохождение сценариев от лица разных ролей

Карьерное развитие и профессиональный рост​

Вопрос​

Какие сертификации полезны системному аналитику?

Ответ​

Наиболее востребованы:

  • IREB CPRE (Foundation и Advanced Levels)
  • CBAP / CCBA от IIBA
  • Scrum.org PSM / PSPO
  • TOGAF (для аналитиков с фокусом на архитектуру)
  • AWS/Azure Solutions Architect (для облачных проектов)

Вопрос​

Как вы оцениваете свою эффективность как аналитика?

Ответ​

По метрикам:

  • Количество возвратов задач из-за недопонимания
  • Время от идеи до реализации
  • Удовлетворённость стейкхолдеров
  • Покрытие требований тестами
  • Частота изменений после утверждения

Вопрос​

Куда может развиваться системный аналитик?

Ответ​

Варианты развития:

  • Product Owner / Product Manager
  • Архитектор решений
  • Технический директор (CTO)
  • Консультант по цифровой трансформации
  • Специалист по данным (Data Analyst / Data Product Owner)

Вопрос​

Как вы остаётесь в курсе новых практик?

Ответ​

Слежу за:

  • Профильными блогами и подкастами
  • Конференциями (например, BA Days, Agile Russia)
  • Открытыми репозиториями шаблонов и чек-листов
  • Обсуждениями в профессиональных сообществах

Вопрос​

Что отличает начинающего аналитика от опытного?

Ответ​

Опытный аналитик:

  • Задаёт меньше вопросов, но более точных
  • Предвидит последствия требований
  • Говорит на языке бизнеса и техники одновременно
  • Управляет неопределённостью
  • Фокусируется на ценности, а не на объёме

Стратегическое мышление и бизнес-влияние​

Вопрос​

Как вы связываете требования с бизнес-метриками?

Ответ​

Каждая задача должна иметь гипотезу влияния:
«Если мы реализуем X, то метрика Y изменится на Z%».
Пример: «Если добавим фильтр по цене, конверсия возрастёт на 5%».

Вопрос​

Что такое value stream mapping?

Ответ​

Value Stream Mapping — это визуализация всех шагов, которые проходит запрос от идеи до доставки ценности пользователю. Она помогает выявить потери и оптимизировать поток создания ценности.

Вопрос​

Как вы оцениваете ROI от внедрения функции?

Ответ​

ROI = (Ожидаемая выгода – Затраты) / Затраты.
Выгода может быть в виде роста выручки, снижения издержек, удержания клиентов. Затраты — трудозатраты, лицензии, инфраструктура.

Вопрос​

Как вы работаете с гипотезами в Agile?

Ответ​

Формулирую гипотезу: «Мы считаем, что [решение] для [пользователя] приведёт к [эффекту]». После релиза проверяю её через A/B-тест, метрики или опросы.

Вопрос​

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

Ответ​

Провожу discovery-сессию: исследую текущие проблемы, метрики, конкурентов. Формулирую возможные цели и предлагаю выбрать приоритетную. Работаю итеративно — от MVP к уточнению.

Работа с документацией и знаниями​

Вопрос​

Как вы организуете хранение знаний?

Ответ​

Использую иерархическую структуру:

  • Продукт → Доменная область → Компонент → Версия Все документы имеют:
  • Дату актуальности
  • Автора
  • Ссылки на связанные задачи
  • Версионирование

Вопрос​

Что такое single source of truth?

Ответ​

Single source of truth — это принцип, согласно которому каждая единица информации хранится в одном месте и используется всеми системами. Это исключает противоречия и упрощает поддержку.

Вопрос​

Как вы мигрируете старую документацию?

Ответ​

Этапы:

  • Инвентаризация существующих документов
  • Оценка актуальности (устаревшие — помечаются)
  • Перенос в единый формат с сохранением истории
  • Связывание с новыми артефактами через ссылки

Вопрос​

Как вы обучаете новых аналитиков в команде?

Ответ​

Создаю:

  • Онбординг-пакет (глоссарий, шаблоны, процессы)
  • Парное проведение интервью и refinement’ов
  • Базу типовых решений и ошибок
  • Регулярные ретроспективы по качеству требований

Вопрос​

Как вы измеряете качество документации?

Ответ​

Метрики:

  • Время на поиск информации
  • Частота обращений за уточнением
  • Количество ошибок из-за недопонимания
  • Удовлетворённость команды (опросы)

Завершение проекта и пост-релизный анализ​

Вопрос​

Что вы делаете после релиза?

Ответ​

Провожу:

  • Пост-мортиум (анализ успехов и проблем)
  • Сбор обратной связи от пользователей
  • Проверку гипотез
  • Обновление документации до актуального состояния
  • Передачу знаний в поддержку

Вопрос​

Как вы оцениваете успешность реализации требования?

Ответ​

Успешность измеряется:

  • Выполнением acceptance criteria
  • Достижением бизнес-метрик
  • Отсутствием критических багов
  • Положительной обратной связью от пользователей

Вопрос​

Что такое lessons learned и зачем он нужен?

Ответ​

Lessons learned — это документ, фиксирующий:

  • Что сработало хорошо
  • Что пошло не так
  • Рекомендации на будущее
    Он помогает избежать повторения ошибок в следующих проектах.

Вопрос​

Как вы закрываете требования после релиза?

Ответ​

Требование считается закрытым, если:

  • Пройдены все тесты
  • Подтверждено Product Owner’ом
  • Зафиксировано в системе как «реализовано»
  • Обновлена соответствующая документация

Вопрос​

Что вы оставляете после завершения работы над проектом?

Ответ​

Оставляю:

  • Актуальную документацию
  • Реестр принятых решений
  • Контакты ключевых экспертов
  • Инструкции по поддержке и расширению
  • Отчёты о метриках и гипотезах
Освоение главы0%