Три дисциплины часто смешивают в одном слое «требований», из-за чего ломается handoff между бизнесом и IT. Здесь — карта местности: чем отличаются бизнес-анализ (BA), системный анализ (SA) и управление требованиями (Requirements Management, RM). Статья не про определение термина «требование» — классификация и спецификация артефактов живут в ветке 02.03.*; третий столп здесь — сквозной процесс на всём жизненном цикле: от выявления до изменений и трассировки. Детали практик RM — в блоке 02.05.01 Управление зависимостями между требованиями и соседних заметках раздела «Совместное управление требованиями (BA + PM)».

1. Суть темы

Бизнес-анализ, системный анализ и управление требованиями — разные, но связанные дисциплины. BA отвечает за ценность и процессы организации (решение не обязательно IT). SA — за поведение, данные и интерфейсы конкретной информационной системы. RM охватывает обе зоны: задаёт правила работы с требованиями на всех уровнях «почему → что → как» и действует на всех фазах жизненного цикла ПО — от анализа до сопровождения (→ 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC)).

На проекте участвуют не только BA и SA: менеджер проекта (PM) ведёт сроки, бюджет и объём, а RM связывает треугольник BA–SA–PM — согласованный baseline требований, приоритеты и контроль изменений без потери трассировки к бизнес-целям.

flowchart LR
    subgraph BA [Бизнес-анализ]
        direction LR
        B1[Проблемы и возможности]
        B2[Бизнес-цели]
        B3[Потребности стейкхолдеров]
    end

    subgraph SA [Системный анализ]
        direction LR
        S1[Функциональные требования]
        S2[Нефункциональные требования]
        S3[Модели данных и поведения]
    end

    subgraph REQ [Управление требованиями]
        direction LR
        R1[Выявление]
        R2[Документирование]
        R3[Приоритизация]
        R4[Трассировка]
        R5[Изменения]
    end

    BA -- Бизнес-требования --> SA
    BA -- Все типы требований --> REQ
    SA -- ФТ и НФТ --> REQ
    REQ -.->|Сквозные практики| BA
    REQ -.->|Сквозные практики| SA

RM — не отдельная «служба над BA и SA», а набор практик внутри их работы и совместно с PM. PM на схеме не выделен отдельным блоком: baseline, приоритеты и scope согласуются через RM совместно с PM.

Иерархия требований (пирамида Why / What / How):

УровеньТип требованийКто формируетПример
Почему? (Why)Бизнес-требования, цели, ограниченияBA«Сократить время согласования счетов с 3 дней до 4 часов»
Что? (What)Функциональные и нефункциональные требованияSA«Система должна автоматически маршрутизировать счёт на утверждение ответственному лицу»
Как? (How)Технические требования, дизайн, архитектураSA (solution design), архитектор, разработчики«Контракт интеграции с учётной системой, асинхронные уведомления заинтересованным ролям» (→ 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf))

Выявление (elicitation) идёт на всех уровнях пирамиды; владелец зависит от глубины: BA — потребности и цели, SA — детали системы, на каждом этапе — в рамках RM. Все уровни живут в едином процессе RM, который обеспечивает целостность, согласованность и отслеживаемость.

2. Ключевые понятия

Бизнес-анализ (Business Analysis)

Выявление потребностей (elicitation) на бизнес-уровне — зона BA в рамках RM: BA проводит интервью и воркшопы (→ 02.02.01 Интервьюирование и анкетирование), SA — уточняет и детализирует уже в контексте системы.

Системный анализ (Systems Analysis)

SA часто готовит solution / system design до передачи архитектору. Граница «требование» vs «архитектурное решение»: SA фиксирует поведение и ограничения системы; выбор платформы, паттернов и компромиссов — в ADR (→ 10.01.13 Шаблон архитектурного решения (ADR), 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая)). Enterprise- и platform-архитектура — зона architect. Часть НФТ исходит из бизнес-ограничений — SLA, регуляторика (→ 08.02 Нефункциональные требования (НФТ) — классификация и стандарты).

Управление требованиями (Requirements Management)

В части организаций границу BA/SA закрывает роль functional analyst (FA) — см. 00.01 Кто такой аналитик (роли BA, SA, FA).

Таблица сравнения

КритерийБизнес-анализ (BA)Системный анализ (SA)Управление требованиями (RM)
Основной вопросЗачем и для кого?Что именно должна делать система и как она устроена логически?Как сохранить целостность и управляемость требований при изменениях?
Выходные артефактыBRD, Business Case, BPMN верхнего уровняSRS, Use Cases, UML/ER, API-спецификацииМатрица трассировки, baseline, журнал изменений, отчёты о покрытии трассировки
Ключевые активностиВыявление потребностей, оценка альтернатив, приоритизация по ценностиДетальная спецификация, моделирование, согласование с dev/QAGovernance, версионирование, impact analysis, ревью, согласование с PM
Основной стандартBABOK GuideSWEBOK, SEBoK (контекстно), ISO 29148ISO/IEC/IEEE 29148

PM в таблице не выделен отдельной колонкой: он владеет сроками, бюджетом и объёмом, а RM обеспечивает согласованный baseline и трассировку изменений к бизнес-целям совместно с PM.

3. Как применяется в работе аналитика

Handoff BA → SA: передавайте согласованные бизнес-цели, границы решения и KPI (→ 02.01.02 Цели, KPI и критерии успеха (SMART, GQM), 02.01.04 Определение границ решения (Scope Modelling)), а не черновые формулировки «система должна…». Критерий готовности к системной проработке — зафиксированный scope и измеримый бизнес-исход (→ 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)). Классификация БТ / ФТ / НФТ — в 02.03.01 Классификация требований (БТ, ФТ, НФТ).

Процесс vs система: BPMN TO-BE без IT — ещё зона BA; как только решение включает автоматизацию, handoff на SA. Scope BA — «что меняется в бизнесе»; SA — «как это реализует система».

В Agile роли BA, SA и Product Owner часто сходятся в одном человеке; RM сохраняется через backlog, baseline спринта и критерии приёмки (→ 00.01 Кто такой аналитик (роли BA, SA, FA), 05.02 Scrum и Kanban (аналитик в Agile)).

Пример из практики (IT-автоматизация)

Замечание: BA не сводится к IT; ниже — типовой кейс автоматизации, когда выбранное решение — информационная система.

Заказчик (владелец бизнеса): «Хочу ускорить процесс согласования счетов».

  1. Бизнес-аналитик (BA):

    • Выясняет: текущий процесс занимает 3 дня; KPI — сократить до 4 часов (→ 02.01.02 Цели, KPI и критерии успеха (SMART, GQM)).
    • Строит BPMN AS-IS / TO-BE; сравнивает альтернативы (перераспределение ролей без IT vs автоматизация).
    • Фиксирует бизнес-требование: «Время полного цикла согласования счёта — не более 4 часов с момента подачи заявки».
    • Обосновывает выбранное решение: автоматизировать маршрутизацию по правилам (сумма, подразделение) — в Business Case / TO-BE процессе.

  2. Системный аналитик (SA):

  3. Управление требованиями (совместно BA, SA, PM):

4. Типовые ошибки и ограничения

  • BA формулирует «система должна…» — это уже уровень What; на Why остаются измеримые бизнес-исходы и границы процесса.
  • TO-BE с IT в зоне BA — автоматизация процесса без системной проработки смешивает What и How; IT-решение передаёт SA после scope.
  • RM как «настройка Jira» — tooling без baseline, ревью и impact analysis не заменяет governance.
  • RM «над» BA и SA — процесс внутри команд, а не внешний контролёр; PM участвует в scope и приоритетах.
  • Линейная цепочка без PM — срывы сроков и scope creep ломают требования так же, как плохая спецификация.
  • SA = архитектор — SA детализирует solution design; platform/enterprise ADR — у architect (→ 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая)).
  • Путаница «требования» и RM — артефакты и их качество (02.03.*, 02.04.*) vs сквозной процесс (02.05.*, эта статья).

Связи с другими разделами базы

Источники и дополнительные материалы

Стандарты и своды знаний:

Книги и практические руководства:

  • Вигерс, К. и Битти, Дж. (2020). Разработка требований к программному обеспечению. 3-е изд. СПб: BHV. (Главы 1–5)

Видео: