RENAR Core¶

Что это. Концептуальный обзор RENAR для человека-читателя: о чём стандарт, зачем нужен, как работает на верхнем уровне. Без технических подробностей, frontmatter, жизненного цикла и нормативных правил — это область полного RENAR Standard.

Время чтения: ≤ 10 минут. Для кого: PM, юристы, regulators, инженеры, впервые сталкивающиеся с RENAR. Если вы AI-агент — читайте напрямую Standard, Core вам не нужен.

Что такое RENAR¶

RENAR (Requirements Engineering & Normative Adaptive Regulation) — нормативный стандарт инженерии требований для разработки с AI-агентами. Стандарт нормирует:

Модель данных артефактов требований: BR (бизнес-требование), SR (системное требование), TR (задача), ADAPT (двусторонняя адаптация ТЗ), 9 типов SPEC (архитектура, API, данные, интеграция, процесс, UI, AI, безопасность, операции), TC (контрольные примеры).
Жизненный цикл и контрольные точки качества (Quality Gates QG-0..QG-4) — состояния артефактов и условия переходов.
Возможности носителя V1–V6, которым должна удовлетворять система хранения артефактов: неизменяемая история, атомарные изменения, сравнение/рецензирование, ветвление, сквозная фиксация версий, автор + отметка времени.
Соответствие — уровни RENAR-1..RENAR-5, обязательные положения, манифест, процедуры оценки.

RENAR — специализация SENAR (методологическая база разработки с AI-агентами) в области инженерии требований. Реализация, соответствующая RENAR, всегда совместима с SENAR; обратное — не обязательно.

Зачем существует RENAR¶

В разработке с AI-агентами требования живут одновременно в нескольких артефактах: договорное ТЗ клиента, инженерные BR/SR/SPEC, тест-кейсы, описание задачи, реализация в коде. Всё это пишет и правит смесь людей и AI-агентов. Без формальных контрактов между артефактами возникает дрейф требований — расхождение между тем, что зафиксировано, что верифицируется, и что фактически реализовано.

RENAR закрывает восемь нормированных классов дрейфа:

Схемный дрейф (schema drift) — поля артефактов расходятся между проектами.
Дрейф жизненного цикла (lifecycle drift) — статусы (draft / approved / verified) значат разное у разных авторов.
Source-of-truth drift — одна сущность правится одновременно в нескольких местах.
Implementation drift — код реализует требование, которое уже удалено или переименовано.
Terminological drift — термины значат разное у разных людей.
Order / provenance drift — delta-ТЗ применяется не в порядке, ссылается на несуществующее требование.
TC ↔ requirement provenance drift — тест верифицирует устаревшее поведение.
Test-fitting drift — AI-агент ослабляет критерии теста вместо исправления кода.

Все восемь классов — структурные: они возникают из самого факта совместного владения артефактом несколькими авторами, а не из ошибок дисциплины. Закрыть их можно только нормативно — фиксацией контракта о том, как артефакты связаны, кто пишет какое поле, и какие предусловия обязаны выполняться при переходах состояний.

Как работает RENAR (концептуально)¶

Полный жизненный цикл одного требования:

flowchart TD
    K[Клиент] --> TZ[ТЗ — договор, неизменяемый]
    TZ --> AR{Adversarial-обзор}
    AR -->|«findings present»| AD["ADAPT — двусторонняя адаптация:<br/>forward + backward findings;<br/>двойная подпись Архитектор + Клиент"]
    AR -->|«no findings»| ART["BR / SR / SPEC / TR / TC<br/>(RENAR-описание)"]
    AD --> ART
    ART --> IMPL[Реализация код]

Ключевые свойства:

ТЗ — договорной неизменяемый артефакт. После подписания клиентом не редактируется. Изменения scope формализуются через delta-ТЗ.
ADAPT — реактивный мост между языком клиента и языком требований. Создаётся только когда конвертация ТЗ → RENAR требует согласования с клиентом (выявленные backward findings, term mapping, scope clarification). Состязательный рецензент (отдельный AI-агент с другой моделью) фиксирует вердикт «findings present» либо «no findings» для каждого ТЗ.
RENAR-описание — источник истины (Source of Truth) о поведении системы. Код — производный артефакт реализации, не авторитетное определение поведения. Если код делает X, а SR говорит Y — это дефект кода, не «фактическое требование изменилось».
TC pos/neg парность. Каждое верифицируемое утверждение требования имеет минимум один позитивный и один негативный тест-кейс. AI-агенты охотно покрывают happy path и обходят негативные сценарии — RENAR делает парность нормативной.
Состязательный обзор. Отдельный AI-агент с другой моделью специально ищет, что primary агент пропустил: недостающие backward findings, ослабленные критерии TC, скрытые допущения. Это компенсирующий механизм против самосогласованных, но семантически неверных AI-выводов.
Двойная подпись ADAPT. Когда ADAPT создаётся, он переходит в approved только после двух подписей: клиент (или его представитель) подтверждает совпадение интерпретации с намерением; архитектор подтверждает техническую реализуемость и закрытие всех находок.

Полный жизненный цикл нормирован через Quality Gates (QG-0 Approval, QG-1 Implementation, QG-2 Verification обязательные; QG-3 Architecture, QG-4 Acceptance опциональные). Каждый переход в более высокий статус артефакта проходит через соответствующий gate с зафиксированным участником и предусловиями.

Штатный исполнитель — AI-агент¶

RENAR-артефакты штатно создаются и поддерживаются AI-агентом по заданию инженера. Человек выполняет роль verifier и approver: просматривает результат, уточняет задачу при необходимости, утверждает переходы жизненного цикла.

Из этого позиционирования следуют две вещи, которые непривычны при чтении стандарта в первый раз:

Артефакты выглядят плотно (десятки полей frontmatter, переходы жизненного цикла, графовые связи) — потому что основной читатель машинный. Плотность — не бюрократия, а требование к «коду на естественном языке», который AI-агент исполняет на последующих шагах.
Процессные издержки на ведение — машинные, не человеческие. AI-агент не устаёт заполнять frontmatter; объём работы линейный. Для человека эти издержки кажутся неподъёмными — но именно их и не нужно нести вручную.

При этом человек остаётся источником решений по contractual outcomes: подпись ADAPT, утверждение QG-0, выборочная проверка тестов, acceptance результата. AI-агент — responsible (исполняет), человек — accountable (отвечает за результат).

Кому пригодится RENAR¶

RENAR создан для контракт-ориентированной разработки: проектов с явным договорным ТЗ и идентифицируемой стороной клиента, перед которой за ТЗ отвечают. Типичные контексты:

Заказная разработка — независимый vendor + клиент с подписанным ТЗ и acceptance criteria.
Регулируемые отрасли (медицина, финансы, госсектор) — где compliance audit обязателен по нормативу.
Enterprise консалтинг — третья сторона реализует по ТЗ корпоративного клиента с утверждением несколькими заинтересованными сторонами.
Public-sector / государственный IT — тендерные ТЗ, формальная приёмка, multi-year contracts.
Long-lived продукты — где Владелец продукта играет роль представителя Клиента для внутренних feature-ТЗ.

RENAR не применим для lean startup discovery, pure R&D без определённого scope, hackathon proofs-of-concept и других контекстов без неизменяемого ТЗ и идентифицируемой Заинтересованной стороны.

Маршруты по ролям¶

Роль	Где начать
PM / RTE	guide/05 — RENAR vs SAFe; затем guide/09 §E3 — практический пример
Legal / Compliance	guide/09 §E3 → guide/06 → reference/07 — ISO 29148 mapping
Regulator / Auditor	reference/07 → reference/08 → standard/13 — манифест соответствия
RE-инженер / Архитектор	guide/00 Быстрый старт → standard/06 → standard/10

Где читать дальше¶

Документ	Назначение
standard/ — 15 нормативных глав	Полное нормативное описание; обязательное чтение для AI-агента и assessor-а
guide/00-quickstart	30-минутный практический сквозной пример: ТЗ → ADAPT → SR → SPEC → TC
guide/01-walkthrough	Расширенный пример на полномасштабном сценарии
guide/06-compliance	GDPR, ФЗ-152, AI Act mapping
reference/01-glossary	Канонический глоссарий + mapping на ISO 29148, BABOK, SAFe, NIST AI RMF
reference/02-schemas	Машино-читаемые схемы артефактов (JSON Schema), правила валидации
reference/03-ai-risk-register	14 AI-рисков по ISO/IEC 23894 + NIST AI RMF