06. Иерархия требований
Часть RENAR Standard v1.0-draft · ← Оглавление
6.1 Назначение главы
Глава нормирует ось требований RENAR — closed list трёх типов (BR, SR, TR) и три уровня организационной декомпозиции (система, подсистема, модуль). На этих понятиях держится Source of Truth-иерархия из главы 05 §5.3: ТЗ → ADAPT → BR / SR / SPEC → TR → TC. Параллельная ось спецификаций SPEC-* нормирована в главе 08; BR / SR / TR ссылаются на SPEC через типизированные рёбра графа связей.
Положения главы являются нормативными. Закрытые списки типов и уровней — mandatory clauses RENAR conformance (глава 14); расширение возможно только через formal change procedure стандарта.
Глава опирается на ISO/IEC/IEEE 29148:2018 «Requirements engineering» в части понятий business / system / task requirements и принципов traceability, но фиксирует closed list ровно из трёх типов оси требований v1.0 и явно отстраивается от свободно расширяемого набора типов, характерного для классических подходов.
6.2 Закрытый список трёх типов оси требований
6.2.1 Нормативная формулировка
Ось требований RENAR v1.0 содержит ровно три типа: BR, SR, TR. Список закрыт. Новые типы добавляются только через formal change procedure стандарта (глава 14).
| Тип | Расшифровка | Вопрос | Содержит | Не содержит |
|---|---|---|---|---|
| BR | Business Requirement | Кто, что и зачем? | Бизнес-цель, роль, ценность | Технологии, экраны, контракты, поля данных |
| SR | System Requirement | Что делает система? | Поведение системы, ограничения | Имена таблиц, фреймворки, конкретные структуры |
| TR | Task Requirement | Что именно реализовать? | Конкретика реализации: поля, условия, ошибки | Архитектурные решения |
Каждый тип отвечает на свой вопрос и принадлежит своему слою waterfall-формы стандарта (глава 05 §5.4).
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 closed list 9 типов SPEC и §8.7 migration):
| 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) — отдельный класс артефактов верификации, нормируемый главой 09. TC не являются требованиями: они проверяют поведение, описанное в BR / SR / SPEC.
6.3 Системы, подсистемы, модули
Уровни организационной декомпозиции — closed list трёх элементов: система, подсистема, модуль. Каждому элементу соответствует допустимый набор типов требований (см. §6.4).
6.3.1 Система
Система — верхний уровень иерархии. Целостный продукт или платформа, которая поставляется и эксплуатируется как единое целое и за которую отвечает организация.
Признаки системы:
- единый владелец со стороны бизнеса (Product Owner, директор, заказчик);
- поставляется и эксплуатируется как единое целое;
- клиент видит и оценивает систему в целом, а не её части по отдельности;
- единый верхнеуровневый ТЗ-документ и один корневой ADAPT.
Допустимые типы требований: BR, SR, TR.
6.3.2 Подсистема
Подсистема — крупный самостоятельный компонент системы, обладающий собственной бизнес-ценностью или отдельным бизнес-владельцем.
Подсистема выделяется, если выполняется хотя бы одно из условий:
| Условие | Пример |
|---|---|
| Своя команда или технический владелец | Команда фронтенда vs команда AI-пайплайна |
| Отдельная база данных или независимо разворачиваемый сервис | Изолированный микросервис с отдельным деплоем |
| Возможность быть заменённой независимо от других | Аналитический модуль заменяется без изменения операционного контура |
| Другой бизнес-домен или отдельный стейкхолдер | Финансовый директор 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 | Пояснение |
|---|---|---|---|---|
| Система | mandatory | mandatory | mandatory | Верхний BR — обязателен (без бизнес-цели нет проекта) |
| Подсистема | optional | mandatory | mandatory | BR — только при наличии собственного стейкхолдера |
| Модуль | not allowed | mandatory | mandatory | BR запрещён нормативно |
Нормативное обоснование запрета BR на уровне модуля: бизнес-требование без бизнес-стейкхолдера и без независимой бизнес-ценности приводит к ложной декомпозиции и порождает «технические BR», не отличимые от SR. Это размывает SoT-иерархию (глава 05 §5.3).
6.5 BR — Business Requirement
6.5.1 Нормативное определение
BR фиксирует что нужно бизнесу и зачем. Описывает роль, действие и бизнес-ценность без отсылок к технологиям, экранам, контрактам, структурам данных.
6.5.2 Frontmatter BR (mandatory поля)
---
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 from ADAPT (mandatory) ===
source:
adapt: ADAPT-NNN # ссылка на ADAPT (глава 07)
adapt-section: "Forward §N" # canonical интерпретация
tz-section: "§N.N" # optional, для traceability
# === Граф связей (auto-managed) ===
children: [] # auto-derived; SR со ссылкой parent.id=<этот BR>
verified-by: [] # auto-derived; TC верифицирующие через SR
# === AI provenance (mandatory на RENAR-4+; см. глава 12) ===
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>"
---Поле source.adapt — нормативно обязательное. Производство BR без ссылки на approved ADAPT — нарушение стандарта; hooks lifecycle (глава 07 §7.4.1) обязаны блокировать создание BR с source.adapt на ADAPT в статусе ниже approved.
Поле parent отсутствует в BR: BR — корневой узел дерева требований.
6.5.3 Body BR (обязательные разделы)
| Раздел | Обязательность | Содержание |
|---|---|---|
| Потребность | mandatory | Кто (роль), что (действие), зачем (бизнес-цель). Формулировка в одном предложении. |
| Критерии успеха | mandatory | Измеримые результаты (3–7 пунктов); каждый поддаётся независимой проверке. |
| Контекст | mandatory | Откуда взялось требование (со ссылкой на раздел ADAPT), какие альтернативы рассматривались. |
| Ограничения | optional | Бизнес-ограничения (бюджет, сроки, регуляторика), не технические. |
Технические детали (UI, API, схема данных) в BR запрещены — для этого существуют типы SPEC (глава 08) и SR.
6.5.4 Статусы BR
| Статус | Смысл | Триггер перехода |
|---|---|---|
draft | В проработке | Создаётся автором |
approved | Утверждено, можно декомпозировать в SR | После QG-1 (глава 10) |
verified | Все производные SR / TR / TC выполнены, бизнес-результат подтверждён | После QG-2; все verified-by TC имеют last-run.result = pass на текущей версии |
deprecated | Устарело; заменено другим BR или утратило актуальность | Архитектором / Product Owner, обязательно с replaced-by (если замена) |
BR в статусе deprecated не удаляется — остаётся как исторический след для аудита.
6.6 SR — System Requirement
6.6.1 Нормативное определение
SR фиксирует что делает система (на уровне системы, подсистемы или модуля). Описывает наблюдаемое поведение и ограничения. Не описывает имена таблиц, фреймворков и конкретных структур данных — это ответственность SPEC (глава 08).
6.6.2 Frontmatter SR (mandatory поля)
---
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 from ADAPT (mandatory) ===
source:
adapt: ADAPT-NNN
adapt-section: "Forward §N"
tz-section: "§N.N" # optional
# === Граф связей (mandatory ones + auto-managed) ===
constrained-by: # типизированные рёбра к SPEC (глава 08)
- SPEC-UI-NN
- SPEC-API-NN
- SPEC-DATA-NN
children: [] # auto-derived; TR со ссылкой parent.id=<этот SR>
verified-by: [] # auto-derived; TC верифицирующие SR
# === AI provenance (mandatory на 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 (глава 08 §8.2).
6.6.3 Body SR (обязательные разделы)
| Раздел | Обязательность | Содержание |
|---|---|---|
| Требование | mandatory | Одно предложение нормативной формы: «Система обязана …». |
| Поведение | mandatory | Детальное описание наблюдаемого поведения; функциональные сценарии. |
| Ограничения | mandatory если применимо | Нефункциональные ограничения (производительность, безопасность); полные ограничения — в constrained-by[] SPEC. |
| Связь с SPEC | mandatory если присутствует 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 (mandatory поля)
---
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: trace chain (auto-derived) ===
source:
adapt: ADAPT-NNN # auto-derived from parent SR
sr-version: "<version-ref>" # pinning к версии SR (V5 substrate capability; глава 11)
# === Граф связей ===
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 (mandatory на 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 — закрытый numbered список falsifiable утверждений.
6.7.3 Body TR (обязательные разделы)
| Раздел | Обязательность | Содержание |
|---|---|---|
| Goal | mandatory | Один параграф; результат, который TR делает наблюдаемым. |
| Acceptance Criteria | mandatory | Numbered list; каждый пункт falsifiable; покрывает positive и negative сценарии. |
| Scope | mandatory | Что входит / что не входит в TR (соответствует SENAR Rule 2). |
| Ссылки | mandatory если применимо | На 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 (глава 07 §7.7.3). Если исполнитель обнаружил неясность в SR — это сигнал либо для нового backward finding в ADAPT (если корень неясности в ТЗ), либо для уточнения SR (если корень в декомпозиции).
6.8 Расширенная иерархия для составных систем
Базовая схема BR → SR → TR справедлива для большинства проектов. Для составных систем стандарт нормирует два варианта расширенной иерархии.
6.8.1 Подсистема — техническое деление, не самостоятельный продукт
BR относятся к системе в целом; подсистемы — техническое деление по командам или сервисам:
BR (система)
└── SR (система) # опционально, если есть кросс-подсистемные SR
└── SR (подсистема)
└── TR
SPEC-INT (между подсистемами) # параллельная ось; см. главу 08SPEC-INT не принадлежит ни одной из подсистем — это спецификация интеграции на уровне системы.
6.8.2 Подсистема — самостоятельный продукт со своим стейкхолдером
Подсистема имеет собственный BR со своим бизнес-владельцем:
BR (система)
└┄┄ BR (подсистема) # ┄┄ = scope containment, НЕ parent-edge
└── SR (подсистема)
└── TR└┄┄ между BR (система) и BR (подсистема) обозначает принадлежность подсистемы к scope системы, не parent-edge дерева требований. BR (подсистема).parent отсутствует — каждая такая подсистема является корневым узлом своего дерева требований (как и BR системы). Связь между деревьями системы и подсистемы — через раздел Контекст BR подсистемы и через общий ADAPT системы.
6.8.3 Запрет множественных родителей
Стандарт не допускает множественное parent для SR или TR. Кросс-функциональные требования, которые могли бы выглядеть как «дочерние сразу двух SR», нормируются одним из двух способов:
- разделяются на несколько SR, каждое с единственным parent BR;
- декомпозируются в SR более высокого уровня (родительская подсистема или система), от которой эти кросс-функциональные сценарии и зависят.
6.9 Эволюция иерархии
6.9.1 Модуль → подсистема
Сценарий из §6.3.5: модуль получает бизнес-владельца. Нормативная последовательность:
- Появление бизнес-владельца фиксируется через backward finding в ADAPT (категория
scope— изменение границ работ; глава 07 §7.4.4). - После approved delta-ADAPT — модуль переводится в статус подсистемы; создаётся BR подсистемы с
source.adapt: <delta-ADAPT>. - Существующие SR модуля сохраняются (immutable IDs); поле
parentSR обновляется на новый BR подсистемы атомарным изменением. - TR / TC, ссылающиеся на эти SR, не требуют изменений (parent SR неизменен).
6.9.2 Запрет авансовой иерархии
Создание BR подсистемы «на вырост», без существующего бизнес-владельца — нарушение стандарта. BR без стейкхолдера превращается в «технический BR», размывающий SoT-инверсию и подменяющий собой SR. Hooks lifecycle (глава 10) обязаны блокировать переход BR в approved, если в ADAPT не зафиксирован identified бизнес-владелец.
6.9.3 Подсистема → модуль
Симметричный сценарий §6.3.5: подсистема утратила бизнес-владельца или бизнес-ценность стала производной от родительской системы. Нормативная последовательность:
- Утрата бизнес-владельца / переоценка бизнес-ценности фиксируется через backward finding в ADAPT (категория
scope; глава 07 §7.4.4). - После approved delta-ADAPT — BR подсистемы переводится в статус
deprecatedс указанием причины вКонтексте(бизнес-владелец отозван / бизнес-ценность поглощена системой). BR не удаляется (immutable IDs, V1). - SR подсистемы сохраняются (immutable IDs); поле
parentSR обновляется атомарным изменением на BR родительской системы (или на BR другой подсистемы, если scope SR относится к ней). - Подсистема переименовывается в модуль на уровне scope и storage layout (§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 — mandatory ссылки на ADAPT, из которого артефакт был выведен (глава 07 §7.7.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 | Авто-вычисляется substrate-нативной индексацией |
SPEC-*.depends-on[] → SPEC-* | Граф между SPEC | См. глава 08 §8.2 |
Связь оси требований и оси SPEC — нормативная: ни один SR с нетривиальным UI / API / data behavior не должен оставаться без constrained-by[] (отсутствие — сигнал либо для написания SPEC, либо для обоснования отсутствия в Контексте SR).
6.10.3 Полная trace chain (read-side)
TC-NN → verifies SR-12 v1.4
│
├─ parent: BR-03 v2.0
├─ source.adapt: ADAPT-001 §Forward §3.2
├─ constrained-by: SPEC-UI-04, SPEC-API-02
└─ children: TR-101, TR-102, TR-103
└─ implements-spec: SPEC-API-02
└─ verified-by: TC-NNПри аудите от любого артефакта (TC / TR / SR / SPEC) восстанавливается полная цепочка до раздела ТЗ через approved ADAPT.
6.11 Storage layout
Требования хранятся в подпапках requirements substrate. Substrate-нативная реализация storage — substrate-specific (см. guide/03 для distributed VCS; guide/04 для document-oriented store).
6.11.1 На уровне системы
[system].req/
br/ # BR-NN-*.md
sr/ # SR-NN-*.md, level=system
tr/ # TR-NN-*.md, level=system (редко)
specs/ # SPEC-* (глава 08)
adapt/ # ADAPT (глава 07)
tz/ # immutable исходники ТЗ
REQUIREMENTS.md # auto-generated index6.11.2 На уровне подсистемы / модуля
[subsystem].req/
br/ # если у подсистемы свой стейкхолдер
sr/
tr/
modules/
[module].req/
sr/ # модуль имеет только SR + TR
tr/
specs/ # глава 08
adapt/
REQUIREMENTS.md6.11.3 REQUIREMENTS.md — auto-generated index
REQUIREMENTS.md — auto-generated реестр всех BR / SR / TR в scope: ID, тип, уровень, заголовок, статус, parent, ссылка на файл. Помечается substrate-нативным флагом auto-generated. Триггеры перегенерации — каждое изменение frontmatter или каждый approve / verify gate (глава 10).
6.12 Quality Gates для оси требований
Детальные определения gates — в главе 10. Краткая сводка для BR / SR / TR:
| Gate | Применим к | Pre-condition | Post-condition |
|---|---|---|---|
| QG-0 | BR / SR / TR (внутри draft) | frontmatter присутствует, mandatory fields заполнены | source.adapt указывает на approved ADAPT (для BR / SR); parent указывает на approved BR / SR; артефакт считается qg0-passed, но статус остаётся draft |
| QG-1 | BR / SR (draft → approved) | QG-0 пройден; body разделы соответствуют §6.5.3 / §6.6.3 | Артефакт переведён в approved; immutable до версии следующего change; разрешена декомпозиция в дочерние артефакты |
| QG-2 | BR / SR / TR (approved → verified / done) | Все verified-by TC pass на текущей версии артефакта | Артефакт verified (BR/SR) или done (TR); цепочка до родительского BR — обновляется к verified, если все дети verified |
QG-0 и QG-1 для TR совмещены: TR переходит из draft в approved единым шагом после успешного прохождения обеих pre-condition (frontmatter + goal + AC). ready и аналогичные термины — не статусы и не присутствуют в state machine draft → approved → verified | done | obsolete | deprecated (см. §6.5.4 / §6.6.4 / §6.7.4).
Hooks substrate (глава 11 §11.3) обязаны блокировать переходы, нарушающие pre-condition.
6.13 Связь с другими главами
| Глава | Связь |
|---|---|
| 05 Положение в типологии методологий | Иерархия BR / SR / TR — несущая структура SoT-инверсии (Утверждение 1); waterfall-форма (Утверждение 2) задаёт слои BR → SR → TR |
| 07 ADAPT | BR.source.adapt, SR.source.adapt — mandatory; ось требований выводится только из approved ADAPT |
| 08 Specifications | Параллельная ось SPEC; SR.constrained-by[], TR.implements-spec[] — типизированные рёбра графа |
| 09 Test cases | TC верифицируют BR / SR / TR; verified-by[] — auto-derived inverse |
| 10 Lifecycle и QG | State machines BR / SR / TR; QG-0 / QG-1 / QG-2 для оси требований |
| 11 Substrate versioning | Immutable IDs (V1); atomic change unit при переподчинении (V2); diff & review для approve (V3); версионирование без потери истории (V4); pinning SR-version в TR (V5); substrate-нативная подпись approve с author + timestamp (V6) |
| 12 Maturity model | RENAR-1: ось BR / SR / TR обязательна; RENAR-3+: constrained-by[] для всех SR, где применимо |
| 14 Conformance | Closed list типов (BR / SR / TR) — mandatory clause v1.0; closed list уровней (система / подсистема / модуль) — mandatory clause v1.0 |
| reference/02 — schemas | Полная machine-readable schema BR / SR / TR frontmatter |