Обзор принципов

Принципы RENAR

Девять идей, на которых построен стандарт. Это не нормативка — введение. Далее — полный стандарт или ядро.

Содержание
1. Пять ценностей 2. Иерархия BR → SR → TR 3. ADAPT — двусторонняя адаптация 4. 9 типов SPEC 5. Контрольные примеры (TC) 6. Хранилище и V1–V6 7. Шлюзы качества QG-0..2 8. Зрелость RENAR-1..5 9. Отношение к SENAR

1. Пять ценностей

Те же, что у SENAR — на них построена методология RENAR.

Требования — источник истины
Реализация подчиняется требованиям. Артефакты в хранилище; ТЗ — неизменяемый вход.
Трассируемость важнее скорости
Цепочка ТЗ → BR → SR → TR → TC → код. Скорость без трассировки — техдолг.
Политика закрытого списка
Новые типы SPEC, шлюзы и состояния lifecycle — только через поправку стандарта. Защита от дрейфа.
Учёт AI в проектировании
Метрики (Hallucination Rate, Multi-model Disagreement) и реестр AI-рисков — нормативные элементы.
Независимость от хранилища
Правила через возможности V1–V6, а не через конкретный продукт. Один стандарт для VCS и хранилищ документов.

2. Иерархия BR → SR → TR

Три уровня требований — каждый со своим вопросом и аудиторией.

BR
Бизнес-требование

Кто, что, зачем. Цели бизнеса, ограничения, KPI. Аудитория — стейкхолдеры и заказчик.

SR
Требование к системе

Что делает система. Функциональные и нефункциональные требования. Аудитория — архитекторы и разработчики.

TR
Требование к задаче

Что делает исполнитель. Цель и критерии приёмки в трекере (Jira, Linear, GitLab Issues), не как файл.

3. ADAPT — двусторонняя адаптация

Когда неизменяемое ТЗ встречается с реальностью реализации.

Прямая интерпретация (forward): ТЗ + контекст → BR / SR / SPEC.

Обратные находки (backward, 7 категорий): противоречия, пробелы, риски — возвращаются заказчику.

Двойная подпись клиент + архитектор фиксирует согласованную трактовку. ТЗ остаётся неизменяемым.

4. 9 типов SPEC (закрытый список)

Параллельная ось к требованиям через constrained-by[].

ARCH
Архитектура, компоненты, потоки
API
Контракты интерфейсов
DATA
Модель данных, миграции
INT
Интеграции
PROC
Бизнес-процессы
UI
Интерфейс, UX-критерии
AI
AI-компоненты, eval, fallback
SEC
Безопасность, threat model
OPS
Развёртывание, мониторинг, инциденты

5. Контрольные примеры (TC)

Не побочный продукт кода, а нормативный артефакт наравне с BR/SR.

  • →
    Парность сценариев: позитивный и негативный для каждого TC.
  • →
    VLM для UX: визуальные критерии через vision-language model.
  • →
    Типы по SPEC: TC-API, TC-AI, TC-SEC и др.
  • →
    Тег [test-spec-change]: явная пометка изменения TC.

6. Хранилище (substrate) и V1–V6

Один стандарт — любое хранилище с шестью возможностями (см. глава 3).

V1
Неизменяемая история
V2
Атомарная единица изменения
V3
Сравнение и ревью (diff & review)
V4
Ветвление и черновики (WIP)
V5
Закрепление версии (version pin)
V6
Автор и метка времени

7. Шлюзы качества QG-0..2

Контрольные точки жизненного цикла до перехода дальше.

QG-0 — шлюз утверждения
BR/SR/SPEC/TR с целью и критериями приёмки, утверждены архитектором.
QG-1 — шлюз реализации проверки
Для TC: реализация проверки готова (только TC имеет QG-1).
QG-2 — шлюз верификации
Обязательные тесты пройдены, evidence записан, критерии отмечены verified.

8. Зрелость RENAR-1..5

Пять уровней зрелости управления требованиями (см. глава 11).

RENAR-1
Стихийный (Ad-hoc) — хранилище есть, schema минимальна
RENAR-2
Зафиксированный (Documented) — frontmatter, ТЗ зафиксировано
RENAR-3
Учитываемый (Tracked) — полный schema, lifecycle, delta-ADAPT
RENAR-4
Верифицируемый (Verified) — pos/neg, QG-2, ai-provenance
RENAR-5
Оптимизирующий (Optimized) — adversarial critic, knowledge graph, метрики

9. Отношение к SENAR

SENAR — как делать AI-нативную разработку. RENAR — что делать: какие требования, в какой форме, с какими связями.

Можно применять RENAR без SENAR или наоборот; вместе — полное покрытие AI-нативной разработки.

Готовы погрузиться?

Полный стандарт Ядро — мягкое введение