Перейти к содержанию

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

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

Плотная глава: перед 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 закрытый список 12 типов 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 — по числу находок состязательного обзора, §7.4.1.4).

Допустимые типы требований: 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 подсистемы исключается из очередной версии комплекта (§6.5.4, §10.5.3), а его 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

# === Владение (mandatory) ===
# Собственного статуса и версии нет: артефакт утверждается в составе версии комплекта
# описания, его состояние производно от неё ([§10.7](10-lifecycle-qg.md#10.7)).
owner: "<role / responsible person>"

# === Измеримый бизнес-результат (conditional) ===
# Обязателен, если реализация объявила QG-4 ([§10.4.2](10-lifecycle-qg.md#10.4.2)):
# по нему QG-4 проверяет достижение результата. Без объявленного QG-4 поле
# опускается — приёмка бизнес-результата тогда не фиксируется ([§10.4.4](10-lifecycle-qg.md#10.4.4)). Полная схема вложенного
# блока — reference/02-schemas.md.
business-outcome:
  kpi-name: "<KPI>"
  measurement-method: "<как измеряется>"
  baseline-value: number
  target-value: number
  # измеренное значение и достижение — не здесь: BR утверждённой версии неизменяем (§10.5.1);
  # QG-4 записывает их в accepted-outcomes[] записи версии (§10.5.4)

# === 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: AR-NNN   # conditional: present если source.adapt отсутствует — AR с verdict «no findings» (§7.4.6)

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

# === Переиспользуемый компонент (conditional, §6.14) ===
assumptions: []                      # корневой BR компонента, путь C: закрытый для версии список A-NN (§6.14.2)
uses: []                             # корневой BR потребителя: подключённые компоненты (§6.14.4)

# === Граф связей (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>-<version>@<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
                                     # фиксируются в записи версии комплекта (§10.5.3, §10.5.4)
---

Поле 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: оно указывает на запись состязательного обзора AR (§7.4.6), хранящую этот вердикт для аудита. Hooks жизненного цикла (§7.4.1, §10.11.1) проверяют оба случая: (1) если source.adapt присутствует — что ADAPT в статусе approved или выше; (2) если source.adapt опущено — что source.adversarial-review-ref указывает на существующую AR в статусе issued с вердиктом no-findings.

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

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

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

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

6.5.4 Состояние BR — производное от версии комплекта

BR не имеет поля status. Его состояние выводится из принадлежности версиям комплекта описания (глава 10 §10.7):

Состояние Условие Что разрешено
черновик Присутствует только в черновике комплекта Правка автором
утверждён Входит в текущую утверждённую версию N.M — после QG-0 комплекта (§10.5.2) Постановка задач (TR) против версии; декомпозиция в SR допустима уже в черновике — BR и его SR утверждаются одной версией (§10.5.2)
исключён Отсутствует в текущей версии; запись версии несёт replaced-by при наличии замены (§10.5.3) Только чтение истории

«Верифицирован» и «принят» — свойства не BR, а пары (версия комплекта, версия продукта): верификация фиксируется записью в записи версии (QG-2, §10.3.3), приёмка бизнес-результата — accepted-outcomes[] (QG-4, §10.4.2, только при объявленном QG-4).

Исключённый BR не удаляется — остаётся в истории носителя (V1) как след для аудита.

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

# === Владение (mandatory) ===
# Собственного статуса и версии нет: артефакт утверждается в составе версии комплекта
# описания, его состояние производно от неё ([§10.7](10-lifecycle-qg.md#10.7)).
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: AR-NNN   # mandatory если adapt omitted (§7.4.6)

# === Характеристика качества (conditional) ===
# mandatory для нефункционального SR; значение — из перечня ISO/IEC 25010:2023
# (§14.4.3). Для функционального SR поле опускается.
quality-characteristic: functional-suitability | performance-efficiency | compatibility |
                        interaction-capability | reliability | security | maintainability |
                        flexibility | safety

# === Адресат обязательства (conditional, §6.14.3) ===
applies-to: self                     # self | consumer; только в SR компонента; по умолчанию self

# === Граф связей (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>-<version>@<date>"
  prompt-template: "<template-path>@<version>"
  context-tokens: integer
  output-tokens: integer
  human-edits: boolean

# === Замена (mandatory если применимо) ===
replaces: "<old-id>"                 # исключение прежнего артефакта и обратная ссылка replaced-by
                                     # фиксируются в записи версии комплекта (§10.5.3, §10.5.4)
---

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

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

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

6.6.3.1 Контролируемая форма утверждения (слот условия)

Оболочка требования нормирована подробно — frontmatter, рёбра графа, провенанс, гейты; само утверждение — нет, хотя агент, выводящий реализацию, читает утверждение, а не оболочку. Свободная проза допускает четыре дефекта, которых не видит ни один гейт: пропущенное предусловие, невыраженный триггер, необъявленное нежелательное поведение и склейку нескольких утверждений в одном предложении.

Утверждению SR следует принимать одну из шести форм. Модальность — рекомендательная: правило вводится на v1.1 с пересмотром по практике, поскольку прогонов на накопленном описании у него пока нет (§12.4 — тот же довод о правиле без данных).

Случай Форма
Постоянное требование Система должна ‹реакция›
Требование по состоянию Пока ‹состояние›, система должна ‹реакция›
Событийное требование Когда ‹триггер›, система должна ‹реакция›
Нежелательное поведение Если ‹условие›, то система должна ‹реакция›
Опциональная возможность При наличии ‹возможности› система должна ‹реакция›
Составное требование Пока ‹состояние›, когда ‹триггер›, система должна ‹реакция›

Маркер условия ставится первым словом предложения и пишется обычной русской орфографией. Опознаётся он позицией, а не начертанием: конвенция заглавных в русской прозе запрещена (reference/06 §2.1), а выделение полужирным этой конвенции не заменяет. Модальность «должна» остаётся строчной канонической — маркеры структурные, не модальные.

Три частности формы существенны:

  • «При наличии», а не «Где». Прямой перенос английского WHERE по-русски читается как вопрос о месте, тогда как смысл — «в конфигурациях, где возможность включена».
  • «то» обязательно. Без него «Если …, система должна» грамматически допустимо, но машинно неотличимо от условного придаточного в свободной прозе.
  • Одно утверждение — одно предложение. Форма не запрещает нескольких предложений в разделе, но каждое несёт ровно одно утверждение: склеенное верифицируется неделимо, и один TC доказывает половину.

Правило распространяется на SR и на утверждения type-specific разделов SPEC о поведении системы (§15.6.1); операторы, глоссарная дисциплина, запрещённые конструкции и атомарность — глава 15. У BR своя форма — «кто, что, зачем» (§6.5.3), для раздела «Ограничения» — формы бизнес-правил §15.6.2; у TR — Goal и критерии приёмки (§6.7.3); Pass/Fail-критерии TC нормируются главой 9.

Основа — шаблоны EARS (Mavin et al., RE'09), названные источником в reference/11.

6.6.4 Состояние SR — производное от версии комплекта

Идентично BR (§6.5.4): поля status нет; черновик / утверждён / исключён выводятся из принадлежности версиям комплекта (§10.7). Утверждение SR в составе версии требует, чтобы parent BR входил в ту же версию (§10.5.2). Верификация — свойство пары (версия комплекта, версия продукта): все verified-by TC прошли при last-run.set-version, равной верифицируемой версии (QG-2, §10.3.3).

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
  set-version: "N.M"                 # версия комплекта, против которой поставлена задача (§10.5.4; 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>-<version>@<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 при last-run.set-version = source.set-version
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[]:

Уровень Сценарий Правило
Обязательно BR.level = subsystem И scope.system имеет ≥ 1 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 входит в утверждённую версию комплекта своей системы (§10.11.1); target только в черновике — фатально.
  • Выявлять циклы цепочек implements; цикл — фатально.
  • При исключении 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: модуль получает бизнес-владельца. Нормативная последовательность:

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

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

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

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

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

  1. Утрата бизнес-владельца / переоценка бизнес-ценности фиксируется через обратную находку в ADAPT (категория scope; глава 7 §7.4.4).
  2. После approved delta-ADAPT — BR подсистемы исключается из очередной версии комплекта (§10.5.3) с указанием причины в записи версии (бизнес-владелец отозван / бизнес-ценность поглощена системой). BR не удаляется (immutable IDs, V1).
  3. SR подсистемы сохраняются (неизменяемые ID); поле parent SR обновляется атомарным изменением на BR родительской системы (или на BR другой подсистемы, если область SR относится к ней).
  4. Подсистема переименовывается в модуль на уровне области и схемы хранения (§6.11.2); существующие IDs SR / TR остаются неизменными.
  5. 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
                                          SPEC-TEST  SPEC-DOC
Ребро Тип Обязательность
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: AR-002
              ├─ source.tz-section: TZ-2026-001 §3.4   (нет ADAPT для этого ТЗ)
              │  source.adversarial-review-ref: AR-002
              ├─ 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 ведёт на запись состязательного обзора AR (§7.4.6), которая фиксирует, кем и когда было задекларировано «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) Версия комплекта (черновик → N.M) для BR / SR; TR (draft → approved) frontmatter валиден, обязательные поля и body заполнены, идентификатор уникален (V1); source.adapt, если присутствует, указывает на approved ADAPT, иначе присутствует source.adversarial-review-ref (BR / SR); parent входит в ту же версию (SR); на каждое утверждение, описывающее наблюдаемое поведение, — пара TC-норм (§9.7); состязательный обзор произведён; подпись Архитектора BR / SR входят в утверждённую версию N.M; разрешены декомпозиция и постановка задач; TR — approved
QG-2 (Verification) Версия комплекта × версия продукта (BR / SR); TR (approved → done) Все TC версии pass при last-run.set-version = N.M; красная история; обязательные виды TC по типам SPEC Запись верификации в записи версии (§10.5.4); TR — done

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

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

6.13 Требование, порождённое реализацией (implementation-originated)

6.13.1 Нормативное правило

Инверсия источника истины (§2.3.3) запрещает выводить требование из наблюдаемого поведения кода и подгонять SR под уже написанное. Запрет не ослабляется: он входит в MVR-1.

Но у запрета есть цена, которую он не должен взимать. AI-агент, реализуя задачу, штатно добавляет внутренние технические детали, которых нет в требованиях: защитную проверку входа, обработку граничного случая, журналирование. Требовать на каждую такую деталь delta-ADAPT с подписью клиента — абсурдная церемония, и именно она толкает к молчаливой подгонке требований задним числом.

Поэтому вводится узкий легальный класс: source: implementation-originated. Второй штатный источник кандидатов этого класса — находка ручного прохода (§9.20): поведение, увиденное человеком при проходе сценария и не описанное в комплекте, если по §6.13.2 оно не наблюдаемо клиентом.

6.13.2 Граница класса

Что Куда
Наблюдаемое клиентом поведение (влияет на приёмку: экран, поле, сообщение, срок, формат, объём поставки) Только через контрактный контур: ADAPT / ACTZ с подписями. Послаблений нет
Внутренняя техническая деталь без наблюдаемого клиентом поведения (защитная проверка, внутренняя валидация, журналирование, обработка граничного случая) Допустим source: implementation-originated

Граница определяется наблюдаемостью для клиента, а не размером правки. Сомнение трактуется в пользу контрактного контура.

6.13.3 Обязательная обвязка

Требование класса implementation-originated обязано нести:

  1. Провенанс: ссылку на единицу изменения реализации, которая его породила, и обоснование — почему функциональность признана нужной.
  2. Утверждение человека: явное одобрение Супервизора (человека, не агента). Агент не может легализовать собственную добавку.
  3. TC до слияния: покрывающий тест обязан существовать и проходить до включения изменения.
  4. Мутационную проверку (§9.18.2): у такого TC не может быть красной истории — он пишется после кода и рождается зелёным. Его зубастость доказывается убитым мутантом; без убитого мутанта TC доказательством не является.
  5. Счётчик в метриках дрейфа (§12.3): рост доли implementation-originated — сигнал, что процесс требований протекает, и он обязан быть виден.

6.13.4 Что остаётся запрещённым

  • Молчаливая правка существующего SR под наблюдаемое поведение кода — по-прежнему нарушение (§2.3.3, MVR-1). Класс implementation-originated легализует добавление внутренней детали с провенансом и подписью человека, а не переписывание нормы под факт.
  • Класс implementation-originated для наблюдаемого клиентом поведения — несоответствие: обязательство перед клиентом не может возникнуть из кода.

6.14 Переиспользуемый компонент

6.14.1 Компонент — система в собственном дереве

Артефакт, создаваемый не для одного заказчика, а для многократного применения (библиотека, платформа, внутренний движок), — система в собственном дереве (§6.8.2 — тот же прецедент, что подсистема как самостоятельный продукт), а не четвёртый уровень области. У компонента есть свой BR (§6.4: без бизнес-цели нет проекта), свои SR / SPEC / TC-нормы и свой комплект описания (§10.5). Сторону клиента у компонента даёт один из двух путей — оба допустимы, выбор определяется структурой организации, а не размером команды (§5.5.5):

Обозначения путей — из ADR-016, где путь A (четвёртый уровень области) отвергнут.

Путь Сторона клиента компонента Соответствие компонента
B — Владелец продукта компонента назначен внутри организации; подписи по общим правилам главы 5 самостоятельное
C — предполагаемая сторона компонент объявляет предположения о потребителе (§6.14.2); каждый потребитель подтверждает их при подключении (§6.14.4) условное: завершается подключением — компонент не вправе заявлять соответствие в одиночку, заявляет проект-потребитель

Внешний прототип пути C — элемент, разрабатываемый вне контекста конкретной системы (ISO 26262 SEooC): его требования выводятся из объявленных предположений о будущей системе, которые подтверждает интегратор.

6.14.2 Объявленные предположения

Корневой BR компонента (level: system) несёт закрытый для данной версии комплекта список assumptions[] — предположений о потребителе, на которые опираются его утверждения: что потребитель обеспечивает сам (например, централизованное хранение секретов), в какой среде компонент работает, какие обязательства принимает потребитель. Каждое предположение имеет неизменяемый идентификатор A-NN (V1), формулировку и указание, чем потребитель его подтверждает. Предположение — не обратная находка: у него нет адресата-клиента до подключения; оно оспоримо при состязательном обзоре (§7.10.2) — рецензент проверяет, не спрятано ли в предположениях то, что должно быть требованием.

6.14.3 Признак applies-to

Утверждение SR или SPEC компонента несёт признак applies-to: self | consumer (по умолчанию self):

  • self — обязательство самого компонента; доказывается его TC один раз, доказательство наследуется потребителями.
  • consumer — обязательство потребителя (как он обязан использовать компонент); у каждого потребителя покрывается статическим TC (automation.kind: static, §9.8.1) — новый тип TC не вводится. Красная история (§9.18.2) для такого TC достигается фиксирующим прогоном на заведомо нарушающей конфигурации: TC, рождённый зелёным, доказательством не является.

consumer-утверждения — дефицитный ресурс: каждое умножается на число потребителей и их зависимостей (транзитивное замыкание по графу uses), тогда как self-утверждение доказывается один раз. Наследуется только доказательство self-утверждений компонента; поведение приложения с компонентом не наследуется и доказывается TC потребителя.

6.14.4 Ребро uses

Потребитель подключает компонент типизированным ребром uses[] в своём корневом BR (level: system) — не parent-edge, запрет множественных родителей (§6.8.3) на него не распространяется:

uses:
  - component: "<system-id компонента>"
    set-version: "N.M"                 # версия комплекта компонента; обязательно (V5)
    assumptions-confirmed:             # каждое A-NN компонента — поимённо
      - { id: A-01, confirmed-by: "<участник>", confirmed-at: "<ISO-8601>" }

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

  1. Версия обязательна: ребро указывает утверждённую версию комплекта компонента (§10.5.4); без неё выпуск новой версии компонента молча менял бы смысл требований потребителя.
  2. Только чтение: дерево компонента для потребителя неизменяемо; расхождение — обратная находка в контуре потребителя или запрос к владельцу компонента.
  3. Подтверждение предположений: каждое A-NN версии компонента подтверждено поимённо стороной, отвечающей за описание потребителя (заинтересованная сторона либо ответственное лицо, §1.4.4); неподтверждённое предположение — версия комплекта потребителя не утверждается.
  4. Ацикличность графа uses; цикл — фатально.
  5. Локальность constrained-by[]: ссылки потребителя на артефакты компонента выражаются только через uses; цели в чужом дереве в constrained-by[] запрещены.
  6. Транзитивность: потребитель подтверждает предположения только прямых компонентов из своего uses[]; предположения компонентов, подключённых через них, подтверждает их непосредственный потребитель, и это подтверждение наследуется вместе с доказательством self-утверждений. consumer-обязательства всех компонентов в транзитивном замыкании uses потребитель обязан покрыть своими статическими TC (§6.14.3).
  7. Правило остановки: обнаружив несовместимость consumer-утверждений двух компонентов, подключённых одним потребителем, потребитель не утверждает версию комплекта, пока решение не принял человек; агент такую несовместимость не разрешает сам. Решение фиксируется в описании потребителя — изменением подключения (иная версия либо исключение компонента из uses[]) или, если затронуто наблюдаемое клиентом поведение, обратной находкой с контрактным исходом (§6.13.2). Носитель это правило не вычисляет: несовместимость утверждений устанавливает человек при состязательном обзоре (§7.10.2).
  8. Смена версии компонента: новая версия компонента для потребителя — изменение его собственного комплекта (set-version в ребре) с повторным подтверждением изменённых предположений; исключение артефакта компонента даёт потребителю предупреждение, не каскадное исключение (по образцу implements[], §6.8.2).

6.14.5 Что не вводится

Четвёртый уровень области, класс провенанса «порождено продуктом», отдельные типы «библиотека / фреймворк» и новый тип TC не вводятся: различие выражается признаком applies-to, версией комплекта и ребром uses. Ни один закрытый список §1.7.5 не расширяется; обязательные положения §13.3 не задеты.

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

Глава Связь
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
05 Роли Сторона клиента переиспользуемого компонента (§6.14.1): Владелец продукта компонента либо объявленные предположения, подтверждаемые потребителем; совмещение ролей — §5.5.5
10 Жизненный цикл и QG Цикл комплекта описания (§10.5): состояние BR / SR выводится из версии комплекта; QG-0 / QG-2 для оси требований (QG-1 — только для TC); точки контроля рёбер implements и uses (§10.11.1)
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