05. Положение в типологии методологий

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

5.1 Назначение главы

RENAR опирается на три фундаментальных утверждения. Без любого из трёх остальные главы стандарта рассыпаются: иерархия требований (глава 06) теряет SoT-смысл, ADAPT перестаёт быть атомарной единицей передачи между договорным и инженерным контурами, спецификации не имеют параллельной оси, тест-кейсы теряют возможность pinning версии требования, lifecycle теряет атомарность переходов, substrate versioning теряет нормативную опору.

Глава фиксирует эти три утверждения как нормативные положения. Каждое утверждение является mandatory clause RENAR conformance (глава 14).

5.2 Три фундаментальных утверждения

Source of Truth inversion. Источник истины о поведении системы — иерархия артефактов требований. Код является derived артефактом реализации. Это RENAR — Spec-Driven Development.
Waterfall-форма ≠ классический waterfall. Процесс RENAR имеет последовательную слоистую форму с гейтами. Стандарт явно отстраивается от четырёх смертельных грехов классического waterfall.
Substrate-agnostic versioning. Версионирование является обязательным свойством substrate, реализующего RENAR. Конкретный инструмент версионирования — interchangeable. Шесть capabilities (V1–V6) нормируют требования к substrate; детали — в главе 11.

Три утверждения логически связаны (см. §5.6).

5.3 Утверждение 1 — Source of Truth: требования, не код

5.3.1 Нормативная формулировка

Источник истины о поведении системы — иерархия артефактов требований: ТЗ → ADAPT → BR / SR / SPEC → TR → TC. Код является derived артефактом реализации этой иерархии. При расхождении между кодом и вышестоящим требованием — нормативно побеждает требование.

5.3.2 Распределение ролей

Уровень	Кто SoT	Кто derived
ТЗ	Договор с клиентом	—
ADAPT	Двусторонняя интерпретация ТЗ	derived from ТЗ
BR / SR / SPEC	Инженерный стандарт системы	derived from ADAPT
TC	Контракт верифицируемого поведения	derived from SR / SPEC
TR (задача)	Акт выдачи работы исполнителю	derived from SR + SPEC
Код	Реализация	derived from всё вышестоящее

5.3.3 Контракт (обязательные следствия)

Стандарт требует следующего поведения от любой RENAR-conforming имплементации:

Запрет reverse-engineering поведения из кода в SR. AI-агент или человек, создающий новый SR или дополнение существующего SR, использует в качестве источника ADAPT и существующие SR — но не наблюдаемое поведение реализации. Reverse-engineering допустим только при создании bug-fix задачи (см. §5.3.4).
Разделение code review и spec review. Code review проверяет соответствие изменения коду. Spec review проверяет соответствие тестов и реализации требованиям. Это два разных гейта с разными артефактами и разными ревьюерами по умолчанию.
Drift detection как substrate hook. При обнаружении ссылки в коде на SR/SPEC, отсутствующий в requirements substrate, atomic change unit реализационного substrate блокируется (см. глава 10 §10.5, глава 11 §11.5).
Запрет молчаливой адаптации SR под код. Если реализация делает X, а SR требует Y, ровно одно из двух истинно: (a) реализация ошибочна — создаётся bug-fix задача с целью привести код к SR; (b) SR ошибочен — создаётся delta-ADAPT с обоснованием и подписями для изменения SR. Третий вариант («просто обновим SR под код») запрещён.

5.3.4 Положение в индустриальной типологии

Утверждение 1 является конкретной реализацией парадигмы Spec-Driven Development (SDD) — индустриального термина, появившегося в 2024–2025 как ответ на ускорение AI-driven разработки. SDD признаёт, что когда AI-агенты способны декомпозировать формальные спецификации в код за минуты, корректность спецификации становится критическим ограничением, а не корректность кода.

Стандарт / framework	Соответствующее положение	Связь с RENAR §5.3
ISO/IEC/IEEE 29148:2018 §6.4.5	Requirements management mandates traceability from requirements to implementation	RENAR §5.3 — конкретная реализация этого mandate
BABOK Guide v3 §6.5	Verify requirements before they drive solution work	RENAR §5.3 нормирует verify как два разных гейта (code/spec)
ISO/IEC 5338:2023	AI system life cycle — requirements drive AI artifact generation	RENAR §5.3 + принципы AI-генерации обеспечивают этот mandate
Spec-Driven Development (industry, 2024-2025)	GitHub SDD framework, Anthropic spec-first agents, Amazon Kiro, BMAD-Method	RENAR — formal standard в этой парадигме

5.4 Утверждение 2 — Waterfall-форма, не классический waterfall

5.4.1 Нормативная формулировка

Процесс RENAR имеет последовательную слоистую форму: ТЗ → ADAPT → BR/SR/SPEC → TR → реализация → TC-прогон → accepted. Это waterfall-образная форма. Стандарт явно отстраивается от четырёх смертельных грехов классического waterfall и не должен интерпретироваться как классический waterfall в смысле Royce 1970.

5.4.2 Четыре отстройки от классического waterfall

Классический waterfall (Royce 1970, индустриальная практика 1970–1990)	RENAR
Один большой проход «требования → дизайн → код → тесты» за квартал или год	Дельта-ТЗ workflow: каждое изменение — мини-цикл за дни или часы. Та же форма повторяется сотни раз с AI-ускорением. См. глава 07 §7.6 (delta-ADAPT)
Тесты в конце цикла, после реализации	TC — first-class артефакт (глава 09). Парные pos/neg TC создаются вместе с SR/SPEC, не после кода. Это ближе к V-model и ATDD, чем к waterfall
Одностороннее «throw spec over the wall»	ADAPT — двусторонний документ по построению. Forward (инженерная интерпретация) + backward (вопросы клиенту). Запрет на одностороннюю передачу
Спека написана один раз, потом неприкосновенна; реальность дрейфует	Continuous reconciliation через substrate hooks. Дрифт code ↔ spec детектируется автоматически и попадает в delta-ADAPT. Спека живая

5.4.3 Применимость

RENAR применим в следующих контекстах:

Контракт-ориентированная разработка (наличие договора с клиентом, подписанного ТЗ).
Regulated industries: compliance, медицина, финтех, госсектор, обработка PII.
Enterprise консалтинг (третья сторона делает продукт по чужому ТЗ).
Проекты с высокой стоимостью изменений требований поздно в цикле.
Проекты, требующие audit trail для compliance ревизий (глава 14).

RENAR не применим в следующих контекстах:

Чистый продуктовый дискавери без договорного контекста (lean startup, продукт-MVP «сначала строим, потом понимаем что строим»).
Чистое R&D без определённых требований.
Прототипирование с life cycle меньше срока написания ADAPT.

Применимость документируется как часть conformance claim.

5.4.4 Положение в индустриальной типологии

Методология	Связь с RENAR
Classical Waterfall (Royce 1970)	RENAR отстраивается по 4 пунктам §5.4.2
V-model	RENAR ближе к V-model: парные TC, тесты в начале каждого слоя
Scrum / Kanban	Не противоречит, но RENAR — другая ось (артефактная, не процессная). Scrum sprint может содержать RENAR delta-ADAPT cycle
SAFe Solution Intent	ADAPT — конкретная реализация Solution Intent для контракт-ориентированной разработки. См. guide/05-safe-comparison.md
BABOK Requirements Analysis	RENAR §5.3+§5.4 — formal реализация BABOK §3+§6 для AI-driven контекста

5.5 Утверждение 3 — Substrate-agnostic versioning

5.5.1 Нормативная формулировка

Версионирование является обязательным свойством substrate, реализующего RENAR. Стандарт нормирует шесть capabilities (V1–V6), которые substrate обязан обеспечить. Конкретный инструмент версионирования является interchangeable: substrate, удовлетворяющий V1–V6, реализует RENAR независимо от того, является ли он distributed VCS, централизованным VCS, документ-ориентированной СУБД с conflict resolution, или иным механизмом.

5.5.2 Шесть обязательных capabilities (concept-level)

Полная нормативная формулировка V1–V6 — в главе 11. На уровне положения в типологии:

#	Capability	Что обеспечивает
V1	Immutable history	Любое прошлое состояние артефакта восстановимо
V2	Atomic change unit	«Изменение» — одна транзакция; всё или ничего
V3	Diff & review	Человек видит изменение и approves / rejects до интеграции
V4	Branching / change-set	WIP отделим от утверждённой правды
V5	Cross-substrate version pin	Реализационный substrate фиксирует версию requirements substrate
V6	Author + timestamp	Каждое изменение имеет автора и время

5.5.3 Substrate, не удовлетворяющий V1–V6, не реализует RENAR

Невозможность реализации RENAR на substrate без V1–V6 — структурная, не операционная: утверждение 1 (SoT inversion) физически не работает без versioning, потому что:

Невозможно сказать «реализация собрана против требований по состоянию на дату X» — пропадает provenance (нарушение V1, V6).
Невозможно построить delta-ADAPT — нет базовой версии для отсчёта дельты (нарушение V1).
Невозможно верифицировать TC — поле verifies[].requirement-version теряет смысл без stable identifier версии (нарушение V5).
Невозможен переход требования verified → accepted — гейту не на что опереться (нарушение V1, V5).
Невозможен audit trail «что мы сдавали клиенту по контракту 2025-Q3» (нарушение V1, V6).

Поэтому substrate без V1–V6 (плоский файловый сервер с переименованием файлов как механизмом версии; document store без conflict resolution; иные системы без immutable history) не реализует RENAR независимо от других свойств.

5.5.4 Substrate-agnostic нормативный язык

Нормативные параграфы RENAR используют substrate-agnostic язык: «atomic change unit», «version pin», «author + timestamp», «diff & review» — а не названия конкретных primitives конкретных инструментов. Это обеспечивает применимость стандарта к любому будущему substrate, удовлетворяющему V1–V6.

Substrate-specific детали (mapping V1–V6 на конкретные инструменты) являются неотъемлемой частью имплементации, но описываются в:

Глава 11 §11.4 — нормативная mapping таблица V1–V6 × {основные substrate}.
guide/03-tool-guide-git.md — практическая имплементация на distributed VCS.
guide/04-tool-guide-raven.md — практическая имплементация на document-oriented store.

5.5.5 Положение в индустриальной типологии

Стандарт	Соответствующее положение	Substrate-нейтральность
ISO/IEC/IEEE 29148:2018 §6.4.5	Configuration management of requirements	Substrate-нейтрален; нормирует capabilities, не tools
BABOK Guide v3 §5.3	Maintain requirements (для прослеживаемости)	Substrate-нейтрален
CMMI-DEV CM SG2	Track and Control Changes	Substrate-нейтрален
SAFe Solution Intent	Versioned artifact	Не нормирует substrate
ISO/IEC 5338:2023	AI artifact provenance	Substrate-нейтрален; provenance — capability

RENAR следует той же нейтральности и явно фиксирует V1–V6 как контракт, что эти стандарты оставляли неявным.

5.6 Логическая связь трёх утверждений

Три утверждения связаны направленно:

              Утверждение 1 (SoT inversion)
              требования > код
                       │
                       │ требует
                       ▼
        Утверждение 3 (substrate versioning V1–V6)
        provenance, pin, history, atomic change
                       │
                       │ позволяет
                       ▼
              Утверждение 2 (waterfall-форма, не классика)
              дельта-ТЗ, парные TC, ADAPT, reconciliation
                       │
                       │ возвращает
                       ▼
              Контракт-ориентированная разработка
              жизнеспособна с AI-ускорением

Без утверждения 1: SoT диффузен, спека дрейфует, audit невозможен. Без утверждения 3: утверждение 1 декларативно, физически не работает. Без явного утверждения 2: ревьюер натягивает на RENAR неподходящие шаблоны (agile sprint без waterfall-form, или classical waterfall без 4 отстроек) и отвергает стандарт по неверной аналогии.

Все три утверждения являются mandatory clauses (глава 14). Conformance к RENAR без любого из трёх не существует на уровне v1.

5.7 Conformance implication

Утверждения §5.3, §5.4, §5.5 являются mandatory clauses для всех уровней RENAR conformance (RENAR-1 .. RENAR-5; см. глава 12, глава 14).

Это означает:

Команда не может заявить «реализуем RENAR-1 без SoT inversion» — это противоречие в терминах.
Команда не может заявить «реализуем RENAR на substrate без V1–V6» — substrate не реализует стандарт.
Команда может выбрать не реализовать RENAR в контексте неприменимости (§5.4.3) — это нормативно допустимо.

Конкретный self-assessment checklist для каждого утверждения — в главе 14.

5.8 Связь с другими главами стандарта

Глава	Связь
06 Требования	Иерархия BR/SR/TR — конкретизация SoT chain из §5.3.2
07 ADAPT	Двусторонняя адаптация — конкретизация утверждения 2 (отстройка от «throw over the wall»)
08 Specifications	SPEC-* как параллельная ось — следствие SoT inversion для структурного описания
09 Test cases	TC как first-class — конкретизация утверждения 2 (отстройка от «тесты в конце»)
10 Lifecycle и QG	Гейты обеспечивают enforcement утверждения 1 (drift hooks) и утверждения 2 (continuous reconciliation)
11 Substrate versioning	Детальная нормативка V1–V6 (§5.5 — concept-level)
12 Maturity	Уровни RENAR-1..RENAR-5 расширяют утверждения дополнительными требованиями
14 Conformance	Self-assessment по трём mandatory clauses