Стандарт RENAR v1.0-draft¶
15 нормативных глав. Это нормативный источник истины — здесь живут точные «обязан / должен / следует».
Если читаешь впервые — не начинай отсюда. Сначала RENAR Core (≤ 10 мин концептуальный обзор), затем быстрый старт (≈ 30 мин сквозной пример). В стандарт возвращайся когда нужна точная формулировка.
Архитектура¶
ТЗ клиента ваши артефакты доказательство
│ │ │
▼ ▼ ▼
┌─────────┐ ADAPT ──► BR / SR ──► SPEC ──► TC ──► QG ──► release
│immutable│ (договор │ │ │ │
└─────────┘ о смысле) └──── TR ─┘ │ └── conformance manifest
Главы выстроены в порядке аргумента — читать подряд 00 → 14. Фундамент (положение в типологии, §2) и инфраструктура носителя (V1–V6, §3) сознательно вынесены вперёд: главы об артефактах (06–10) на них опираются.
Оглавление¶
| # | Глава | Ссылка | О чём |
|---|---|---|---|
| 00 | Введение | 00-introduction.md | MVR (минимальный набор правил), связь с SENAR, политика закрытых списков |
| 01 | Область применения | 01-scope.md | Где RENAR обязателен, где избыточен, что вне области |
| 02 | Положение в типологии методологий | 02-methodology-positioning.md | Инверсия источника истины (требования → код); «форма водопада» ≠ classical waterfall |
| 03 | Версионирование носителя | 03-substrate-versioning.md | V1–V6 — что должен уметь носитель артефактов независимо от git / wiki / document store |
| 04 | Термины и определения | 04-terms.md | Канонический реестр терминов; один термин — одно значение |
| 05 | Роли | 05-roles.md | Кто отвечает за ADAPT, подписи, утверждение QG; AI-агент как штатный исполнитель |
| 06 | Иерархия требований | 06-requirements-hierarchy.md | BR / SR / TR: от бизнес-потребности до задачи реализации |
| 07 | ADAPT | 07-adapt.md | Реактивный мост между ТЗ и требованиями; forward + backward findings; двойная подпись |
| 08 | Спецификации | 08-specifications.md | Девять типов SPEC (ARCH…OPS) и граф связей с требованиями |
| 09 | Тест-кейсы | 09-test-cases.md | TC как артефакт с собственным жизненным циклом; pos/neg-парность; защита от «подгонки» тестов |
| 10 | Жизненный цикл и контрольные точки | 10-lifecycle-qg.md | Состояния, QG-0…QG-4, hooks |
| 11 | Модель зрелости | 11-maturity-model.md | RENAR-1…5 уровни зрелости |
| 12 | Метрики | 12-metrics.md | Измеримость процесса требований |
| 13 | Соответствие | 13-conformance.md | Манифест, обязательные пункты, самооценка + независимая оценка |
| 14 | Нормативные ссылки | 14-normative-refs.md | ISO 29148, NIST AI RMF, EU AI Act и другие рамки |
Маршруты по ролям¶
| Роль | Маршрут |
|---|---|
| Архитектор / Tech Lead | глава 2 → 3 → 10 → переход на RENAR |
| PM / RTE | Core → сравнение с SAFe |
| Legal / compliance / аудитор | guide/06 → reference/07 → §13 |
| Нужен термин с примером | глоссарий — глава 4 для оценщика, не для обучения |
Статус¶
- v1.3-draft (2026-06-05) — ADAPT: стадийность / множественность / дезавуирование (ADR-007, GitLab #7): стадийно-независимый триггер, множественность ADAPT на ТЗ, дезавуирование (
superseded). - v1.2-draft (2026-05-26) — partner pushback iteration; ADAPT-reactive (ADR-006) + Core pivot (ADR-005).
- v1.0 — после согласования партнёров и EN-перевода.
История изменений — CHANGELOG.md.