Приоритет backlog, MoSCoW и даже WSJF не отвечают полностью на вопрос «можно ли это сделать раньше?»: WSJF учитывает стоимость задержки, но не топологию графа связей. Зависимость между требованиями (requirement dependency) означает, что реализация, проверка или изменение одного требования условлено другим — или общим артефактом: данными, API, ролью, регуляторикой. Без явной карты связей команда берёт в спринт «готовые» stories, которые нельзя интегрировать, а change request вызывает неожиданный каскад правок. Эта статья — про выявление, документирование и сопровождение таких связей совместно с PM: порядок поставки, блокеры, конфликты и impact analysis.

1. Суть темы

Управление зависимостями между требованиями — часть совместного управления требованиями (BA + PM): установление и поддержание отношений «одно требование влияет на другое» на протяжении жизненного цикла. Зависимости — подмножество трассируемых связей из 02.03.04 Трассировка требований (концепция): здесь фокус на горизонтальных и межуровневых ограничениях порядка, а не на полной цепочке «цель → реализация → тест». Стандарты и своды практик по связям между требованиями — см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

Для системного аналитика зависимости — инструмент согласованного scope и предсказуемой последовательности. Они часто жёстко задают порядок реализации независимо от 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано): Must-have B, заблокированный Could-have A, всё равно не поставить, пока A не решён или не переработан B.

Типичные ситуации на проекте:

СитуацияЧто означает зависимость
«Сначала платформа, потом фича»Prerequisite (Finish-to-Start): B нельзя принять без A; enabler/platform — см. 02.03.01 Классификация требований (БТ, ФТ, НФТ) и 04.02 Пользовательские истории (User Stories) и Job Stories
Две stories делят одну сущность данных или APIShared resource: изменение источника правды ломает потребителей; изменение потребителя тянет owner и контракт
Epic разбит на storiesRefinement / decomposition: не блокировка, но влияет на completeness
«Безлимитный доступ» vs «тариф с квотой»Conflict: нужно решение и фиксация исхода, а не только приоритет
«Сначала security gate, потом feature X»NFR-prerequisite: hard dependency по политике или регуляторике — см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты
Фича в релизе 2, интеграция — в релизе 1Temporal / release: плановый порядок поставки; без hard prerequisite не блокирует DoR, но ломает coherent increment и обещание заказчику
Ждём контракт внешнего провайдераExternal / regulatory: вне прямого контроля команды
flowchart LR
    A[REQ-A: мастер-данные клиента] -->|prerequisite| B[REQ-B: оформление заказа]
    A -->|shared resource| C[REQ-C: отчёт по клиентам]
    B -.->|conflicts with| D[REQ-D: анонимный checkout]
    E[REQ-E: API v2] -->|release order| F[REQ-F: миграция потребителей]

Граница статьи: межтребовательные связи и управление ими. Классификация и формат — 02.03.01 Классификация требований (БТ, ФТ, НФТ) и 02.03.03 Спецификация требований (SRS, Use Case, User Story); границы scope — 02.01.04 Определение границ решения (Scope Modelling); полная модель трассировки и типы связей в RTM — 02.03.04 Трассировка требований (концепция).

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

ПонятиеСуть
Зависимость требований (requirement dependency)Отношение, при котором реализация, проверка или изменение одного требования условлено состоянием, наличием или результатом другого (или артефакта)
Prerequisite / Finish-to-Start (A → B)B нельзя полноценно реализовать или принять, пока не выполнено или не стабилизировано A
Shared resource / связанность (coupling)Несколько требований опираются на одну сущность данных, API, роль, отчёт — риск каскадных изменений в обе стороны; у связи есть owner источника правды
Conflict / mutual exclusionДва требования несовместимы по поведению, NFR или политике — нужно решение с фиксацией исхода
Verification dependencyТест или приёмка B невозможны без среды, данных или компонента от A — см. 02.04.01 Верификация и валидация (V&V)
Dependency graphНаправленный граф связей; циклы (A→B→A) сигнализируют о противоречии или незрелой декомпозиции
Critical path по требованиям (логический)Самая длинная цепочка prerequisite/temporal в графе; минимальная логическая длина инкремента. Не путать с календарным critical path PM: ресурсы, параллельные потоки, буферы и даты накладывает PM поверх логической цепочки

Типы зависимостей (рабочая таксономия)

Полная семантика типов связей в RTM — в 02.03.04 Трассировка требований (концепция); ниже — операционная таксономия для dependency management.

ТипНаправлениеПримерДействие
PrerequisiteA → BСправочник валют → расчёт цены в валютеЖёсткий порядок в плане
RefinementParent → ChildБТ → ФТ, Epic → StoryКонтроль полноты декомпозиции; не блокирует реализацию child по умолчанию
Shared resourceOwner → ConsumersДва UC используют один REST-контракт; owner — REQ-контракт APIImpact при изменении owner или consumer; уведомление и согласование контракта
ConflictA ⊥ BХранение всех логов vs GDPR-удалениеTrade-off → decision log → статус resolved conflict
Temporal / releaseA (R1) → B (R2)Базовый API в релизе 1, клиенты — в 2Согласование с PM; без hard prerequisite — не блокирует DoR, но блокирует целостный инкремент и коммуникацию релиза
ExternalExternal → REQЛицензия, third-party SLA, regulationРиск, owner и дата вне команды — см. 08.05 Управление рисками на этапе анализа

Hard dependency блокирует Definition of Ready или приёмку. Soft dependency допускает параллельную работу с заглушками — но только после явного risk acceptance: PM фиксирует срок снятия заглушки, architect или tech lead подтверждает допустимость mock/stub, BA документирует verification gap до появления реального компонента. Story не берётся в спринт без подписи architect/tech lead на stub-подход; если architect отклоняет заглушку после того как PM уже обещал story — эскалирует PM (решение о sequencing), BA фиксирует gap и возвращает story в backlog до hard dependency или пересмотра scope.

Verification dependency — не только «компонент от A». Типичные подвиды:

ПодвидПример
Test data / fixtureМастер-данные клиента нужны до сценария оформления заказа
Feature flag / toggleПриёмка B возможна только после включения платформенного флага из A
Staging / partner sandboxИнтеграционный тест ждёт sandbox внешнего провайдера или preprod-среды

Транзитивность: если A → B и B → C, для планирования и release review считайте, что A должно быть решено до C — даже без прямого ребра A → C. На больших графах перед PI или релизом проводите precedence review: обход транзитивных цепочек вручную или через инструмент.

Derives from vs refinement: derives from — происхождение формулировки (источник текста, норматив); refinement — декомпозиция поставки (parent/child в backlog). Оба фиксируются в RTM (02.03.04 Трассировка требований (концепция)), но на порядок спринта влияют только refinement + prerequisite + hard verification/temporal с блокирующим статусом.

Разрешение conflict: куда фиксировать исход

Conflict не закрывается эскалацией «на словах». Минимальный управляемый исход:

  1. Decision log (ADR, секция в change request или dependency log): что выбрано — отмена REQ, изменение политики, phased compromise, de-scope одного из требований.
  2. Обновление статуса связи в RTM: conflicts with → resolved conflict с ссылкой на решение и дату.
  3. Согласование scope с 02.05.03 Управление объёмом (Scope Creep) и ожиданиями — если trade-off меняет границы релиза.
  4. При необходимости — change request через 02.05.02 Управление изменениями (Change Control Board); пересмотр приоритетов затронутых REQ — 02.05.02 Управление приоритетами в условиях изменчивости.

До статуса resolved conflict оба REQ считаются release-blocking для затронутого scope.

Зависимости в RTM и ALM

Для dependency management в RTM добавляются поля поверх вертикальной трассировки: ID₁ → ID₂, тип связи, направление, owner (shared/external), статус, комментарий/риск. Формат — 10.01.15 Шаблон матрицы трассировки; полный перечень типов связей и кардинальность — 02.03.04 Трассировка требований (концепция).

Инструмент vs семантика: нативные blocks / is blocked by в ALM — механика видимости в backlog; RTM хранит тип и смысл (prerequisite ≠ conflict ≠ temporal). Один blocks в Jira без типа в RTM теряет контекст impact analysis.

Роли BA и PM

РольЗона ответственности по зависимостям
SA/BAМодель связей, формулировки, фиксация исходов conflict, impact analysis при изменениях
PMSequencing, календарный план поверх логического critical path, milestones, risk acceptance для soft dependencies, эскалация при расхождении с architect
ArchitectТехнические и интеграционные зависимости — см. 03.01.04 Интерфейсы и интеграционные взаимодействия, 03.01.03 Декомпозиция системы на подсистемы и модули
QAVerification dependencies, покрытие трассировки тестами

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

Когда начинать

После первичной 02.03.01 Классификация требований (БТ, ФТ, НФТ) и черновой 02.03.03 Спецификация требований (SRS, Use Case, User Story) — на 02.02.02 Воркшопы, фасилитация и совместные сессии с архитектором, PM и QA. При 02.01.04 Определение границ решения (Scope Modelling) и декомпозиции явно помечайте: blocked by, requires, conflicts with.

Откладывать карту зависимостей до «стабилизации backlog» рискованно: в agile backlog меняется часто, но release-blocking связи нужно фиксировать сразу.

Рабочий цикл

1. Inventory. Список требований с согласованными ID (SRS, User Story map, ALM). Enabler/platform epics — в той же карте, что user-facing REQ, с типом prerequisite к фичам.

2. Elicitation зависимостей. Интервью, design-сессии, review контрактов — см. 02.02.02 Воркшопы, фасилитация и совместные сессии. Вопросы-якоря:

  • Что должно существовать до реализации этого требования?
  • С чем делим данные, экран, API, роль? Кто owner общего артефакта?
  • Что ломается, если изменить соседнее требование — в том числе если меняется consumer, а не только owner?
  • Можно ли протестировать без другого компонента, тестовых данных, флага или sandbox?
  • Есть ли несовместимые формулировки, требующие trade-off?

Интеграционная зависимость на практике почти всегда двойная: prerequisite (сервис или контракт доступен) + shared resource (общий API/событие как источник правды) — см. 03.01.04 Интерфейсы и интеграционные взаимодействия, 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf).

3. Document. RTM, секция в SRS или нативные links в инструменте (Jira blocks / is blocked by, Azure DevOps, DOORS) — см. 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence). Минимум на связь: два ID, тип, направление, owner (для shared/external), комментарий. Для conflict — placeholder до decision log.

4. Validate. Walkthrough с dev/QA:

  • Циклы и транзитивные цепочки;
  • «висящие» external без owner;
  • смешение conflict, prerequisite и temporal;
  • verification dependencies — связь с 02.04.02 Критерии приёмки (Acceptance Criteria) и тест-планом: для каждого REQ с verification dependency — явный тестовый prerequisite или заглушка с датой снятия.

5. Sync с планом. PM переводит hard dependencies и логический critical path по требованиям в порядок работ, параллельные потоки и календарь; soft — в backlog ordering с WSJF только после risk acceptance. Совместная 02.05.04 Совместная оценка трудоёмкости требований учитывает ожидание блокеров. Precedence review перед планированием релиза или PI: транзитивные цепочки, unresolved conflict, external с просроченной датой.

6. Change control и сопровождение графа. При change request — impact analysis (ниже), обновление тестов и release notes. При split/merge story, смене ID или duplicate — перенос и снятие рёбер в RTM и ALM; устаревшие blocks — типичный источник ложных blockers — см. 02.05.05 Жизненный цикл требования. Формальный процесс изменений — 02.05.02 Управление изменениями (Change Control Board); пересмотр порядка работ при сдвиге блокеров — 02.05.02 Управление приоритетами в условиях изменчивости.

Impact analysis при изменении REQ

Локальная процедура для BA при change request или существенном уточнении формулировки (детали governance — 02.05.02 Управление изменениями (Change Control Board)):

  1. Якорь: зафиксируйте, что именно изменилось в REQ-X (формулировка, scope, статус, контракт).
  2. Upstream (1–2 hops): от чего зависит X — prerequisite, shared owner, external, verification prerequisite. Для shared resource проверяйте и owner, и consumers.
  3. Downstream: кто зависит от X — прямые блокируемые REQ; для hard/prerequisite — транзитивный обход до release-blocking цепочек; для soft — только прямые связи + пометка «требует risk acceptance».
  4. Reverse shared impact: если менялся consumer REQ — поднимитесь к owner API/данных и всем sibling-consumers.
  5. Conflicts: все conflicts with / unresolved conflict, где участвует X или затронутые downstream REQ.
  6. Vertical trace: по каждому затронутому REQ — stories, тесты, AC (02.03.04 Трассировка требований (концепция)).
  7. Stop-rules: external без смены ETA — в отчёт impact, без автоматического блокирования; soft без risk acceptance — флаг, не hard blocker; temporal без prerequisite — влияние на narrative релиза, не на DoR.
  8. Артефакт: заполните impact analysis template — затронутые ID, тип влияния, stakeholders, решение (принять / отложить / de-scope).

Глубина обхода: для косметической правки текста без смены поведения — 1 hop и vertical trace; для split epic, смены контракта или scope — полный транзитивный обход hard-цепочек.

Артефакты

АртефактНазначение
Dependency log / секция в SRSТаблица связей для ревью и контрактной поставки
RTM с типами связейЕдиная точка для audit и impact analysis — поля зависимостей поверх 02.03.04 Трассировка требований (концепция)
Decision log / resolved conflictИсход trade-off, ссылка из RTM
Impact analysis templateПри изменении: затронутые ID, тип влияния, stakeholders
Precedence matrixLiving artifact в ALM/RTM; снимок на пакет релиза или PI — какие REQ должны войти в инкремент до других (формат — 10.01.15 Шаблон матрицы трассировки)
DoR checklist«Нет unresolved hard blocker и unresolved conflict» — см. 10.04 Чеклист аналитика перед стартом разработки

Техники выявления

Agile-практики

На уровне epic / feature / story:

  • Связи blocks в backlog-инструменте — видимость для PM и команды.
  • Definition of Ready: story не берётся в спринт при unresolved hard blocker или conflict; soft — только с risk acceptance (PM + architect/tech lead) и сроком снятия заглушки.
  • Зависимости от других команд — тип external с named owner и датой.

В 05.02 Scrum и Kanban (аналитик в Agile) карта зависимостей дополняет 02.05.02 Управление приоритетами в условиях изменчивости: порядок в колонке backlog не отменяет логический prerequisite.

Program / multi-team: та же модель масштабируется через external между командами. В SAFe — dependency board и PI Planning с precedence matrix на инкремент. В LeSS — координация на multi-team refinement, общие области backlog и явные cross-team REQ без PI-лексики. Детали роли аналитика — 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках.

Пример фрагмента dependency log

ID источникID цельТипСтатусКомментарий
REQ-018REQ-042prerequisiteactiveСправочник статусов заказа
REQ-055REQ-042shared resourceactiveOwner API /orders → consumer REQ-042
REQ-055REQ-061shared resourceactiveOwner API /orders → consumer REQ-061
REQ-042REQ-061conflictresolvedDR-014: обязательная авторизация; guest checkout de-scoped из R1
EXT-CRMREQ-042externalactiveКонтракт CRM, owner: команда integrations, ETA: 2026-09-15

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

Ограничения

  • Полный граф для большой системы дорог в сопровождении; обычно достаточно критичных, release-blocking и unresolved conflict связей.
  • В agile частые изменения устаревают статичную RTM без дисциплины в инструменте, DoR/DoD и сопровождения при split/merge ID.
  • Неформализованные зависимости (устные договорённости, soft без risk acceptance) не попадают в impact analysis.
  • Зависимости через организацию (другая команда, лицензия) плохо видны в SRS без явного типа external.
  • Tool links (blocks) не заменяют семантику: conflict и prerequisite требуют разных решений.
  • Temporal без prerequisite легко недооценить: story формально ready, но demo и release notes не сходятся.
  • NFR-зависимости (security/performance gate) часто живут только в NFR-документе, а не в графе REQ — см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.

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

ОшибкаПоследствиеКак избежать
Смешать логический и календарный critical pathНереалистичные даты или «готовые» stories без учёта ресурсовBA отдаёт логическую цепочку; PM накладывает календарь и параллелизм
Impact только «от owner», не от consumerПропуск изменений контракта при правке потребителяShared resource: обход в обе стороны (см. impact analysis)
Soft dependency без подписи architectStory в спринте с непринимаемой заглушкойDoR + эскалация PM при отказе architect
Circular dependencies без эскалацииБесконечный reworkWalkthrough; разрыв через scope, redesign или phased compromise
Игнор транзитивных цепочек«Готовый» REQ без скрытого prerequisitePrecedence review перед релизом/PI
Приоритизация без учёта графаStories без интеграцииЛогический critical path + precedence matrix
Перегруз RTM связями «для галочки»Потеря доверия к артефактуRisk-based: blocking, conflict, shared
Verification = только компонентStory «done», но непринимаемаУчитывать test data, feature flag, sandbox
External blocker без ownerСрыв сроковOwner, expected date, escalation — 08.05 Управление рисками на этапе анализа
Устаревшие рёбра после split/mergeЛожные blockers в спринтеОбновление графа при смене ID — 02.05.05 Жизненный цикл требования

Критерий зрелости: при структурном change (scope, контракт, split/merge) по одному REQ-ID за 15–30 минут BA и PM совместно называют зависимые и зависящие требования, затронутые тесты, unresolved conflict и блокеры релиза — без ручного поиска по чатам; для косметической правки текста достаточно короткого upstream/downstream на 1 hop. Проверка — на dependency review перед планированием или при значимом change. Если нет — карта связей декоративна.

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

Полный граф не цель. Цель — управляемые решения о порядке, scope и изменениях совместно с PM, без сюрпризов на интеграции и приёмке.

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

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

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

  • Karl Wiegers, Joy Beatty — Software Requirements, 3rd ed. (разделы о traceability links, dependency между требованиями и impact analysis при change)
  • ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering (управление изменениями, traceability, impact analysis): https://standards.ieee.org/standard/29148-2018.html
  • A Guide to the Business Analysis Body of Knowledge (BABOK Guide) — IIBA, задача Trace Requirements и сопровождение связей: https://www.iiba.org/standards-and-resources/babok/

Статьи и справочные материалы