12. Maturity model
Часть RENAR Standard v1.0-draft · ← Оглавление
12.1 Назначение главы
Глава нормирует закрытый список уровней зрелости RENAR — пять уровней RENAR-1..RENAR-5, каждый с явно определёнными нормативными критериями. Уровень — это измеримая характеристика проекта в области управления требованиями, не сам по себе conformance claim (механика conformance machinery — глава 14).
Глава фиксирует:
- Позиционирование RENAR-M как domain-specific dimension в общей SENAR maturity (§12.2) — проект характеризуется парой
(SENAR-N, RENAR-M). - Closed list RENAR-1..5 (§12.3) — добавление новых уровней только через formal change procedure (§14.9).
- Нормативные определения каждого уровня (§12.4–§12.8) — что обязано быть в substrate проекта; observable signals (как уровень проверяем со стороны); привязка к QG enforcement и mandatory clauses главы 14.
- Сравнительная таблица признаков (§12.9) — exhaustive matrix атрибутов по уровням.
- Минимальный entry-level (§12.10) —
RENAR-1как нижняя граница conformance manifest. - Path RENAR-1 → RENAR-5 (§12.11) — нормативные шаги transitions с ожидаемым порядком времени.
- Связь с SENAR ADR (§12.12) — Adversarial Detection Rate по уровням.
- Связь с другими главами (§12.13).
Глава не определяет conformance procedures — это глава 14. Глава не определяет метрики измерения уровня — это глава 13. Глава не определяет substrate capabilities — это глава 11. Глава фиксирует только уровневые критерии и transitions.
12.2 RENAR-M как domain-specific dimension в SENAR maturity
12.2.1 SENAR maturity (общая зрелость)
SENAR определяет одномерную модель из пяти уровней общей зрелости команды и методологии: Стихийный → Супервизируемый → Измеримый → Управляемый → Оптимизирующий. Эта модель оценивает процессную зрелость команды в целом независимо от конкретной process area.
12.2.2 RENAR-M как отдельная размерность
RENAR-M — отдельная размерность в общей SENAR maturity, специализирующая её для process area «requirements engineering». Проект характеризуется парой:
проект ──▶ (SENAR-N, RENAR-M)
где N ∈ {1, 2, 3, 4, 5} — общая SENAR зрелость
M ∈ {1, 2, 3, 4, 5} — RENAR-уровень управления требованиямиПары (SENAR-N, RENAR-M) нормативно независимы: проект на SENAR-4 (Управляемый) может находиться на RENAR-2 (Documented) — команда зрелая в SENAR-практиках в целом, но именно requirements management формализован слабо. Это допустимый и наблюдаемый сценарий.
12.2.3 Согласованность с SENAR Reference
SENAR Reference допускает domain-specific maturity dimensions (auth, security, observability и иные process areas). RENAR-M — одно из таких domain-specific измерений; не противоречит SENAR и не дублирует его.
Аналог в индустрии — CMMI capability levels per process area: REQM (Requirements Management) и Verification могут находиться на разных capability levels внутри одной organisation. RENAR-M — нормативная capability dimension для process area «Requirements Engineering».
12.2.4 Конформанс как пара
Conformance manifest (§14.4) фиксирует только RENAR-M (level поле). SENAR-N остаётся в области SENAR conformance и не дублируется в RENAR manifest.
12.3 Closed list уровней RENAR-1..RENAR-5
Закрытый список из пяти уровней. Изменение списка — только через formal change procedure стандарта (§14.9.3).
| Уровень | Краткое название | Семантика (одной строкой) |
|---|---|---|
RENAR-1 | Ad-hoc | Requirements substrate существует; артефакты ведутся без формального schema и lifecycle |
RENAR-2 | Documented | Артефакты имеют базовый frontmatter и хранятся структурно; ТЗ зафиксировано |
RENAR-3 | Tracked | Full frontmatter schema; lifecycle статусы используются; delta-ТЗ workflow через ADAPT |
RENAR-4 | Verified | 100 % approved имеют verified-by; pos/neg парность; QG-2 enforced; AI-provenance |
RENAR-5 | Optimized | Adversarial critic как gate; multi-model для priority: must; knowledge graph; metrics |
Промежуточные уровни (RENAR-3.5) и project-local уровни запрещены (§14.9.2). Локальное ужесточение критериев в пределах объявленного уровня — разрешено через declared-stricter (§14.4.2).
Каждый уровень включает в себя нормативные критерии всех нижестоящих уровней. RENAR-M подразумевает выполнение требований RENAR-1..RENAR-(M-1).
12.4 RENAR-1: Ad-hoc
12.4.1 Нормативное определение
RENAR-1 — нижний conformant уровень. Проект обязан удовлетворять:
- Requirements substrate существует физически (V1–V6 (§14.3.2) обеспечены — это абсолютное mandatory clause независимо от уровня).
- Требования ведутся как артефакты внутри requirements substrate (не только в ticket-системах или личной переписке).
- Существует ADAPT для каждого ТЗ (§14.3.3) — это mandatory clause, не уровневый.
- Применяется substrate-agnostic язык для нормативных описаний (§5.5.4) — substrate-specific детали выносятся в
guide/.
12.4.2 Что НЕ требуется на RENAR-1
- Стандартизированный frontmatter артефактов (допустим минимальный
id+title). - Lifecycle статусы (
draft/approved/verified) — артефакты могут жить без явных переходов. - TC как отдельные артефакты — тесты допустимо вести в коде.
- COVERAGE — отсутствует.
- Substrate-нативные hooks lifecycle — не обязательны.
12.4.3 Observable signals
- Артефакт-файлы BR / SR / ADAPT существуют в substrate (не в трекере, не в чате).
- При запросе «откуда это требование» — ответ через substrate (а не через память участника).
- Conformance manifest (§14.4) выпущен с
level: RENAR-1.
12.4.4 Относительно QG enforcement
QG-0/QG-1/QG-2 нормативно объявлены как required (§14.3.6), но enforcement через substrate-нативные hooks не обязателен на RENAR-1. Acceptance check выполняется человеком вручную при необходимости.
12.5 RENAR-2: Documented
12.5.1 Нормативное определение
Поверх RENAR-1, проект обязан удовлетворять:
- Каждый артефакт BR / SR имеет frontmatter с обязательными полями (§6.5.2, §6.6.2) — допустим базовый minimum без сторогой schema-валидации.
- ТЗ зафиксировано как immutable артефакт substrate (§7.4.2).
- Существует структурное хранение артефактов (логические папки или substrate-нативные коллекции).
- Дельта-ТЗ оформляется как явный артефакт в substrate (не устно).
12.5.2 Что НЕ требуется на RENAR-2
- CI-валидация frontmatter по schema (
requirement-schema.md). - Полный lifecycle (статусы используются по желанию, не нормативно обязаны).
- TC покрытие —
tc-typeextensions необязательны. - Pos/neg парность TC.
12.5.3 Observable signals
- Все BR / SR имеют валидный (по обязательному minimum) frontmatter.
- ТЗ найдено как один substrate-native артефакт.
- Дельта-ТЗ присутствует как явный change-set (§7.6).
- Conformance manifest с
level: RENAR-2.
12.5.4 Относительно QG enforcement
QG-0 (Approval, §10.3.1) применяется как процедурный gate (явный approval с substrate-нативной фиксацией V6 author + timestamp), но без автоматической блокировки substrate-нативными hooks.
12.6 RENAR-3: Tracked
12.6.1 Нормативное определение
Поверх RENAR-2, проект обязан удовлетворять:
- Frontmatter артефактов валидирован по schema (reference/02-schemas.md) substrate-нативным механизмом (§10.11.1).
- Lifecycle статусы реально используются: каждый артефакт находится в одном из закрытых состояний (глава 10).
- TC существуют для всех BR / SR / SPEC с
priority: must; дляshould/could— желательно но не обязательно. - COVERAGE — substrate-нативный auto-generated артефакт (§9.15) обновляется на promote-transitions.
- Дельта-ТЗ оформляется как substrate-нативный change-set с явным impact analysis (§9.16).
- Substrate обеспечивает reference-validation hook (§10.11.1): создание BR / SR / SPEC, ссылающегося на ADAPT в статусе ниже
approved, автоматически блокируется. - Каждый артефакт реализационного substrate, ссылающийся на BR / SR / SPEC, обязан pinning через
verifies[].version(§9.4, V5).
12.6.2 Observable signals
- Frontmatter-validation hook substrate возвращает экономный structured feedback при нарушении schema.
- Каждый артефакт имеет status ∈ {
draft,approved,verified,deprecated,obsolete} (§10.5). - COVERAGE auto-generated и обновлён в течение разумного срока от последнего promote-transition.
- При delta-ТЗ архитектор видит затронутые SR / SPEC / TC автоматически.
- Conformance manifest с
level: RENAR-3.
12.6.3 Относительно QG enforcement
QG-0 (Approval) и QG-1 (Implementation) enforced substrate-нативно. QG-2 (Verification) может быть enforced частично — проверка verifies[] обязательна, но pos/neg парность (§9.7) не обязана enforced быть автоматически.
12.7 RENAR-4: Verified
12.7.1 Нормативное определение
Поверх RENAR-3, проект обязан удовлетворять:
- 100 % артефактов в
approvedимеютverified-byссылку на ≥ 1 TC (§9.4). - Pos/neg парность (§9.7) выполнена для каждого нормативного утверждения верифицируемого артефакта (
tc-type: contract/security/eval/ иной). Single-TC-coverage допустим только для negative-invariant утверждений (§9.7 исключение). - QG-2 (Verification, §10.3.3) enforced substrate-нативно: promote артефакта в
verifiedблокируется при отсутствии всехpassingTC на текущейrequirement-version. - Все TC автоматизированы (
automation.status: automated) либо явноmanual-pendingс дедлайном и обоснованием (§9.5). - Для
tc-type: ux— VLM-judge isolation (§9.13.4) соблюдена. - Для
tc-type: eval— judge-модель отличается от модели реализации (Decision #8). - AI-provenance во frontmatter артефактов per canonical поле-лист §3.10.1: минимум
ai-provenance.generated-by(идентификатор модели) иai-provenance.generated-at(отдельное UTC timestamp поле) обязательны для AI-генерируемых артефактов; полный список полей и cost-метрики на RENAR-5 — см. §3.10.1 + §12.8.1 (cost/latency budget). Frontmatter schemas §6.5.2 / §6.6.2 обязаны включать все поля §3.10.1. - Source citation в body артефакта: каждое нормативное утверждение имеет inline pointer на источник в ТЗ или ADAPT (
[TZ-XXX §Y line Z]или маркерderivedс pointer’ом). - Reconciliation hook (§5.4.2 continuous reconciliation) запускается substrate-нативно по расписанию (не реже еженедельно).
- Спот-чек 5 случайных passing TC раз в спринт (§9.14) фиксируется в audit-trail.
12.7.2 Observable signals
- COVERAGE содержит метрику
verified-by-percent: 100%дляapprovedартефактов. - При попытке promote BR / SR / SPEC в
verifiedбез всех passing TC — substrate возвращает blocking error. - Грубая выборка 5 случайных артефактов показывает source citation на все нормативные утверждения.
- Conformance manifest с
level: RENAR-4.
12.7.3 Относительно QG enforcement
QG-0, QG-1, QG-2 enforced substrate-нативно. QG-3 (Architecture, §10.4.1) — declared если проект использует ADAPT с двойной подписью (по умолчанию для регулируемых отраслей).
12.8 RENAR-5: Optimized
12.8.1 Нормативное определение
Поверх RENAR-4, проект обязан удовлетворять:
- Adversarial critic — обязательный gate для перехода артефакта
draft → approved: artefact обязан пройти ревью второй AI-моделью (отличной от модели генерации) с явной фиксацией согласия / расхождения в audit-trail. - Multi-model agreement для артефактов с
priority: must: артефакт генерируется ≥ 2 моделями; расхождения помечены маркером[multi-model-disagreement]и обязательны к ручному разбору. - Cost / latency budget per artifact: для каждого AI-генерируемого артефакта зафиксирован
cost-budgetиlatency-budget; превышение фактических значений триггерит автоматическую декомпозицию артефакта на меньшие части. - Knowledge graph (reference/05-knowledge-graph-schema.md) как primary search: AI-агенты обязаны использовать graph-запросы как первичный источник контекста; full-text search — fallback.
- Continuous evaluation для AI-критических компонентов: eval-runs по расписанию + on-change для всех
SPEC-AI(§8.5.7). - Метрика Hallucination Rate (глава 13) измеряется и поддерживается < 1 %.
- Метрика Multi-model Disagreement Rate (глава 13) измеряется и тренды отслеживаются.
- Возврат улучшений шаблонов в
requirements-libraryчерез substrate-нативный change-set — стандартная практика команды.
12.8.2 Observable signals
- Каждый промоутенный артефакт имеет audit-trail запись об adversarial review.
- При
priority: mustBR substrate показывает либо[multi-model-agreement]либо[multi-model-disagreement]маркер. - Knowledge graph health dashboard substrate-нативный и доступен.
- Hallucination Rate dashboard показывает < 1 % rolling window.
- Conformance manifest с
level: RENAR-5.
12.8.3 Относительно QG enforcement
Все obligatory gates (QG-0, QG-1, QG-2) enforced substrate-нативно. Adversarial review enforced как часть QG-0 (§10.3.1) — substrate блокирует promote draft → approved без подтверждения adversarial review. QG-3 (Architecture) — declared. QG-4 (Acceptance) — declared если проект применяет post-release outcomes (§10.4.2).
12.9 Сравнительная таблица признаков
Exhaustive matrix атрибутов по уровням. Заполнение: ❌ — не требуется; partial — частично; ✓ — нормативно обязательно.
| Признак | RENAR-1 | RENAR-2 | RENAR-3 | RENAR-4 | RENAR-5 |
|---|---|---|---|---|---|
| Substrate с V1–V6 | ✓ | ✓ | ✓ | ✓ | ✓ |
| ADAPT для каждого ТЗ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Frontmatter стандартизирован | ❌ | partial | ✓ | ✓ | ✓ |
| Lifecycle статусы используются | ❌ | partial | ✓ | ✓ | ✓ |
| Schema-валидация frontmatter (substrate hook) | ❌ | ❌ | ✓ | ✓ | ✓ |
| TC как first-class артефакт | ❌ | ❌ | partial | ✓ | ✓ |
| Pos/neg парность для каждого утверждения | ❌ | ❌ | ❌ | ✓ | ✓ |
| COVERAGE auto-generated | ❌ | ❌ | ✓ | ✓ | ✓ |
| Reference-validation hook | ❌ | ❌ | ✓ | ✓ | ✓ |
verifies[].version pinning (V5) | ❌ | ❌ | ✓ | ✓ | ✓ |
| QG-0 enforced substrate-нативно | ❌ | partial | ✓ | ✓ | ✓ |
| QG-2 enforced substrate-нативно | ❌ | ❌ | partial | ✓ | ✓ |
| AI-provenance во frontmatter | ❌ | ❌ | ❌ | ✓ | ✓ |
| Source citation в body артефактов | ❌ | ❌ | ❌ | ✓ | ✓ |
| Adversarial review as gate | ❌ | ❌ | ❌ | ❌ | ✓ |
Multi-model agreement для priority: must | ❌ | ❌ | ❌ | ❌ | ✓ |
| Cost/latency budget per artifact | ❌ | ❌ | ❌ | ❌ | ✓ |
| Knowledge graph primary search | ❌ | ❌ | ❌ | ❌ | ✓ |
| Continuous reconciliation | ❌ | ❌ | ❌ | ✓ (basic) | ✓ (full) |
| Continuous evaluation (SPEC-AI) | ❌ | ❌ | ❌ | ❌ | ✓ |
| Hallucination Rate < 1 % | n/a | n/a | n/a | n/a | tracked & enforced |
| Multi-model Disagreement Rate trending | n/a | n/a | n/a | n/a | tracked |
12.10 Минимальный entry-level
RENAR-1 — нормативная нижняя граница conformance manifest. Проект без выполнения mandatory clauses (§14.3) — в частности, без substrate V1–V6 или без ADAPT для каждого ТЗ — не имеет уровня RENAR-M вовсе; conformance manifest для такого проекта не выпускается.
| Тип проекта | Рекомендуемый целевой уровень |
|---|---|
| Small spike, < 1 sprint, без контракта | RENAR-2 — достаточно для документирования |
| Internal automation, 1–3 месяца | RENAR-3 — tracked lifecycle |
| Client-facing продукт по договору | RENAR-4 — verified с pos/neg парностью |
| AI-критическая компонента (eval-зависимая) | RENAR-5 — обязательно |
| Regulated industries (медицина, финтех, госсектор) | RENAR-4 minimum, RENAR-5 рекомендовано |
Стандарт допускает разные уровни в разных проектах одной organisation — нет требования унификации уровня по портфелю.
Negative scenario: substrate, в котором отсутствует хотя бы одна capability из V1–V6 (§11.2), нормативно не может реализовать никакой RENAR-M — даже RENAR-1. Это структурное ограничение, не операционное; manifest такого проекта невалиден (§14.3.2).
12.11 Path RENAR-1 → RENAR-5
Нормативная последовательность шагов между соседними уровнями. Времена — ожидаемый порядок (small project, не нормативная гарантия).
12.11.1 RENAR-1 → RENAR-2
- Создание structured хранения артефактов в substrate (logical folders или substrate-native collections).
- Перенос существующих требований из ticket-системы / чата / документов в substrate-native артефакты с минимальным frontmatter (
id,title). - Фиксация ТЗ как immutable артефакт (§7.4.2).
- Соглашение в команде: новые требования — только через substrate; не через ticket-системы.
Ожидаемое время: 1–2 недели для small project; 1–2 месяца для проекта с большим legacy backlog.
12.11.2 RENAR-2 → RENAR-3
- Привести frontmatter всех артефактов к schema (substrate-нативный нормализатор).
- Включить substrate hook для schema-валидации (block change-set при нарушении).
- Внедрить lifecycle: пройтись по всем артефактам, проставить статусы.
- Включить reference-validation hook (§10.11.1).
- Сгенерировать первоначальный COVERAGE auto-generated артефакт (§9.15).
- Создать TC для
priority: mustартефактов. - Внедрить
verifies[].versionpinning из реализационного substrate.
Ожидаемое время: 2–4 недели включая team training.
12.11.3 RENAR-3 → RENAR-4
- AI-агент проходит по всем артефактам, генерирует пары pos/neg TC для каждого нормативного утверждения.
- Реализация TC в коде / SPEC-runners — параллельно с feature work; растягивается на 1–2 квартала.
- Включить QG-2 substrate hook (block promote в
verifiedбез всех passing TC). - Внедрить spot-check workflow (§9.14).
- Включить reconciliation hook с еженедельным расписанием.
- Внедрить AI-provenance во frontmatter (substrate hook block при отсутствии для AI-генерируемых артефактов).
- Внедрить source citation в body артефактов (substrate hook block при отсутствии citation для нормативных утверждений).
Ожидаемое время: 1–2 квартала.
12.11.4 RENAR-4 → RENAR-5
- Подключить adversarial critic второй модели (отличной от primary; принцип judge isolation §9.13.4); включить как QG-0 enforcement.
- Включить multi-model генерацию для
priority: mustартефактов. - Развернуть knowledge graph (reference/05).
- Tune прицельные метрики Hallucination Rate и Multi-model Disagreement Rate (глава 13).
- Внедрить cost/latency budget с автоматической декомпозицией при overrun.
- Установить practice возврата улучшений шаблонов в
requirements-library. - Continuous evaluation для всех
SPEC-AIартефактов (§8.5.7).
Ожидаемое время: 1–2 квартала после RENAR-4.
12.11.5 Reverse-transitions (downgrade)
Нормативный downgrade (§14.8.2) — выпуск новой версии manifest с уровнем ниже текущего — допустим при наличии формального обоснования (например, decommissioning AI-критической компоненты, упрощение substrate). Downgrade обязан сопровождаться записью в audit-trail; скрытие downgrade — нарушение mandatory clause (§14.3.1).
12.12 Связь с SENAR ADR (Adversarial Detection Rate)
SENAR §9 определяет ADR — Adversarial Detection Rate — как общую метрику способности процесса обнаружить ошибки до выхода в production. RENAR-M определяет, на каких уровнях нормативная инфраструктура adversarial review существует. RENAR-specific подкласс ADR для зоны requirements — ACR (Adversarial Catch Rate, §13.3.6).
| RENAR-M | Нормативная adversarial-review инфраструктура | ADR / ACR измеримость |
|---|---|---|
| RENAR-1, RENAR-2 | Отсутствует (§12.4, §12.5) | n/a |
| RENAR-3 | Отсутствует нормативно; команда может ввести adversarial review как локальное ужесточение (declared-stricter §14.4.2) | optional |
| RENAR-4 | Pos/neg парность TC (§9.7) — structural ADR proxy; adversarial review артефактов нормативно не требуется | optional (pos/neg coverage measurable как proxy) |
| RENAR-5 | Adversarial critic как обязательный gate (§12.8.1) + multi-model agreement для priority: must | normatively measurable (ACR §13.3.6) |
RENAR-M зрелость связана с SENAR-метрикой ADR непрерывно, без дублирования: SENAR ADR fixes понятие метрики; RENAR-M уровень определяет, какие adversarial loops нормативны; ACR (§13.3.6) — domain-specific метрика для requirements zone.
12.13 Связь с другими главами
| Глава | Связь |
|---|---|
| 05 Положение в типологии методологий | §5.3 SoT inversion + §5.5 substrate-agnostic versioning — mandatory clauses независимо от уровня; §5.4 четыре отстройки — наблюдаются на всех уровнях, начиная с RENAR-2 |
| 06 Иерархия требований | Frontmatter артефактов и обязательные поля проверяются на RENAR-3+; иерархия BR/SR/TR — на всех уровнях |
| 07 ADAPT | ADAPT для каждого ТЗ — mandatory clause независимо от уровня (§12.4.1); двойная подпись QG-3 — declared на RENAR-4+ |
| 08 Specifications | Closed list 9 SPEC types — mandatory; полное type-specific покрытие на RENAR-4+; SPEC-AI continuous evaluation на RENAR-5 |
| 09 Test cases | TC для priority: must на RENAR-3; pos/neg парность на RENAR-4+; spot-check workflow на RENAR-4+ |
| 10 Lifecycle и QG | QG-0/QG-1/QG-2 объявлены required на всех уровнях; substrate enforcement постепенный — partial на RENAR-2, full на RENAR-4+; QG-3 declared на RENAR-4+ если ADAPT используется |
| 11 Substrate versioning | V1–V6 — абсолютное mandatory clause для любого уровня; substrate без V1–V6 не имеет уровня RENAR-M (§12.10) |
| 13 Metrics | Метрики Hallucination Rate / Multi-model Disagreement Rate / Defect Escape Rate измеряются на RENAR-4+; конкретные определения — в главе 13 |
| 14 Conformance | §14.2 forward-refs на эту главу для критериев каждого уровня; §14.5 self-assessment использует §12.X checklists; §14.9 closed list policy применяется к закрытому списку RENAR-1..5 (§12.3) |