06. Иерархия требований¶

Часть RENAR Standard v1.0-draft · ← Оглавление

Плотная глава: перед frontmatter — guide/00 quickstart; плотность глав — reference/09.

6.1 Три типа требований и три уровня¶

У требования три высоты, и путать их нельзя. Бизнес хочет результата: «клиент сам восстанавливает пароль, чтобы разгрузить поддержку». Система должна вести себя так, чтобы этот результат стал возможен: «по запросу с подтверждённого адреса система отправляет ссылку сброса со сроком 30 минут». Инженер берёт это в работу одной задачей: «сделать сброс пароля с ограничением три попытки в час». Три разных вопроса — зачем, что и как именно, — и каждому RENAR даёт свой тип артефакта: BR, SR, TR.

Типов ровно три, список закрыт, и связаны они в дерево: один SR раскрывает один BR, одна TR — один SR. Сверху накладываются три уровня масштаба — система, подсистема, модуль; они определяют, какие из трёх типов вообще уместны (у модуля нет своего бизнес-владельца — значит, нет и BR). На этой оси держится вся иерархия источника истины из главы 2 §2.3: ТЗ → ADAPT → BR / SR / SPEC → TR → TC. Структура системы описывается параллельно — спецификациями SPEC-* (глава 8), на которые BR / SR / TR ссылаются через типизированные рёбра графа.

Положения главы нормативны. Закрытые списки типов и уровней — обязательные положения (глава 13); расширить их можно только формальной процедурой изменения стандарта.

Глава опирается на ISO/IEC/IEEE 29148:2018 «Requirements engineering» в части понятий business / system / task requirements и принципов traceability, но фиксирует закрытый список ровно из трёх типов оси требований v1.0 и явно отстраивается от свободно расширяемого набора типов, характерного для классических подходов.

6.2 Закрытый список трёх типов оси требований¶

6.2.1 Нормативная формулировка¶

Ось требований RENAR v1.0 содержит ровно три типа: BR, SR, TR. Список закрыт. Новые типы добавляются только через формальную процедуру изменения стандарта (глава 13).

Тип	Расшифровка	Вопрос	Содержит	Не содержит
BR	Business Requirement	Кто, что и зачем?	Бизнес-цель, роль, ценность	Технологии, экраны, контракты, поля данных
SR	System Requirement	Что делает система?	Поведение системы, ограничения	Имена таблиц, фреймворки, конкретные структуры
TR	Task Requirement	Что именно реализовать?	Конкретика реализации: поля, условия, ошибки	Архитектурные решения

6.2.2 Дерево родителей¶

BR
 └── SR              # parent = BR (единственный)
      └── TR         # parent = SR (единственный)
                ↓
          Goal + Acceptance Criteria
          в системе управления задачами

SR.parent — единственный BR. TR.parent — единственный SR. Это дерево, не граф; множественные родители на оси требований запрещены. Граф связей — между требованиями и спецификациями (§6.10).

6.2.3 Что не является типом оси требований¶

Артефакты, исторически встречавшиеся в проектах под именами UIC (UI Concept), AIC (AI Concept), INT-SR (интеграционное требование), TS (техническая спецификация), не являются типами оси требований в v1.0. Они перенесены в параллельную ось спецификаций как соответствующие типы SPEC (см. §8.3 закрытый список 9 типов SPEC и §8.7 миграция):

Legacy артефакт	RENAR v1.0 тип
UIC	SPEC-UI
AIC	SPEC-AI
INT-SR	SPEC-INT
TS (architecture / data / API / process / security / ops)	SPEC-ARCH / SPEC-DATA / SPEC-API / SPEC-PROC / SPEC-SEC / SPEC-OPS

SPEC-* связан с осью требований не как «ещё один тип требования», а как параллельная ось с типизированными рёбрами SR.constrained-by[] и TR.implements-spec[] (§6.10).

Тест-кейсы (TC) — отдельный класс артефактов верификации, нормируемый главой 9. TC не являются требованиями: они проверяют поведение, описанное в BR / SR / SPEC.

6.3 Системы, подсистемы, модули¶

Уровни организационной декомпозиции — закрытый список трёх элементов: система, подсистема, модуль. Каждому элементу соответствует допустимый набор типов требований (см. §6.4).

6.3.1 Система¶

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

Признаки системы:

единый владелец со стороны бизнеса (Владелец продукта, директор, заказчик);
поставляется и эксплуатируется как единое целое;
клиент видит и оценивает систему в целом, а не её части по отдельности;
единый верхнеуровневый ТЗ-документ и один корневой ADAPT.

Допустимые типы требований: BR, SR, TR.

6.3.2 Подсистема¶

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

Подсистема выделяется, если выполняется хотя бы одно из условий:

Условие	Пример
Своя команда или технический владелец	Команда фронтенда vs команда AI-pipeline
Отдельная база данных или независимо разворачиваемый сервис	Изолированный микросервис с отдельным деплоем
Возможность быть заменённой независимо от других	Аналитический модуль заменяется без изменения операционного контура
Другой бизнес-домен или отдельная заинтересованная сторона	Финансовый директор vs операционный директор
Добавляется позже как отдельная инициатива с отдельным бюджетом	Партнёрская программа

Ключевой нормативный критерий: существует ли отдельный человек со стороны бизнеса, отвечающий за ценность этой части системы? - да → подсистема, BR оправданы; - нет → модуль, только SR.

Допустимые типы требований: BR (если есть своя заинтересованная сторона) + SR + TR.

6.3.3 Модуль¶

Модуль — техническое деление внутри подсистемы. Реализует часть поведения подсистемы, но не имеет самостоятельной бизнес-ценности.

Признаки модуля:

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

Допустимые типы требований: SR + TR. BR не создаётся.

6.3.4 Сводная таблица¶

	Система	Подсистема	Модуль
Бизнес-заинтересованная сторона	да	да (свой)	нет
Независимое развёртывание	возможно	да	нет
Упоминается в ТЗ отдельно	да	да	редко
Существует отдельно	да	возможно	нет
BR	да	да (если своя заинтересованная сторона)	нет
SR	да	да	да
TR	да	да	да

6.3.5 Эволюция «модуль → подсистема»¶

Граница между модулем и подсистемой не является навечно зафиксированной. Если модуль вырос, получил собственную команду или бизнес-владельца — он становится подсистемой и получает BR. Нормативно: BR пишется в момент появления бизнес-владельца, не авансом.

Обратная эволюция (подсистема → модуль) — также допустима, если бизнес-владелец ушёл, бизнес-ценность стала производной; в этом случае BR подсистемы получает статус deprecated (§6.5.4), а его SR переподчиняются BR родительской системы.

6.4 Допустимые типы требований по уровням декомпозиции¶

Уровень	BR	SR	TR	Пояснение
Система	обязательно	обязательно	обязательно	Верхний BR — обязателен (без бизнес-цели нет проекта)
Подсистема	опционально	обязательно	обязательно	BR — только при наличии собственной заинтересованной стороны
Модуль	не допускается	обязательно	обязательно	BR запрещён нормативно

Нормативное обоснование запрета BR на уровне модуля: бизнес-требование без бизнес-заинтересованной стороны и без независимой бизнес-ценности приводит к ложной декомпозиции и порождает «технические BR», не отличимые от SR. Это размывает иерархию источника истины (глава 2 §2.3).

6.5 BR — Business Requirement¶

6.5.1 Нормативное определение¶

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

6.5.2 frontmatter BR (обязательные поля)¶

---
id: BR-NN                            # immutable; NN sequential в рамках scope
title: "<short, descriptive>"
type: BR
slug: "<kebab-case>"                 # auto-derived

# === Scope (mandatory) ===
level: system | subsystem            # BR на уровне модуля запрещён (§6.4)
scope:
  system: "<system-id>"
  subsystem: "<subsystem-id>"        # null если level=system

# === Lifecycle (mandatory) ===
status: draft | approved | verified | deprecated
owner: "<role / responsible person>"

# === Source: provenance (conditional, см. §7.4.1) ===
# source.adapt — mandatory если ADAPT существует (gap при конвертации ТЗ → RENAR обнаружен);
# source.tz-section — mandatory всегда. Минимум один источник всегда присутствует.
source:
  adapt: ADAPT-NNN                   # conditional: present если ADAPT создавался для этого ТЗ
  adapt-section: "Forward §N"        # mandatory если adapt present
  tz-section: "§N.N"                 # mandatory всегда — primary provenance
  adversarial-review-ref: "<нативная для носителя ссылка>"   # conditional: present если source.adapt отсутствует — evidence verdict «no findings» (§7.4.1.2)

# === Межуровневая связь BR подсистемы → BR системы (см. §6.8.2) ===
# Recommended на v1.0; mandatory на v1.1+ при level=subsystem И parent system имеет approved BR.
# Не parent-edge — отдельный тип ребра графа связей (см. §6.8.3).
implements:                          # массив; substrate-agnostic
  - id: BR-NN                        # ID BR родительской системы
    scope:
      system: "<system-id>"          # обязательно для cross-system ссылки
    rationale: "<short>"             # опционально; ссылка на ADAPT§ при наличии

# === Граф связей (auto-managed) ===
children: []                         # auto-derived; SR со ссылкой parent.id=<этот BR>
implemented-by: []                   # auto-derived; BR подсистем со ссылкой implements[].id=<этот BR>
verified-by: []                      # auto-derived; TC верифицирующие через SR

# === AI provenance (обязательно на RENAR-4+; canonical schema — §4.10.1) ===
ai-provenance:
  generated-by: "<vendor>-<model>@<date>"
  generated-at: "<ISO-8601>"
  prompt-template: "<template-path>@<version>"
  context-tokens: integer
  output-tokens: integer
  human-edits: boolean
  # optional на RENAR-4, обязательно на RENAR-5 (см. §4.10.1):
  # cost-budget, cost-actual, generation-time-ms

# === Замена (mandatory если применимо) ===
replaces: "<old-id>"
replaced-by: "<new-id>"
deprecated-date: "<ISO date>"
---

Поле source.tz-section обязательно всегда. Поле source.adapt — условное: оно присутствует, когда конвертация ТЗ → RENAR потребовала ADAPT (§7.4.1.1), и опускается, когда состязательный рецензент вынес вердикт «no findings, no clarifications» (§7.4.1.2). Если source.adapt опущено, обязательно поле source.adversarial-review-ref: оно хранит свидетельство этого вердикта для аудита. Hooks жизненного цикла (§7.4.1, §10.11.1) проверяют оба случая: (1) если source.adapt присутствует — что ADAPT в статусе approved или выше; (2) если source.adapt опущено — что source.adversarial-review-ref присутствует, а свидетельство доступно аудитору по запросу.

Поле parent отсутствует в BR: BR — корневой узел дерева требований. Для межуровневой связи между деревом подсистемы и деревом системы используется отдельное поле implements[] (см. §6.8.2): это не parent-edge, а типизированная межуровневая декларация «BR подсистемы раскрывает указанные BR системы». Запрет множественных parents (§6.8.3) на implements[] не распространяется.

6.5.3 Body BR (обязательные разделы)¶

Раздел	Обязательность	Содержание
Потребность	обязательно	Кто (роль), что (действие), зачем (бизнес-цель). Формулировка в одном предложении.
Критерии успеха	обязательно	Измеримые результаты (3–7 пунктов); каждый поддаётся независимой проверке.
Контекст	обязательно	Откуда взялось требование (со ссылкой на раздел ADAPT), какие альтернативы рассматривались.
Ограничения	опционально	Бизнес-ограничения (бюджет, сроки, регуляторика), не технические.

Технические детали (UI, API, схема данных) в BR запрещены — для этого существуют типы SPEC (глава 8) и SR.

6.5.4 Статусы BR¶

Статус	Смысл	Триггер перехода
`draft`	В проработке	Создаётся автором
`approved`	Утверждено, можно декомпозировать в SR	После QG-0 (глава 10)
`verified`	Все производные SR / TR / TC выполнены, бизнес-результат подтверждён	После QG-2; все `verified-by` TC имеют `last-run.result = pass` на текущей версии
`deprecated`	Устарело; заменено другим BR или утратило актуальность	Архитектором / Владельцем продукта, обязательно с `replaced-by` (если замена)

BR в статусе deprecated не удаляется — остаётся как исторический след для аудита.

6.6 SR — System Requirement¶

6.6.1 Нормативное определение¶

SR фиксирует что делает система (на уровне системы, подсистемы или модуля). Описывает наблюдаемое поведение и ограничения. Не описывает имена таблиц, фреймворков и конкретных структур данных — это ответственность SPEC (глава 8).

6.6.2 frontmatter SR (обязательные поля)¶

---
id: SR-NN                            # immutable
title: "<short, descriptive>"
type: SR
slug: "<kebab-case>"

# === Scope (mandatory) ===
level: system | subsystem | module
scope:
  system: "<system-id>"
  subsystem: "<subsystem-id>"        # null если level=system
  module: "<module-id>"              # null если level ≠ module

# === Lifecycle (mandatory) ===
status: draft | approved | verified | deprecated
owner: "<role / responsible person>"

# === Parent (mandatory) ===
parent:
  id: BR-NN                          # единственный родитель

# === Source: provenance (conditional, см. §7.4.1) ===
# Те же правила что для BR: source.adapt conditional; source.tz-section mandatory всегда;
# source.adversarial-review-ref mandatory если source.adapt omitted.
source:
  adapt: ADAPT-NNN                   # conditional
  adapt-section: "Forward §N"        # mandatory если adapt present
  tz-section: "§N.N"                 # mandatory всегда
  adversarial-review-ref: "<нативная для носителя ссылка>"   # mandatory если adapt omitted

# === Граф связей (mandatory ones + auto-managed) ===
constrained-by:                      # типизированные рёбра к SPEC (глава 8)
  - SPEC-UI-NN
  - SPEC-API-NN
  - SPEC-DATA-NN
children: []                         # auto-derived; TR со ссылкой parent.id=<этот SR>
verified-by: []                      # auto-derived; TC верифицирующие SR

# === AI provenance (обязательно на RENAR-4+) ===
ai-provenance:
  generated-by: "<vendor>-<model>@<date>"
  prompt-template: "<template-path>@<version>"
  context-tokens: integer
  output-tokens: integer
  human-edits: boolean

# === Замена (mandatory если применимо) ===
replaces: "<old-id>"
replaced-by: "<new-id>"
deprecated-date: "<ISO date>"
---

Ключевые поля. parent.id — единственный BR; это дерево родителей. constrained-by[] — типизированные ссылки на SPEC-; это граф*, не дерево. SR может ссылаться на произвольное количество SPEC любых типов; SPEC, в свою очередь, может быть referenced-by множеством SR (глава 8 §8.2).

6.6.3 Body SR (обязательные разделы)¶

Раздел	Обязательность	Содержание
Требование	обязательно	Одно предложение нормативной формы: «Система должна …» (модальность — по конвенции §0.5: «должна» / «обязана» = обязательно).
Поведение	обязательно	Детальное описание наблюдаемого поведения; функциональные сценарии.
Ограничения	обязательно если применимо	Нефункциональные ограничения (производительность, безопасность); полные ограничения — в `constrained-by[]` SPEC.
Связь с SPEC	обязательно если присутствует `constrained-by[]`	Краткое объяснение, какие аспекты поведения нормированы какими SPEC.

6.6.4 Статусы SR¶

Идентичны статусам BR (§6.5.4) — draft → approved → verified → deprecated. Переход approved → verified — после QG-2 (глава 10); требует, чтобы все verified-by TC имели last-run.result = pass на текущей версии SR.

6.7 TR — Task Requirement¶

6.7.1 Нормативное определение¶

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

6.7.2 frontmatter TR (обязательные поля)¶

---
id: TR-NN                            # immutable
title: "<short, descriptive>"
type: TR
slug: "<kebab-case>"

# === Scope (mandatory) ===
level: system | subsystem | module   # system — редко, кросс-подсистемные задачи
scope:
  system: "<system-id>"
  subsystem: "<subsystem-id>"        # null если level=system
  module: "<module-id>"              # null если level ≠ module

# === Lifecycle (mandatory) ===
status: draft | approved | done | obsolete
owner: "<assignee role / agent>"

# === Parent (mandatory) ===
parent:
  id: SR-NN                          # единственный родитель

# === Source: цепочка прослеживаемости (auto-derived from parent SR) ===
# TR не имеет собственного source — наследует от parent SR (§6.7.5).
# Если parent SR.source.adapt omitted (§7.4.1) — этот факт также наследуется.
source:
  adapt: ADAPT-NNN                   # auto-derived from parent SR; может быть omitted
  sr-version: "<version-ref>"        # pinning к версии SR (возможность носителя V5; глава 3)

# === Граф связей ===
implements-spec:                     # типизированные рёбра к SPEC
  - SPEC-API-NN
  - SPEC-UI-NN
verified-by: []                      # auto-derived; TC верифицирующие через SR

# === Goal + Acceptance Criteria ===
goal: "<one-sentence outcome>"
acceptance-criteria:
  - "<numbered, falsifiable, без двусмысленности>"
  - "..."

# === AI provenance (обязательно на RENAR-4+) ===
ai-provenance:
  generated-by: "<vendor>-<model>@<date>"
  human-edits: boolean
---

Ключевые поля. parent.id — единственный SR. implements-spec[] — типизированные рёбра к SPEC; конкретизирует, какие SPEC должны быть учтены при реализации именно этого TR (подмножество constrained-by[] родительского SR или его расширение типами SPEC, не указанными у SR прямо). acceptance-criteria — закрытый нумерованный список опровержимых утверждений.

6.7.3 Body TR (обязательные разделы)¶

Раздел	Обязательность	Содержание
Goal	обязательно	Один параграф; результат, который TR делает наблюдаемым.
Acceptance Criteria	обязательно	Нумерованный список; каждый пункт опровержим; покрывает положительные и отрицательные сценарии.
Scope	обязательно	Что входит / что не входит в TR (соответствует SENAR Rule 2).
Ссылки	обязательно если применимо	На SPEC из `implements-spec[]` и разделы родительского SR.

6.7.4 Статусы TR¶

Статус	Смысл	Триггер
`draft`	TR создан, AC ещё не финализированы	Авторство
`approved`	AC утверждены, разрешён старт работы	QG-0 (глава 10): goal + AC присутствуют
`done`	AC верифицированы, TC прошли	QG-2; `verified-by` TC `pass`
`obsolete`	TR утратил актуальность до завершения (например, SR изменился)	Архитектором, обязательно с пометкой

6.7.5 TR не ссылается на ADAPT напрямую¶

Исполнитель TR работает в рамках SR / SPEC и не обращается к ADAPT напрямую — все нужные интерпретации ТЗ уже зафиксированы в approved ADAPT и протянуты в SR / SPEC через source.adapt (глава 7 §7.7.3). Если исполнитель обнаружил неясность в SR — это сигнал либо для новой обратной находки в ADAPT (если корень неясности в ТЗ), либо для уточнения SR (если корень в декомпозиции).

6.8 Расширенная иерархия для составных систем¶

Базовая схема BR → SR → TR справедлива для большинства проектов. Для составных систем стандарт нормирует два варианта расширенной иерархии.

6.8.1 Подсистема — техническое деление, не самостоятельный продукт¶

BR относятся к системе в целом; подсистемы — техническое деление по командам, компонентам или другим архитектурным границам:

BR (система)
 └── SR (система)         # опционально, если есть кросс-подсистемные SR
      └── SR (подсистема)
           └── TR

SPEC-INT (между подсистемами)    # параллельная ось; см. главу 8

SPEC-INT не принадлежит ни одной из подсистем — это спецификация интеграции на уровне системы.

6.8.2 Подсистема — самостоятельный продукт со своей заинтересованной стороной¶

Подсистема имеет собственный BR со своим бизнес-владельцем:

BR (система)
 └┄┄ BR (подсистема)       # ┄┄ implements-edge (см. ниже), НЕ parent-edge
      └── SR (подсистема)
           └── TR

└┄┄ между BR (система) и BR (подсистема) обозначает типизированное межуровневое ребро implements (§6.5.2): BR подсистемы декларирует, какие BR родительской системы он раскрывает и реализует. Это не parent-edge дерева требований: BR (подсистема).parent остаётся отсутствующим, и каждая такая подсистема является корневым узлом своего дерева. implements — отдельный тип ребра графа связей, симметричный паре constrained-by[] ↔ referenced-by[] для SPEC (§6.10.2).

Нормативное правило implements[]:

Уровень	Сценарий	Правило
Recommended на v1.0 / обязательно на v1.1+	`BR.level = subsystem` И `scope.system` имеет ≥1 approved BR	`implements[]` обязан содержать ≥1 ссылку на applicable BR родительской системы
Permitted	`BR.level = subsystem` И родительская система — контейнер без собственных BR (охват организационного уровня)	`implements[]` опускается; обоснование фиксируется в разделе `Контекст` со ссылкой на ADAPT§
Запрещено	`BR.level = system`	`implements[]` не применяется (system BR — корень всей иерархии охвата)

Hooks жизненного цикла (глава 10 §10.11) обязаны:

Проверять существование target BR (по id + scope.system) при approve BR подсистемы.
Проверять, что target BR в статусе approved или выше; ошибочный draft target — фатально.
Выявлять циклы цепочек implements; цикл — фатально.
При deprecate target BR (§6.5.4) — генерировать cascade-warning для всех implemented-by[] (не cascade-deprecate; решение об эволюции зависимых BR — у Архитектора).

Машиночитаемая цепочка прослеживаемости в §6.8.2 восстанавливается через implements-ребро (§6.10.3) — асимметрия с §6.8.1 устраняется.

Связь подсистемы с общим ADAPT системы сохраняется через source.adapt (если применимо); implements[] и source.adapt — независимые поля и могут указывать на разные узлы графа.

6.8.3 Запрет множественных родителей¶

Стандарт не допускает множественное parent для SR или TR. Кросс-функциональные требования, которые могли бы выглядеть как «дочерние сразу двух SR», нормируются одним из двух способов:

разделяются на несколько SR, каждое с единственным parent BR;
декомпозируются в SR более высокого уровня (родительская подсистема или система), от которой эти кросс-функциональные сценарии и зависят.

Поле BR.implements[] (§6.5.2, §6.8.2) — не parent-edge и под действие §6.8.3 не подпадает: один BR подсистемы может раскрывать несколько BR системы (cardinality 0..N). Это сознательная разница типизации рёбер графа связей: parent — единственный, межуровневые декларации — множественные.

6.9 Эволюция иерархии¶

6.9.1 Модуль → подсистема¶

Сценарий из §6.3.5: модуль получает бизнес-владельца. Нормативная последовательность:

Появление бизнес-владельца фиксируется через обратную находку в ADAPT (категория scope — изменение границ работ; глава 7 §7.4.4).
После approved delta-ADAPT — модуль переводится в статус подсистемы; создаётся BR подсистемы с source.adapt: <delta-ADAPT>.
Существующие SR модуля сохраняются (неизменяемые ID); поле parent SR обновляется на новый BR подсистемы атомарным изменением.
TR / TC, ссылающиеся на эти SR, не требуют изменений (parent SR неизменен).

6.9.2 Запрет авансовой иерархии¶

Создание BR подсистемы «на вырост», без существующего бизнес-владельца — нарушение стандарта. BR без заинтересованной стороны превращается в «технический BR», размывающий инверсию источника истины и подменяющий собой SR. Hooks жизненного цикла (глава 10) обязаны блокировать переход BR в approved, если в ADAPT не зафиксирован выявленный бизнес-владелец.

6.9.3 Подсистема → модуль¶

Симметричный сценарий §6.3.5: подсистема утратила бизнес-владельца или бизнес-ценность стала производной от родительской системы. Нормативная последовательность:

Утрата бизнес-владельца / переоценка бизнес-ценности фиксируется через обратную находку в ADAPT (категория scope; глава 7 §7.4.4).
После approved delta-ADAPT — BR подсистемы переводится в статус deprecated с указанием причины в Контексте (бизнес-владелец отозван / бизнес-ценность поглощена системой). BR не удаляется (immutable IDs, V1).
SR подсистемы сохраняются (неизменяемые ID); поле parent SR обновляется атомарным изменением на BR родительской системы (или на BR другой подсистемы, если область SR относится к ней).
Подсистема переименовывается в модуль на уровне области и схемы хранения (§6.11.2); существующие IDs SR / TR остаются неизменными.
TR / TC, ссылающиеся на эти SR, не требуют изменений.

Если ни одна BR родительской системы не покрывает поведение SR — это сигнал того, что подсистема в действительности не утратила самостоятельную бизнес-ценность; обратная эволюция в этом случае невозможна, и BR подсистемы остаётся approved.

6.10 Связь иерархии с ADAPT и SPEC¶

Стандарт фиксирует связи между осью требований, ADAPT и параллельной осью SPEC через нормативные поля frontmatter и типизированные рёбра графа связей.

6.10.1 Связь с ADAPT¶

BR.source.adapt, SR.source.adapt, SPEC-*.source.adapt — условные ссылки на ADAPT, из которого артефакт был выведен (глава 7 §7.7.1): присутствуют, когда ADAPT создавался; при вердикте «no findings» ADAPT не существует, и вместо ссылки обязательно поле source.adversarial-review-ref (§7.4.1). TR не имеет прямого source.adapt — наследует его через parent SR (§6.7.5).

6.10.2 Граф связей с SPEC¶

Дерево требований (ось поведения):       Параллельная ось спецификаций:
BR
 └── SR  ──── constrained-by[] ─────►    SPEC-ARCH  SPEC-API  SPEC-DATA
      └── TR ─── implements-spec[] ──►   SPEC-INT   SPEC-PROC SPEC-UI
                                          SPEC-AI    SPEC-SEC  SPEC-OPS

Ребро	Тип	Обязательность
`SR.constrained-by[] → SPEC-*`	Граф (множественное)	Optional; присутствует при наличии нормирующих SPEC
`TR.implements-spec[] → SPEC-*`	Граф (множественное)	Optional; конкретизирует SPEC для исполнителя
`SPEC-*.referenced-by[] → SR / TR`	Auto-derived inverse	Авто-вычисляется нативной для носителя индексацией
`SPEC-.depends-on[] → SPEC-`	Граф между SPEC	См. глава 8 §8.2

Связь оси требований и оси SPEC — нормативная: ни один SR с нетривиальным поведением UI / API / данных не должен оставаться без constrained-by[] (отсутствие — сигнал либо для написания SPEC, либо для обоснования отсутствия в Контексте SR).

6.10.3 Полная цепочка прослеживаемости (read-side)¶

ADAPT — реактивный артефакт (§7.4.1): создаётся только когда конвертация ТЗ → RENAR порождает разрыв между языками. Цепочка прослеживаемости соответственно имеет два валидных варианта, выбираемых в зависимости от того, существует ли ADAPT для конкретного ТЗ.

Вариант A — когда ADAPT создавался (source.adapt present):

TC-NN  →  verifies SR-12 v1.4
              │
              ├─ parent:        BR-03 v2.0     (BR-03 — level: subsystem)
              │                     │
              │                     └─ implements: BR-01 (system), BR-05 (system)
              │                                       (типизированное межуровневое ребро §6.8.2)
              ├─ source.adapt:  ADAPT-001 §Forward §3.2
              │     └─ source-tz: TZ-2026-001 §3.4
              ├─ constrained-by: SPEC-UI-04, SPEC-API-02
              └─ children:      TR-101, TR-102, TR-103
                                    └─ implements-spec: SPEC-API-02
                                    └─ verified-by: TC-NN

Вариант B — когда ADAPT не создавался (source.adapt omitted; состязательный рецензент вынес «no findings» вердикт, §7.4.1.2):

TC-NN  →  verifies SR-12 v1.4
              │
              ├─ parent:        BR-03 v2.0     (BR-03 — level: subsystem)
              │                     │
              │                     ├─ implements: BR-01 (system), BR-05 (system)
              │                     └─ source.tz-section: TZ-2026-001 §3.4
              │                        source.adversarial-review-ref: <verdict evidence ref>
              ├─ source.tz-section: TZ-2026-001 §3.4   (нет ADAPT для этого ТЗ)
              │  source.adversarial-review-ref: <verdict evidence ref>
              ├─ constrained-by: SPEC-UI-04, SPEC-API-02
              └─ children:      TR-101, TR-102, TR-103
                                    └─ implements-spec: SPEC-API-02
                                    └─ verified-by: TC-NN

Оба варианта машиночитаемы. В варианте B путь восстанавливается через source.tz-section напрямую; свидетельство adversarial-review-ref фиксирует, кем и когда было задекларировано «no findings» (V6 author + timestamp), и доступно по запросу аудитора (§13.5).

Для сценария «подсистема — самостоятельный продукт» (§6.8.2) цепочка в обоих вариантах содержит ребро implements между BR подсистемы и BR родительской системы — это восстанавливает машиночитаемую прослеживаемость, симметричную сценарию §6.8.1.

Дезавуированный ADAPT в цепочка прослеживаемости. Когда ADAPT переходит в superseded (§7.6.4, §10.8.5), все производные BR / SR / SPEC с source.adapt на него обязаны быть либо перенаправлены на дезавуирующий ADAPT, либо пере-выведены. Висячая ссылка source.adapt на ADAPT в статусе superseded делает цепочку прослеживаемости невалидной (read-side): аудит не должен приводить к дезавуированному источнику интерпретации как к действующему. Сам superseded ADAPT сохраняется для аудита (V1) и достижим по ребру superseded-by от дезавуирующего ADAPT — но не как source.adapt действующего требования. Обеспечение соблюдения — adapt-supersession validation (§10.11.1).

6.11 Схема хранения¶

Требования хранятся в подпапках носителя требований. Нативная для носителя реализация хранения специфична для носителя (см. guide/03 для distributed VCS; guide/04 для document-oriented store).

6.11.1 На уровне системы¶

[requirements-substrate]/        # корень носителя требований (layout — guide/03 или guide/04)
  br/                            # BR-NN-*.md
  sr/                            # SR-NN-*.md, level=system
  tr/                            # TR-NN-*.md, level=system (редко)
  specs/                         # SPEC-* (глава 8)
  adapt/                         # ADAPT (глава 7)
  tz/                            # immutable исходники ТЗ
  REQUIREMENTS.md                # auto-generated index

6.11.2 На уровне подсистемы / модуля¶

[subsystem-substrate]/           # scope подсистемы внутри носителя требований
  br/                            # если у подсистемы своя заинтересованная сторона
  sr/
  tr/
  modules/
    [module-substrate]/
      sr/                        # модуль имеет только SR + TR
      tr/
  specs/                         # глава 8
  adapt/
  REQUIREMENTS.md

6.11.3 REQUIREMENTS.md — auto-generated index¶

REQUIREMENTS.md — auto-generated реестр всех BR / SR / TR в области: ID, тип, уровень, заголовок, статус, parent, ссылка на файл. Помечается нативным для носителя флагом auto-generated. Триггеры перегенерации — каждое изменение frontmatter или каждый approve / verify gate (глава 10).

6.12 Контрольные точки качества для оси требований¶

Детальные определения gates — в главе 10. Краткая сводка для BR / SR / TR:

Gate	Применим к	Предусловие	Постусловие
QG-0 (Approval)	BR / SR / TR (`draft → approved`)	frontmatter валиден, обязательные поля заполнены, идентификатор уникален (V1); `source.adapt`, если присутствует, указывает на approved ADAPT, иначе присутствует `source.adversarial-review-ref` (BR / SR); `parent` указывает на approved BR / SR (SR); body разделы соответствуют §6.5.3 / §6.6.3; состязательный обзор произведён	Артефакт переведён в `approved`; immutable до версии следующего change; разрешена декомпозиция в дочерние артефакты
QG-2 (Verification)	BR / SR / TR (`approved → verified` / `done`)	Все `verified-by` TC `pass` на текущей версии артефакта	Артефакт `verified` (BR/SR) или `done` (TR); цепочка до родительского BR — обновляется к verified, если все дети verified

QG-1 (Implementation) к оси требований не применяется: это отдельный gate только для TC (§10.3.2) — промежуточного «QG-1 implementation» для BR / SR / TR не существует, переход approved → verified / done управляется единым QG-2. TR переходит draft → approved тем же QG-0 единым шагом (frontmatter + goal + AC). ready и аналогичные термины — не статусы оси требований и не присутствуют в машине состояний draft → approved → verified | done | obsolete | deprecated (см. §6.5.4 / §6.6.4 / §6.7.4).

Hooks носителя (глава 3 §3.3) обязаны блокировать переходы, нарушающие предусловие соответствующего гейта.

6.13 Связь с другими главами¶

Глава	Связь
02 Положение в типологии методологий	Иерархия BR / SR / TR — несущая структура инверсии источника истины (Утверждение 1); waterfall-форма (Утверждение 2) задаёт слои BR → SR → TR
07 ADAPT	`BR.source.adapt`, `SR.source.adapt` — условные (при отсутствии ADAPT — `source.adversarial-review-ref`); ось требований выводится из approved ADAPT либо напрямую из ТЗ при вердикте «no findings»
08 Specifications	Параллельная ось SPEC; `SR.constrained-by[]`, `TR.implements-spec[]` — типизированные рёбра графа
09 Test cases	TC верифицируют BR / SR / TR; `verified-by[]` — auto-derived inverse
10 Жизненный цикл и QG	Машины состояний BR / SR / TR; QG-0 / QG-2 для оси требований (QG-1 — только для TC)
03 Версионирование носителя	Неизменяемые ID (V1); atomic change unit при переподчинении (V2); diff & review для approve (V3); версионирование без потери истории (V4); pinning SR-version в TR (V5); нативная для носителя подпись approve с author + timestamp (V6)
11 Maturity model	RENAR-1: ось BR / SR / TR обязательна; RENAR-3+: `constrained-by[]` для всех SR, где применимо
13 Соответствие	Закрытый список типов (BR / SR / TR) — обязательное положение v1.0; закрытый список уровней (система / подсистема / модуль) — обязательное положение v1.0
reference/02 — schemas	Полная машиночитаемая schema BR / SR / TR frontmatter