Три опорных документа задают общий язык для аналитика: что делать (BABOK), как мыслить системой (SEBoK) и как формулировать и управлять требованиями (ISO/IEC/IEEE 29148). Важно различать их тип: BABOK — профессиональное руководство IIBA, SEBoK — открытый свод знаний (Body of Knowledge), ISO 29148 — нормативный международный стандарт для контрактов и аудита. Руководства не диктуют пошаговый процесс «как на вашем проекте», а стандарт фиксирует обязательные критерии качества и процессов — особенно в регулируемой среде (regulated environment). Эта заметка — карта местности; детали практик — в ветках 02.*, 03.* и 08.*.

Версии документов указаны на дату обновления статьи (август 2026). Актуальность проверяйте на iiba.org, sebokwiki.org и iso.org / standards.ieee.org.

1. Суть темы

ХарактеристикаBABOKSEBoKISO/IEC/IEEE 29148
Тип документаПрофессиональное руководство (guide)Свод знаний / wiki (BoK)Международный стандарт ISO/IEEE
Полное названиеA Guide to the Business Analysis Body of KnowledgeGuide to the Systems Engineering Body of KnowledgeSystems and software engineering — Life cycle processes — Requirements engineering
РазработчикInternational Institute of Business Analysis (IIBA)BKCASE (Stevens Institute of Technology, Naval Postgraduate School)ISO/IEC JTC 1/SC 7, совместно с IEEE
Актуальная версияv3.0 (2015); v4 в разработке — содержание v3 остаётся базой сертификации IIBA, пока v4 не опубликованv2.14 (живая wiki, обновляется сообществом)2018 (подтверждена в 2023); новая редакция — CD, ожидается ~2026
Основной фокусДеятельность бизнес-аналитика: задачи, техники, компетенцииСистемная инженерия: жизненный цикл сложных системИнженерия требований (requirements engineering): процессы, артефакты, критерии качества
Ценность для аналитикаОбщий профессиональный язык BA; основа сертификаций ECBA / CCBA / CBAPСистемный контекст, границы, архитектура«Золотой стандарт» формулировок и RE в контрактах; сменил устаревший IEEE 830

IEEE 830 → ISO 29148. Стандарт IEEE 830 описывал структуру SRS; ISO/IEC/IEEE 29148 (2018) объединил и расширил практики RE, гармонизировав их с ISO/IEC/IEEE 15288 (жизненный цикл систем) и ISO/IEC/IEEE 12207 (жизненный цикл ПО). В госконтрактах и тендерах ссылка на 29148 заменяет отсылки к 830.

Сертификация vs стандарт. BABOK — не «закон», а база знаний IIBA; экзамены ECBA, CCBA и CBAP проверяют владение этим сводом, но не заменяют организационные или контрактные требования. ISO 29148, напротив, может быть прямо включён в ТЗ и SLA.

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

BABOK Guide v3

Бизнес-анализ (business analysis) — практика изменений в организации через выявление потребностей (needs) и рекомендацию решений (solutions), приносящих ценность (value) заинтересованным сторонам (stakeholders).

BACCM (Business Analysis Core Concept Model) — шесть связанных понятий: изменение, потребность, решение, заинтересованная сторона, ценность, контекст. Модель задаёт «грамматику» любой аналитической инициативы; разбор техник выявления и стратегического анализа — в ветке 02.*.

Шесть областей знаний (Knowledge Areas): планирование и мониторинг BA; выявление и сотрудничество (elicitation and collaboration); управление жизненным циклом требований (Requirements Life Cycle Management, RLCM); стратегический анализ; анализ требований и определение дизайна (Requirements Analysis and Design Definition); оценка решения (Solution Evaluation).

RLCM и инженерия требований (RE). В BABOK RLCM охватывает трассировку, приоритизацию, изменения и информацию для проектирования (design information) на всём жизненном цикле (→ 02.05.05 Жизненный цикл требования). В ISO 29148 RE — процессная рамка с жёстче заданными входами, выходами и критериями качества. Рамки согласуемы, но не тождественны: RLCM шире по артефактам BA, ISO — строже по процессам жизненного цикла.

Design Definition — граница BA и SA. Область «Requirements Analysis and Design Definition» включает проектирование решения на уровне BA (варианты, прототипы, бизнес-правила). Когда решение становится IT-системой, детализация переходит к системному анализу (→ 00.02 Бизнес-анализ vs Системный анализ vs Требования, 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая)). Не смешивайте BA-дизайн процесса и SA-дизайн системы.

ISO/IEC/IEEE 29148:2018

Инженерия требований (requirements engineering, RE) — междисциплинарная функция, связывающая заказчика и исполнителя для установления и поддержания требований к системе, ПО или услуге на протяжении жизненного цикла.

Процессы жизненного цикла vs детализация RE. Три процесса, ведущие от миссии к системным требованиям, определены в ISO/IEC/IEEE 15288:2023 (жизненный цикл систем), а не в 29148. Названия приведены по актуальной редакции 15288; при расхождении с локальной копией ориентируйтесь на ISO/IEEE:

  • Business or Mission Analysis — цели, проблемы и возможности на уровне предприятия или миссии;
  • Stakeholder Needs and Requirements Definition — потребности заинтересованных сторон в их терминах;
  • System/Software Requirements Definition — детализация до уровня проектирования и реализации.

ISO 29148 детализирует инженерию требований внутри этих и смежных процессов: извлечение (→ 02.02.01 Интервьюирование и анкетирование), анализ, спецификация (→ 02.03.03 Спецификация требований (SRS, Use Case, User Story)), валидация, управление изменениями (→ 02.05.02 Управление изменениями (Change Control Board)). Для ПО параллельная рамка — ISO/IEC/IEEE 12207 (процессы жизненного цикла программных систем).

Критерии качества требований — ключевой вклад стандарта. Для отдельного требования: необходимое (necessary), однозначное (unambiguous), полное (complete — все детали в одной формулировке), выполнимое (achievable), поддающееся проверке (verifiable). Для набора: непротиворечивое (consistent), полное (complete — покрытие всех аспектов системы), упорядоченное по важности и стабильности (ranked). Один термин complete — два разных критерия; путаница здесь — частая ошибка на ревью SRS. Практика проверки и чек-листы — в 02.04.03 Управление качеством требований и 08.03 Тестирование требований (статическое тестирование).

Атрибуты и трассировка. Стандарт рекомендует идентификатор, автора, версию, обоснование, приоритет, статус, источник и связи между требованиями (→ 02.03.04 Трассировка требований (концепция)). Рекомендации по языку помогают избегать двусмысленности («support», «manage», «etc.»).

SEBoK

SEBoK — живой путеводитель по системной инженерии в формате wiki; не является стандартом или учебником, а систематизирует термины, процессы и ссылки на литературу (версия 2.14). Полезен, когда проект выходит за рамки «IT-фичи»: интеграция подсистем, legacy, физические и организационные границы.

Из чего состоит wiki. SEBoK организован в части (parts): основы системной инженерии (SE foundations), подходы и управление жизненным циклом (systems approaches and lifecycle), прикладные области и специальные темы (specialty areas). Для первого знакомства достаточно Part 2 (основы) и разделов Part 3 про жизненный цикл; детали моделирования, архитектуры и интеграций — в ветках 01.* и 03.*, а не в полном перечитывании wiki.

Системное мышление в SEBoK опирается на целостность, иерархичность, причинность и контекст — базовые принципы системного подхода; разбор с примерами — в 01.01 Понятие системы и системного подхода, а не здесь.

Generic Life Cycle Model (Exploration → Concept → Development → Production → Utilization and Support → Retirement) задаёт стадии без привязки к Waterfall или Agile. Связь с SDLC/STLC и ролью аналитика — в 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC).

Для аналитика в SEBoK особенно релевантны управление требованиями, определение архитектуры системы, V&V — детали процессов см. 02.04.01 Верификация и валидация (V&V), 08.05 Управление рисками на этапе анализа, 03.01.01 Понятие архитектуры ИС и её виды (бизнес-, системная, техническая).

Экосистема смежных стандартов

СтандартРоль для аналитика
ISO/IEC/IEEE 15288:2023Родительская модель жизненного цикла систем; контекст для процессов из § выше
ISO/IEC/IEEE 12207:2017Жизненный цикл ПО; 29148 гармонизирован с обоими
ISO/IEC 25000 (SQuaRE)Серия стандартов о качестве ПО и систем; для НФТ на практике чаще ссылаются на ISO/IEC 25010 (модель качества) → 08.02 Нефункциональные требования (НФТ) — классификация и стандарты
PMBOK / Requirements Management Practice Guide (PMI)Управление проектом и требованиями на стыке с BA; совместная работа BA + PM → 02.05.01 Управление зависимостями между требованиями, 02.05.03 Управление объёмом (Scope Creep) и ожиданиями
IREB CPREЕвропейская рамка RE и сертификация; пересекается с ISO 29148 по качеству требований, дополняет BABOK с технической стороны RE
SWEBOK v4Свод знаний программной инженерии; дополняет SEBoK для SA

Локальный слой (РФ). В госконтрактах и крупных интеграционных проектах нередко ссылаются на ГОСТ 34 (стадии создания АС), ЕСПД и отраслевые регламенты поверх ISO. Международный стандарт не отменяет локальных ТЗ — уточняйте, какой документ указан в контракте.

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

Три документа дополняют, а не конкурируют друг с другом. Схема ниже — упрощённая опора: сплошные стрелки показывают основной акцент; пунктир — пересечения (RLCM в BABOK, Design Definition, V&V в SEBoK).

graph TD
    subgraph "Стандарты и своды знаний"
        BABOK
        SEBoK
        ISO_29148
    end
    subgraph "Аналитическая деятельность"
        BA["Бизнес-анализ<br/>зачем и что делать"]
        SA["Системный анализ<br/>как устроено решение"]
        RE["Инженерия требований<br/>качество и управление"]
    end

    BABOK --> BA
    BABOK -.->|RLCM, design info| RE
    SEBoK --> SA
    SEBoK -.->|жизненный цикл, V&V| RE
    ISO_29148 --> RE
    ISO_29148 -.->|критерии в контракте| BA

Кому что читать первым:

  • Начинающему BA — структура BABOK v3 и BACCM; техники выявления — в 02.02.*, не в полном тексте guide.
  • Системному аналитику — ISO 29148 (критерии качества, атрибуты) + SEBoK для контекста сложных систем; архитектура — ветка 03.*.
  • Функциональному аналитику (FA) — ISO 29148 (атрибуты, качество контрактов) + ветка 03.05.* (интеграции, API); BABOK — для контекста BA-задач на стыке (→ 00.01 Кто такой аналитик (роли BA, SA, FA)).
  • Regulated / госконтракт — ISO 29148 + форматы SRS/BRD (→ 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)); сверка с ГОСТ 34, если указан в ТЗ.
  • Agile-продукт — BABOK как карта задач + Agile Extension to the BABOK Guide (расширение IIBA для гибких контекстов); адаптация к Scrum/Kanban — 05.02 Scrum и Kanban (аналитик в Agile). ISO 29148 не привязан к методологии: критерии качества формулировок и приёмки применимы и в Agile; полная структура SRS по стандарту обычно не нужна — достаточно AC, трассировки и атрибутов там, где это требует контракт.

Типовые сценарии:

СценарийОпораАртефакты в KB
Продуктовая команда, короткие итерацииBABOK + Agile ExtensionUser Story, AC → 04.02 Пользовательские истории (User Stories) и Job Stories
Формальный SRS для заказчика / аудитаISO 29148 + 15288/12207SRS, матрица трассировки → 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD), 02.03.04 Трассировка требований (концепция)
Крупная система с интеграциями и legacySEBoK + ISO 29148Context diagram, ADR → 03.01.02 Моделирование контекста системы (Context Diagram), 10.01.13 Шаблон архитектурного решения (ADR)
Интеграции, контракты API (роль FA)ISO 29148 + 03.05.*OpenAPI, матрица трассировки → 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 10.01.04 Шаблон спецификации REST API

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

  • Смешение 15288 и 29148 — приписывать процессы Business/Mission Analysis стандарту 29148; 29148 детализирует RE, а не весь жизненный цикл.
  • «ISO — тоже просто гайд» — в контракте 29148 нормативен; BABOK и SEBoK — ориентиры для практики и обучения.
  • Два Complete без различения — «полная формулировка» одного требования ≠ «полное покрытие» системы набором; дальше — только практика в 02.04.03 Управление качеством требований.
  • RLCM = ISO RE один к одному — термины пересекаются, но объём и артефакты различаются; не выстраивайте процесс «только по одному документу».
  • Design Definition без handoff — см. §2 и 00.02 Бизнес-анализ vs Системный анализ vs Требования; не оставляйте API и модели данных «на стороне BA».
  • Перечитывание SEBoK вместо веток vault — принципы holism/иерархия уже в 01.01 Понятие системы и системного подхода; риски и V&V — в 08.05 Управление рисками на этапе анализа, 02.04.01 Верификация и валидация (V&V).
  • Игнор локальных стандартов — ссылка на ISO в тендере не отменяет ГОСТ 34 / ЕСПД, если они указаны в ТЗ.
  • Устаревшие версии — SEBoK и SWEBOK обновляются чаще печатных изданий; фиксируйте версию в проектной wiki.

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

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

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

Книги и руководства

  • (в папке с книгами) BABOK Guide v3.0: IIBA. A Guide to the Business Analysis Body of Knowledge. — Toronto: IIBA, 2015. ISBN 9781927584026.
  • (в папке с книгами) Agile Extension to the BABOK Guide v2: IIBA. — Toronto: IIBA, 2017.

Статьи и онлайн-ресурсы

  • DOU: Критерии качества требований и как им следовать (сравнение BABOK, ISO 29148, PMI, IREB): https://dou.ua/forums/topic/35139/