11. Модель зрелости¶
Часть RENAR Standard v1.0-draft · ← Оглавление
11.1 Зрелость как лестница, а не ярлык¶
Глава 3 дала фундамент — носитель, способный хранить историю и происхождение требований. Но наличие фундамента ещё не говорит, насколько зрело команда им пользуется. Один проект просто держит требования в носителе; другой валидирует их по схеме, гоняет парные тесты и заставляет вторую модель оспаривать первую. Это разные ступени одной лестницы — и эта глава их нумерует.
RENAR определяет пять уровней зрелости — RENAR-1..RENAR-5, закрытый список. Уровень — это измеримая характеристика того, насколько формализовано управление требованиями в проекте. Его важно не путать с заявлением о соответствии (соответствие): уровень описывает, где находится проект, а соответствие — это процедура, которой он это доказывает. Механика заявления — в главе 13.
Каждая следующая ступень добавляет обязательства поверх предыдущей и закрывает свой класс расхождений; читать главу стоит по порядку: §11.4–§11.8 разбирают ступени по одной, §11.10–§11.11 отвечают на «с чего начать» и «как расти».
Граница главы строгая. Она нормирует только критерии уровней и переходы между ними. Процедуры заявления о соответствии — глава 13; метрики измерения уровня — глава 12; сами capabilities носителя — глава 3.
11.2 RENAR-M как предметно-специфичная размерность в модели зрелости SENAR¶
11.2.1 Модель зрелости SENAR (общая зрелость)¶
SENAR определяет одномерную модель из пяти уровней общей зрелости команды и методологии: Стихийный → Супервизируемый → Измеримый → Управляемый → Оптимизирующий. Эта модель оценивает процессную зрелость команды в целом, независимо от конкретной процессной области.
11.2.2 RENAR-M как отдельная размерность¶
RENAR-M — отдельная размерность в общей зрелости по SENAR, специализирующая её для процессной области «инженерия требований». Проект характеризуется парой:
проект ──▶ (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-практиках в целом, но именно управление требованиями формализовано слабо. Это допустимый и наблюдаемый сценарий.
11.2.3 Согласованность с SENAR Reference¶
SENAR Reference допускает предметно-специфичные размерности зрелости (аутентификация, безопасность, наблюдаемость и иные процессные области). RENAR-M — одна из таких размерностей; она не противоречит SENAR и не дублирует его.
В индустрии типична ситуация, когда в одной организации разные процессные области имеют различную зрелость. RENAR-M — нормативная размерность зрелости именно для области «инженерия требований», с критериями только из этой главы и смежных параграфов стандарта.
11.2.4 Соответствие как пара¶
Манифест соответствия (§13.4) фиксирует только RENAR-M (поле level). SENAR-N остаётся в области SENAR-соответствия и в RENAR-манифесте не дублируется.
11.3 Закрытый список уровней RENAR-1..RENAR-5¶
Список из пяти уровней закрыт. Изменение списка возможно только через формальную процедуру изменения стандарта (§13.9.3).
| Уровень | Краткое название | Семантика (одной строкой) |
|---|---|---|
RENAR-1 |
Стихийный (Ad-hoc) | Носитель требований существует; артефакты ведутся без формальной схемы и жизненного цикла |
RENAR-2 |
Зафиксированный (Documented) | Артефакты имеют базовый frontmatter и хранятся структурно; ТЗ зафиксировано |
RENAR-3 |
Учитываемый (Tracked) | Полная схема frontmatter; статусы жизненного цикла используются; delta-ТЗ рабочий поток через ADAPT |
RENAR-4 |
Верифицируемый (Verified) | 100% approved имеют verified-by; pos/neg парность; QG-2 обеспечивается; AI-происхождение |
RENAR-5 |
Оптимизирующий (Optimized) | Состязательный обзор как gate; несколько моделей для priority: must; граф знаний; метрики |
Промежуточные уровни (RENAR-3.5) и локальные для проекта уровни запрещены (§13.9.2). Локальное ужесточение критериев в пределах объявленного уровня разрешено через declared-stricter (§13.4.2).
Каждый уровень включает нормативные критерии всех нижестоящих. RENAR-M подразумевает выполнение требований RENAR-1..RENAR-(M-1).
11.4 RENAR-1: Стихийный (Ad-hoc)¶
Первая ступень отвечает на вопрос: где живут требования? Ответ — «в носителе, а не в чьей-то голове, трекере задач или переписке». Формальной схемы и жизненного цикла ещё нет, но происхождение уже восстановимо.
11.4.1 Нормативное определение¶
RENAR-1 — нижний соответствующий уровень. Проект обязан удовлетворять: носитель существует физически (V1–V6 §13.3.2 — абсолютное обязательное положение независимо от уровня); требования ведутся как артефакты внутри носителя (не в трекерах задач или переписке); существует ADAPT для каждого ТЗ (§13.3.3); применяется независимый от носителя язык (§2.5.4).
RENAR-1 ≠ нулевая инфраструктура. «Стихийный» — про отсутствие формальной схемы / жизненного цикла, а не носителя: V1–V6 обязательны на любом уровне. Плоский файловый сервер, Notion, Google Docs, Confluence без immutable history / atomic change / version pin не квалифицируются даже на RENAR-1. Минимум — distributed VCS или document-oriented store с V1–V6 (§3, guide/03–04).
11.4.2 Что НЕ требуется на RENAR-1¶
Стандартизированный frontmatter (допустим минимум id + title); статусы жизненного цикла; TC как отдельные артефакты (допустимо вести в коде); COVERAGE; нативные для носителя hooks жизненного цикла.
11.4.3 Наблюдаемые сигналы¶
Артефакт-файлы BR/SR/ADAPT в носителе (не в трекере/чате); на запрос «откуда это требование» ответ через носитель; манифест (§13.4) с level: RENAR-1.
11.4.4 Применение QG (обеспечение соблюдения)¶
QG-0/QG-1/QG-2 нормативно required (§13.3.6), но обеспечение соблюдения через hooks не обязательно — проверка человеком вручную по мере необходимости.
11.5 RENAR-2: Зафиксированный (Documented)¶
RENAR-2 добавляет к существованию структуру: базовый frontmatter, ТЗ как неизменяемый артефакт, предсказуемое место для артефактов. Требование можно найти, процитировать и сослаться на него. Машинной проверки ещё нет; дисциплину держат люди.
11.5.1 Нормативное определение¶
Поверх RENAR-1: каждый BR/SR имеет frontmatter с обязательными полями (§6.5.2, §6.6.2) — минимум без строгой schema-валидации; ТЗ — неизменяемый артефакт (§7.4.2); структурное хранение (логические папки / нативные коллекции); delta-ТЗ — явный артефакт, не устный.
11.5.2 Что НЕ требуется на RENAR-2¶
CI-валидация frontmatter по схеме; полный жизненный цикл (статусы по желанию); TC расширения tc-type; pos/neg парность TC.
11.5.3 Наблюдаемые сигналы¶
Все BR/SR имеют валидный (по минимуму) frontmatter; ТЗ — один нативный артефакт; delta-ТЗ как явный change-set (§7.6); манифест с level: RENAR-2.
11.5.4 Применение QG (обеспечение соблюдения)¶
QG-0 (§10.3.1) — процедурный gate (явное утверждение с V6 author + timestamp), без автоматической блокировки hooks.
11.6 RENAR-3: Учитываемый (Tracked)¶
На RENAR-3 включается машина. Frontmatter валидируется по схеме, статусы жизненного цикла работают, delta-ТЗ проходит через ADAPT. Носитель блокирует ссылку на неутверждённый ADAPT и не даёт реализации сослаться на требование без привязки версии.
11.6.1 Нормативное определение¶
Поверх RENAR-2: frontmatter валидирован по схеме (reference/02-schemas.md) нативным механизмом (§10.11.1); статусы жизненного цикла реально используются (глава 10); TC существуют для всех BR/SR/SPEC с priority: must; COVERAGE авто-генерируется (§9.15); delta-ТЗ — change-set с анализом влияния (§9.16); reference-validation hook (§10.11.1) блокирует создание артефакта со ссылкой на ADAPT ниже approved; реализационный носитель привязывает verifies[].version (§9.4, V5).
11.6.2 Наблюдаемые сигналы¶
Hook валидации frontmatter возвращает структурированный отклик при нарушении схемы; каждый артефакт ∈ {draft, approved, verified, deprecated, obsolete} (§10.5); COVERAGE обновляется в разумный срок; при delta-ТЗ архитектор автоматически видит затронутые SR/SPEC/TC; манифест с level: RENAR-3.
11.6.3 Применение QG (обеспечение соблюдения)¶
QG-0 + QG-1 обеспечиваются нативно; QG-2 — частично (проверка verifies[] обязательна, pos/neg парность (§9.7) не обязана автоматической).
11.7 RENAR-4: Верифицируемый (Verified)¶
RENAR-4 — рубеж доверия к тестам. Каждое нормативное утверждение покрыто парой pos/neg TC, QG-2 блокирует перевод в verified без зелёных тестов на актуальной версии, спот-чек раз в итерацию ловит тесты, подделанные под код.
11.7.1 Нормативное определение¶
Поверх RENAR-3: 100% артефактов в approved имеют verified-by со ссылкой на ≥ 1 TC (§9.4); pos/neg парность (§9.7) выполнена для каждого нормативного утверждения (single-TC-coverage допустим только для инвариантов с негативной семантикой); QG-2 (§10.3.3) обеспечивается — перевод в verified блокируется при отсутствии всех passing TC на текущей requirement-version; все TC автоматизированы (automation.status: automated) либо помечены manual-pending с дедлайном (§9.5); для tc-type: ux — изоляция судьи VLM (§9.13.4); для tc-type: eval модель-судья отличается от модели реализации (Decision #8); AI-происхождение во frontmatter (§4.10.1): минимум generated-by и generated-at обязательны; цитирование источника в теле артефакта ([TZ-XXX §Y line Z] или маркер derived); hook непрерывной сверки (§2.4.2) по расписанию (не реже раз в неделю); спот-чек 5 случайных passing TC раз в итерацию (§9.14) в audit-trail.
11.7.2 Наблюдаемые сигналы¶
COVERAGE содержит verified-by-percent: 100% для approved; попытка перевода BR/SR/SPEC в verified без всех passing TC возвращает блокирующую ошибку; выборка 5 случайных артефактов показывает цитирование источника на все нормативные утверждения; манифест с level: RENAR-4.
11.7.3 Применение QG (обеспечение соблюдения)¶
QG-0/QG-1/QG-2 обеспечиваются нативно. QG-3 (Architecture, §10.4.1) — declared, если проект использует ADAPT с двойной подписью (по умолчанию для регулируемых отраслей).
11.8 RENAR-5: Оптимизирующий (Optimized)¶
RENAR-5 замыкает контур AI-надёжности. Вторую модель ставят оспаривать первую, критичные требования генерируются несколькими моделями с обязательным разбором расхождений, частота галлюцинаций удерживается ниже 1%. Стандарт становится системой, которая сама себя проверяет.
11.8.1 Нормативное определение¶
Поверх RENAR-4: состязательный обзор — обязательный gate для draft → approved (артефакт проходит рецензирование второй AI-моделью с фиксацией в audit-trail); multi-model agreement для priority: must (артефакт генерируется ≥ 2 моделями; расхождения помечаются [multi-model-disagreement] и обязательны к разбору); cost/latency budget на артефакт (cost-budget + latency-budget; превышение запускает автоматическую декомпозицию); граф знаний (reference/05) — первичный поиск AI-агентов; continuous evaluation для всех SPEC-AI (§8.5.7); Hallucination Rate (глава 12) измеряется и < 1%; Multi-model Disagreement Rate (глава 12) измеряется, тренды отслеживаются; возврат улучшений шаблонов в requirements-library — стандартная практика.
11.8.2 Наблюдаемые сигналы¶
Каждый promote-нутый артефакт имеет в audit-trail запись состязательного обзора; для priority: must BR — маркер [multi-model-agreement] или [multi-model-disagreement]; дашборд графа знаний доступен; дашборд Hallucination Rate < 1% на скользящем окне; манифест с level: RENAR-5.
11.8.3 Применение QG (обеспечение соблюдения)¶
Все обязательные gates (QG-0/½) обеспечиваются нативно. Состязательный обзор обеспечивается как часть QG-0 — носитель блокирует draft → approved без подтверждения. QG-3 declared. QG-4 declared, если проект применяет post-release outcomes (§10.4.2).
11.9 Сравнительная таблица признаков¶
Всё, что разнесено по пяти секциям выше, в одной матрице. Заполнение: ❌ — не требуется; частично — частично; ✓ — нормативно обязательно.
| Признак | RENAR-1 | RENAR-2 | RENAR-3 | RENAR-4 | RENAR-5 |
|---|---|---|---|---|---|
| Носитель с V1–V6 | ✓ | ✓ | ✓ | ✓ | ✓ |
| ADAPT для каждого ТЗ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Frontmatter стандартизирован | ❌ | частично | ✓ | ✓ | ✓ |
| Статусы жизненного цикла используются | ❌ | частично | ✓ | ✓ | ✓ |
| Валидация frontmatter по схеме (hook носителя) | ❌ | ❌ | ✓ | ✓ | ✓ |
| TC как полноценный артефакт | ❌ | ❌ | частично | ✓ | ✓ |
| Pos/neg парность для каждого утверждения | ❌ | ❌ | ❌ | ✓ | ✓ |
| COVERAGE авто-генерируется | ❌ | ❌ | ✓ | ✓ | ✓ |
| Reference-validation hook | ❌ | ❌ | ✓ | ✓ | ✓ |
Привязка verifies[].version (V5) |
❌ | ❌ | ✓ | ✓ | ✓ |
| QG-0 обеспечивается нативно для носителя | ❌ | частично | ✓ | ✓ | ✓ |
| QG-2 обеспечивается нативно для носителя | ❌ | ❌ | частично | ✓ | ✓ |
| AI-происхождение во frontmatter | ❌ | ❌ | ❌ | ✓ | ✓ |
| Цитирование источника в теле артефактов | ❌ | ❌ | ❌ | ✓ | ✓ |
| Состязательный обзор как gate | ❌ | ❌ | ❌ | ❌ | ✓ |
Согласование нескольких моделей для priority: must |
❌ | ❌ | ❌ | ❌ | ✓ |
| Бюджет стоимости и задержки на артефакт | ❌ | ❌ | ❌ | ❌ | ✓ |
| Граф знаний как первичный поиск | ❌ | ❌ | ❌ | ❌ | ✓ |
| Непрерывная сверка | ❌ | ❌ | ❌ | ✓ (базовая) | ✓ (полная) |
| Непрерывная оценка (SPEC-AI) | ❌ | ❌ | ❌ | ❌ | ✓ |
| Hallucination Rate < 1% | н/п | н/п | н/п | н/п | измеряется и контролируется |
| Тренд Multi-model Disagreement Rate | н/п | н/п | н/п | н/п | отслеживается |
11.10 Минимальный входной уровень (entry-level)¶
RENAR-1 — нормативная нижняя граница манифеста соответствия. Проект, не выполняющий обязательные положения (§13.3) — в частности, без носителя с V1–V6 или без ADAPT для каждого ТЗ — не имеет уровня RENAR-M вовсе; манифест соответствия для такого проекта не выпускается.
| Тип проекта | Рекомендуемый целевой уровень |
|---|---|
| Короткий эксперимент (spike), < 1 спринта, без контракта | RENAR-2 — достаточно для документирования |
| Внутренняя автоматизация, 1–3 месяца | RENAR-3 — учитываемый жизненный цикл |
| Клиентский продукт по договору | RENAR-4 — верифицируемый, с pos/neg парностью |
| AI-критическая компонента (зависит от eval) | RENAR-5 — обязательно |
| Регулируемые отрасли (медицина, финтех, госсектор) | RENAR-4 минимум, RENAR-5 рекомендовано |
Стандарт допускает разные уровни в разных проектах одной организации — требования унифицировать уровень по портфелю нет.
Негативный сценарий: носитель, в котором отсутствует хотя бы одна capability из V1–V6 (§3.2), нормативно не может реализовать никакой RENAR-M — даже RENAR-1. Это структурное ограничение, не операционное; манифест такого проекта невалиден (§13.3.2).
11.11 Путь RENAR-1 → RENAR-5¶
Нормативная последовательность шагов между соседними уровнями. Времена — ожидаемый порядок (для небольшого проекта; это не нормативная гарантия).
11.11.1 RENAR-1 → RENAR-2¶
- Создать структурное хранение артефактов в носителе (логические папки или нативные для носителя коллекции).
- Перенести существующие требования из трекера задач, чата или документов в нативные для носителя артефакты с минимальным frontmatter (
id,title). - Зафиксировать ТЗ как неизменяемый артефакт (§7.4.2).
- Договориться в команде: новые требования — только через носитель, не через трекер задач.
Ожидаемое время: 1–2 недели для небольшого проекта; 1–2 месяца для проекта с большим объёмом накопленных требований.
11.11.2 RENAR-2 → RENAR-3¶
- Привести frontmatter всех артефактов к schema (нативный для носителя нормализатор).
- Включить hook носителя для schema-валидации (блокировать change-set при нарушении).
- Внедрить жизненный цикл: пройтись по всем артефактам, проставить статусы.
- Включить reference-validation hook (§10.11.1).
- Сгенерировать первоначальный авто-генерируемый артефакт COVERAGE (§9.15).
- Создать TC для артефактов с
priority: must. - Внедрить привязку
verifies[].versionиз реализационного носителя.
Ожидаемое время: 2–4 недели, включая обучение команды.
11.11.3 RENAR-3 → RENAR-4¶
- AI-агент проходит по всем артефактам и генерирует пары pos/neg TC для каждого нормативного утверждения.
- Реализация TC в коде / SPEC-runners — параллельно с продуктовой работой; растягивается на 1–2 квартала.
- Включить hook носителя QG-2 (блокировать перевод в
verifiedбез всех passing TC). - Внедрить процесс спот-чека (§9.14).
- Включить hook непрерывной сверки с еженедельным расписанием.
- Внедрить AI-происхождение во frontmatter (hook носителя блокирует при отсутствии для AI-генерируемых артефактов).
- Внедрить цитирование источника в теле артефактов (hook носителя блокирует при отсутствии цитаты для нормативных утверждений).
Ожидаемое время: 1–2 квартала.
11.11.4 RENAR-4 → RENAR-5¶
- Подключить состязательный обзор второй модели (отличной от первичной; принцип изоляции судьи §9.13.4); включить как обеспечение соблюдения QG-0.
- Включить генерацию несколькими моделями для артефактов с
priority: must. - Развернуть граф знаний (reference/05).
- Настроить прицельные метрики Hallucination Rate и Multi-model Disagreement Rate (глава 12).
- Внедрить бюджет стоимости и задержки с автоматической декомпозицией при превышении.
- Закрепить практику возврата улучшений шаблонов в
requirements-library. - Непрерывная оценка для всех артефактов
SPEC-AI(§8.5.7).
Ожидаемое время: 1–2 квартала после RENAR-4.
11.11.5 Обратные переходы (понижение уровня, downgrade)¶
Нормативное понижение уровня (§13.8.2) — выпуск новой версии манифеста с уровнем ниже текущего — допустимо при наличии формального обоснования (например, вывод из эксплуатации AI-критической компоненты, упрощение носителя). Понижение обязано сопровождаться записью в audit-trail; скрытие понижения — нарушение обязательного положения (§13.3.1).
11.12 Связь с SENAR ADR (Adversarial Detection Rate)¶
SENAR §9 определяет ADR — Adversarial Detection Rate — как общую метрику способности процесса обнаружить ошибки до выхода в промышленную эксплуатацию. RENAR-M определяет, на каких уровнях существует нормативная инфраструктура состязательного обзора. RENAR-специфичный подкласс ADR для зоны требований — ACR (Adversarial Catch Rate, §12.3.6).
| RENAR-M | Нормативная инфраструктура состязательного обзора | Измеримость ADR / ACR |
|---|---|---|
| RENAR-1, RENAR-2 | Отсутствует (§11.4, §11.5) | н/п |
| RENAR-3 | Нормативно отсутствует; команда может ввести состязательный обзор как локальное ужесточение (declared-stricter, §13.4.2) |
опционально |
| RENAR-4 | Pos/neg парность TC (§9.7) — структурный прокси ADR; состязательный обзор артефактов нормативно не требуется | опционально (покрытие pos/neg измеримо как прокси) |
| RENAR-5 | Состязательный обзор как обязательный gate (§11.8.1) + согласование нескольких моделей для priority: must |
нормативно измеримо (ACR, §12.3.6) |
Зрелость RENAR-M связана с SENAR-метрикой ADR непрерывно, без дублирования: SENAR ADR задаёт понятие метрики; уровень RENAR-M определяет, какие состязательные циклы нормативны; ACR (§12.3.6) — предметно-специфичная метрика для зоны требований.
11.13 Связь с другими главами¶
Модель зрелости — это карта, по которой расставлены требования всех остальных глав: каждая глава «включается» на своём уровне. Таблица ниже показывает, где именно.
| Глава | Связь |
|---|---|
| 02 Положение в типологии методологий | §2.3 инверсия источника истины + §2.5 независимое от носителя версионирование — обязательные положения независимо от уровня; §2.4 четыре отстройки — наблюдаются на всех уровнях, начиная с RENAR-2 |
| 06 Иерархия требований | frontmatter артефактов и обязательные поля проверяются на RENAR-3+; иерархия BR/SR/TR — на всех уровнях |
| 07 ADAPT | ADAPT для каждого ТЗ — обязательное положение независимо от уровня (§11.4.1); двойная подпись QG-3 — declared на RENAR-4+ |
| 08 Specifications | Закрытый список 9 типов SPEC — обязателен; полное type-specific покрытие на RENAR-4+; непрерывная оценка SPEC-AI на RENAR-5 |
| 09 Test cases | TC для priority: must на RENAR-3; pos/neg парность на RENAR-4+; процесс спот-чека на RENAR-4+ |
| 10 Жизненный цикл и QG | QG-0/QG-1/QG-2 объявлены required на всех уровнях; обеспечение соблюдения носителем постепенное — частичное на RENAR-2, полное на RENAR-4+; QG-3 declared на RENAR-4+, если используется ADAPT |
| 03 Версионирование носителя | V1–V6 — абсолютное обязательное положение для любого уровня; носитель без V1–V6 не имеет уровня RENAR-M (§11.10) |
| 12 Метрики | метрики Hallucination Rate / Multi-model Disagreement Rate / Defect Escape Rate измеряются на RENAR-4+; конкретные определения — в главе 12 |
| 13 Соответствие | §13.2 ссылается на эту главу за критериями каждого уровня; §13.5 self-assessment использует checklists §§11.4–12.8 (по одной секции на уровень); §13.9 политика закрытого списка применяется к закрытому списку RENAR-1..5 (§11.3) |