После того как определена бизнес-проблема, сформулированы цели и проанализированы заинтересованные стороны, встаёт ключевой вопрос: «Что именно мы будем делать, а что — точно нет?» Ответ даёт моделирование границ решения (Scope Modelling). Чёткий scope — главный инструмент против расползания требований и бесконечных проектов; детальный контур управления объёмом — в 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.

1. Суть темы

Определение (BABOK v3, см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)):

Границы решения (Solution Scope) — набор возможностей (capabilities), которые должно обеспечить создаваемое или изменяемое решение для удовлетворения выявленной бизнес-потребности.

В BABOK v3 Scope Modelling относится к области Strategy Analysis (Analyze Current State, Define Future State, Define Design Options) и к техникам главы «Techniques» — не сводится к одной задаче «Define Change Strategy».

Границы отвечают на три вопроса:

  • Что внутри? — функциональность, данные, интерфейсы, бизнес-правила, которые будут реализованы.
  • Что снаружи? — смежные системы, процессы, пользователи, организации, с которыми решение взаимодействует, но которые не изменяются в рамках данного scope.
  • Что именно исключено? — функциональность, которую явно решили не делать в текущем проекте или релизе (даже если стейкхолдеры о ней просили).

Важно: одна диаграмма не закрывает все три вопроса. Контекстная диаграмма и Use Case Diagram хорошо показывают «внутри / снаружи», но не фиксируют явные исключения. Для третьего вопроса нужен отдельный артефакт — матрица In/Out или раздел «Out of scope» в Vision & Scope. Формат и структура документа — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD); здесь — зачем фиксировать исключения и когда baseline считается готовым. На практике связка «контекст + In/Out List» — минимальный набор для baseline scope.

Цепочка уровней границ

На этапе стратегического анализа полезно держать в голове цепочку (сверху вниз — от организации к поставке):

УровеньВопросПример
Граница бизнес-измененияКакие процессы, подразделения, продуктовые линии затрагивает инициатива end-to-end?«Процесс «Заказ → Отгрузка» меняем целиком; «Возвраты» — только touchpoint в CRM, без перестройки склада».
Scope решенияКакие возможности должна дать ИТ-система или продукт?«Оформление заказа, уведомления, экспорт счёта в 1С».
Scope проектаКакие работы нужны, чтобы создать и внедрить решение?«Разработка, интеграция, миграция справочника, обучение 20 менеджеров».

Граница бизнес-изменения часто проясняется на as-is / to-be сессиях по процессам — см. 03.04.01 BPMN 2.0 - введение и основы; здесь достаточно зафиксировать какой процесс целиком, а какой — частично (например, «автоматизируем шаг 3 из 7»). Это first-class concept: частичный scope процесса ≠ «весь процесс в системе».

Предшественники в треке 02.01: 02.01.01 Определение бизнес-проблем и возможностей, 02.01.02 Цели, KPI и критерии успеха (SMART, GQM), 02.01.03 Анализ заинтересованных сторон (Stakeholder Map).

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

Scope решения vs scope проекта

ПонятиеОпределениеПример
Scope решения (product / solution scope)Совокупность возможностей, которые решение должно предоставить для удовлетворения бизнес-потребности.«Система оформляет заказ, шлёт уведомление на почту, передаёт данные в 1С».
Scope проекта (project scope)Работы для создания, внедрения и развёртывания решения: анализ, разработка, тестирование, обучение, миграция.«Модуль заказа, интеграция с почтой, миграция справочника, обучение».

Роли (типовая матрица RACI):

ЗонаAccountable / ResponsibleРоль BA
Scope решенияProduct Owner, спонсор или назначенный владелец продукта — A; BA — R (моделирование, согласование с целями)Моделирует capabilities, In/Out, трассировку к 02.01.02 Цели, KPI и критерии успеха (SMART, GQM)
Scope проектаPM или спонсор — A; PM — R (WBS, ресурсы, сроки)C: даёт вводные по объёму работ анализа и зависимостям решения, но не владеет уставом проекта

BA не «отвечает за оба scope» в смысле владения: аналитик ведёт моделирование границ решения и консультирует PM по влиянию scope решения на объём работ. Понимание project scope нужно для реалистичных оценок и сроков.

На уровне программы или портфеля границы могут быть разнесены по нескольким командам и релизам — см. 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках.

Статусы элементов scope

В матрице In/Out и scope statement различайте:

СтатусСмысл
In scopeВходит в текущий baseline (релиз / проект).
Out of scopeСознательно не делаем; может вернуться позже, но не обещано.
DeferredОтложено на следующую волну (v2, Phase 2) с явной отметкой «не в текущем baseline».
Owned by other projectНужно бизнесу, но финансируется и поставляется другой инициативой (например, интеграция SAP — отдельный проект).

Размытая формулировка «не сейчас» без статуса — частый источник конфликтов при приёмке. Запросы «широкого круга» стейкхолдеров без decision rights чаще всего превращаются в ложный deferred — см. §3.7.

NFR в границах scope

На этапе стратегии достаточно зафиксировать категории нефункциональных требований в scope (безопасность, производительность, доступность) и уровень детализации (только категории vs целевые SLA). Конкретные метрики — в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты; регуляторные обязательства — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).

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

3.1 Контекстная диаграмма (Context Diagram)

Показывает решение как «чёрный ящик» и внешние сущности (акторы, системы, организации) с границами взаимодействия.

  • Что внутри: центральный блок (наше решение).
  • Что снаружи: все внешние сущности.
  • Исключения: на диаграмме не обозначаются; всё, что не нарисовано как взаимодействие, не входит в модель контекста, но не заменяет явный список «что точно не делаем».

На этапе стратегии достаточно акторов и границ взаимодействия; подписи потоков на примере ниже — иллюстрация, а не обязательная детализация. Разбор состава потоков и их атрибутов — 03.01.02 Моделирование контекста системы (Context Diagram); полная модель потоков данных — 03.04.02 Диаграмма потоков данных (DFD).

graph TD
    subgraph "Решение (чёрный ящик)"
        S[Solution]
    end
    P1[Клиент] -->|Размещает заказ| S
    P2[Менеджер] -->|Управляет каталогом| S
    S -->|Отправляет счёт| ERP[1С:ERP]
    S -->|Уведомление| Email[Почтовый сервис]
    ERP -->|Справочник товаров| S

3.2 Диаграмма прецедентов (Use Case Diagram)

Очерчивает границу системы: акторы и use cases внутри рамки — scope решения.

  • Исключения: use cases вне текущего релиза помечают «v2» / «future» или выносят на отдельную диаграмму.

Подробнее — 03.02.01 Диаграмма прецедентов (Use Case Diagram); выбор Use Case vs User Story — 04.03 Use Case vs User Story — выбор подхода.

3.3 Дерево возможностей (Feature Tree)

Иерархия capabilities / features для scope и MVP: корень — решение, ветви — функциональные области и фичи. В BABOK capability — способность организации или решения создавать ценность на уровне бизнеса; feature — более конкретная единица, которую можно включить в In/Out и релиз. На практике дерево часто смешивает оба уровня: верхние ветви — capabilities, листья — features.

Это BA-артефакт стратегии («что входит в продукт»), а не техническая декомпозиция на модули и подсистемы — последняя относится к системному анализу: 03.01.03 Декомпозиция системы на подсистемы и модули. Техника BABOK Functional Decomposition на стратегии применяется к бизнес-возможностям и областям продукта, а не к архитектурным компонентам.

Пример:

  • Интернет-магазин
    • Каталог: поиск, фильтрация, карточка товара
    • Заказ: регистрация (MVP), гостевая покупка (deferred)
    • Личный кабинет: история заказов (MVP), профиль (deferred)

3.4 Матрица включения/исключения (In/Out List)

Итоговый артефакт после контекста или дерева фич; обязателен для явных исключений. Статусы из §2 — рабочий минимум для baseline; полный шаблон раздела — в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

Функция / возможностьСтатусКомментарий
Оформление заказа с регистрациейIn scopeMVP
Гостевая покупкаDeferredПосле запуска MVP
Интеграция с 1С:ERPIn scopeТолько экспорт счетов
Интеграция с SAPOwned by other projectОтдельный проект в следующем году
Мобильное приложениеOut of scopeТолько адаптивный web

3.5 Артефакты фиксации границ

3.6 MVP, MMF, MBI — граница первой поставки

ТерминКритерий «когда выбираем»Фокус
MVPНужно проверить гипотезу или получить обратную связь при минимальных затратахОбучение, эксперимент
MMFФича сама по себе может быть выпущена и продана/использованаРыночная ценность единицы функциональности
MBIНужен измеримый бизнес-результат для организации (связь с KPI — 02.01.02 Цели, KPI и критерии успеха (SMART, GQM))Минимальное бизнес-приращение

MMF и MBI в части команд пересекаются; если команда не различает — зафиксируйте одно имя и критерий «done» для первой волны.

Фиксация MBI в In/Out: минимальный измеримый KPI + минимальный набор capabilities, без которых KPI не достижим. Пример: KPI «−30% времени обработки заказа» → In scope: «оформление заказа», «экспорт в ERP»; Out: «личный кабинет с историей». Строки MBI переносите в матрицу §3.4 с явным статусом In scope и ссылкой на KPI.

Разделение уровней: MVP/MBI задают границу продукта или релиза на стратегии; definition of scope спринта и thin vertical slices — тактика delivery, см. 05.02 Scrum и Kanban (аналитик в Agile).

3.7 Design options, валидация и baseline scope

На этапе Define Design Options (BABOK) scope моделируют для каждого варианта решения отдельно, затем сравнивают по целям, рискам и стоимости — и только после выбора варианта фиксируют один baseline:

  1. Вариант A (например, доработка legacy) → scope A: контекст + In/Out.
  2. Вариант B (новая платформа + интеграции) → scope B: другой набор capabilities и исключений.
  3. Сравнение по 02.01.02 Цели, KPI и критерии успеха (SMART, GQM) и ограничениям.
  4. Выбранный design option → единственный baseline scope → sign-off.

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

  1. Walkthrough с ключевыми стейкхолдерами по 02.01.03 Анализ заинтересованных сторон (Stakeholder Map):
    • Обязательны на сессии (R/A на scope): спонсор или PO, владелец процесса, представитель ИТ/архитектуры при интеграциях.
    • Consulted: эксплуатация, compliance, ключевые пользователи — проверяют In/Out по своей зоне.
    • Informed после baseline: широкий круг заинтересованных без права менять статус без change request.
    • Контекст + In/Out — каждый пункт «внутри / снаружи / исключено» проговаривается вслух; «хотелки» без decision rights не переводите в deferred без явного согласия accountable.
  2. Sign-off baseline: accountable — спонсор или PO (зависит от модели); BA готовит материалы (R).
  3. Критерии готовности baseline (Definition of Ready для scope): связь элементов scope с целями/KPI; явные исключения и deferred; согласованные границы NFR-категорий; зафиксированные зависимости от внешних систем и assumptions по рискам (см. 02.05.01 Управление зависимостями между требованиями, 08.05 Управление рисками на этапе анализа).
  4. Validation — «строим ли правильное» (соответствие потребности); verification деталей требований — позже, см. 02.04.01 Верификация и валидация (V&V) и 08.04 Рецензирование и инспекции (техники Фейгана).

Элементы scope затем трассируют к эпикам и требованиям — 02.03.04 Трассировка требований (концепция). При смене целей или повторном выборе design option baseline пересматривают целиком (не только через change request). В каскадных моделях baseline часто привязывают к воротам фазы — см. 05.01 Waterfall и V-model.

3.8 Scope baseline и расползание границ

Scope creep — неконтролируемое расширение без учёта сроков, бюджета и ресурсов. На этапе стратегии аналитик:

Процесс ожиданий, метрики стабильности, эскалация и роли BA/PM — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями; формальные change request — 02.05.02 Управление изменениями (Change Control Board). Приоритизация (MoSCoW, WSJF) — смежный инструмент отсечения; механика — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

3.9 Чек-лист вопросов для сессий

Перед воркшопом соберите черновик границ через 02.02.01 Интервьюирование и анкетирование и 02.02.03 Наблюдение и анализ документов; на сессии фиксируйте ответы (02.02.02 Воркшопы, фасилитация и совместные сессии). Первый черновик scope не путайте с baseline — см. 01.07 Когнитивные искажения и критическое мышление. Перед freeze scope — 10.04 Чеклист аналитика перед стартом разработки.

  • Какие бизнес-процессы полностью в scope? Какие — частично (какие шаги)?
  • Какие внешние системы — поставщики данных? Потребители?
  • Граница данных: какие master data in/out; нужна ли миграция; чьи справочники — источник истины (MDM, ERP, CRM)?
  • Какие роли работают с системой напрямую? Какие — только через другие системы?
  • Какие отчёты/дашборды в первой очереди?
  • Что откладываем (deferred) vs исключаем (out of scope)? Кто accountable за статус?
  • Есть ли регуляторные или договорные обязательства с жёстким перечнем функций?
  • Какие категории NFR в scope и на каком уровне детализации?
  • Согласованы ли product baseline и scope в SOW/контракте?

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

  • «Сделаем всё и сразу» — раздутый scope, срыв сроков. Действие: In/Out + MVP/MBI и приоритизация (02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)).
  • Размытые формулировки («улучшить UX») — нельзя проверить in/out. Действие: конкретные capabilities или сценарии.
  • Только контекстная диаграмма, без списка исключений — стейкхолдеры помнят обсуждения, а не baseline. Действие: In/Out или раздел Out of scope в Vision & Scope.
  • Scope statement в договоре ≠ product baseline — на приёмке «мы оплатили X» не совпадает с «система делает Y». Действие: сверка SOW, scope statement и In/Out до sign-off; расхождения — явное решение спонсора.
  • Scope без ключевых стейкхолдеров — расхождение с ожиданиями спонсора; ложный deferred от «громких» consulted. Действие: walkthrough по карте стейкхолдеров (§3.7); см. 09.07 Управление ожиданиями заказчика.
  • Игнор границы данных — «SAP out of scope», но без master data из ERP решение не работает. Действие: строки In/Out по данным и владению; assumption «интеграция X — scope проекта Y» в реестре рисков (08.05 Управление рисками на этапе анализа).
  • Игнор зависимостей от внешних систем — «без импорта из SAP система мертва», а интеграция out of scope. Действие: 02.05.01 Управление зависимостями между требованиями.
  • Один scope до выбора design option — baseline фиксируют до сравнения вариантов, потом переделывают всё. Действие: отдельный scope на вариант, один baseline после выбора (§3.7).
  • Путаница Feature Tree и модульной декомпозиции — дублирование с SA. Действие: capabilities здесь, модули — 03.01.03 Декомпозиция системы на подсистемы и модули.
  • Смешение границы релиза и границы спринта — scope продукта «плывёт» каждые две недели. Действие: baseline релиза на стратегии, тактика — 05.02 Scrum и Kanban (аналитик в Agile).

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

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

Книги и стандарты

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

Дополнительно