01. Область применения¶
Часть RENAR Standard v1.0-draft · ← Оглавление
1.1 Где RENAR работает, а где нет¶
Две команды пишут код с AI-агентами. Первая делает банковский модуль по подписанному ТЗ: есть заказчик, приёмка, аудит — каждое требование надо уметь предъявить. Вторая на стартап-скорости проверяет гипотезы: «требование» сегодня есть, а после разворота завтра его нет. RENAR — для первой. Он создан там, где есть договорное ТЗ и сторона, перед которой за него отвечают: заказная разработка, регулируемые отрасли, консалтинг по чужому ТЗ. На чистом продуктовом дискавери — «сначала строим, потом понимаем, что строили» — RENAR не просто избыточен, он структурно неприменим: нет неизменяемого ТЗ, не из чего строить ADAPT. Эта глава проводит обе границы — предметную (что стандарт нормирует) и контекстную (когда им вообще стоит пользоваться) — закрытыми списками §1.2–§1.5.
Содержательные нормы артефактов и жизненного цикла глава не задаёт — это область глав 06–14; нативные для носителя механизмы реализации — область главы 3 и guide/03-tool-guide-*.md.
1.2 Что нормирует RENAR (закрытый список)¶
Закрытый список нормативных областей RENAR на версии v1.0. Каждая область рассматривается в указанной главе:
| # | Область | Глава |
|---|---|---|
| 1 | Иерархия требований (BR / SR / TR) | 06 |
| 2 | ADAPT (двусторонняя адаптация ТЗ): forward интерпретация + backward findings + двойная подпись | 07 |
| 3 | Закрытый список 9 типов спецификаций (SPEC-ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS) | 08 |
| 4 | Test Cases как полноценный артефакт (TC); pos/neg парность; spec-specific TC-обязательства | 09 |
| 5 | Состояния жизненного цикла + Quality Gates (QG-0 / QG-1 / QG-2 обязательные; QG-3 / QG-4 опциональные) | 10 |
| 6 | независимые от носителя возможности версионирования V1–V6 | 03 |
| 7 | Maturity model (RENAR-1..RENAR-5) | 11 |
| 8 | Метрики инженерии требований (RDLT, Hallucination Rate, DRA, ACR и др.) | 12 |
| 9 | Соответствие (обязательные положения, манифест, self-assessment, third-party assessment) | 13 |
| 10 | Роли и ответственность за артефакты (specializations над SENAR §4) | 05 |
Все перечисленные области имеют нормативное содержание: обязательные требования и запрет локальных для проекта расширений по соответствующим закрытым спискам.
1.2.1 Что относится к нормативной области¶
К нормативной области RENAR относятся:
- Модель данных артефактов — обязательные frontmatter поля, типы, enum-значения, инварианты согласованности.
- Состояния жизненного цикла + переходы — машины состояний per артефакт-тип; pre/post-conditions; gate-id для каждого перехода.
- Идентичность и происхождение — неизменяемые идентификаторы; нативная для носителя фиксация авторства и времени (V6); version pin между артефактами (V5).
- Cross-artifact constraints —
verifies[],constrained-by[],parent,delta-of,verified-by,implements-spec— нормативная семантика связей и правила консистентности. - AI-происхождение — обязательная фиксация модели-генератора, prompt-template, объёма tokens; правила human-edits для утверждения.
- Процедуры соответствия — обязательные положения, манифест-схема, периодичность оценки, обработка потери соответствия.
1.3 Что RENAR явно НЕ нормирует (закрытый список)¶
Закрытый список областей, которые намеренно оставлены за пределами стандарта. Реализация в этих областях — свободный выбор и не влияет на соответствие.
| # | Область | Что вне области |
|---|---|---|
| 1 | SENAR-методология в целом | 5 ценностей, 14 правил, общие Quality Gates, agent instrumentation — нормируются SENAR; RENAR не дублирует и не переопределяет. |
| 2 | Конкретный носитель / VCS | Выбор конкретного version-control / document-database / wiki-platform — на усмотрение реализации; RENAR нормирует только возможности V1–V6 (§3). |
| 3 | Tech stack реализации | Языки программирования, фреймворки, базы данных, инфраструктурные компоненты — вне области; RENAR нормирует требования, не реализацию. |
| 4 | Конкретный UI / IDE / редактор артефактов | Web-интерфейсы, IDE-расширения, CLI-инструменты — вне области; нормируется только формат хранения артефактов в носителе. |
| 5 | Конкретные test runners | pytest, jest, playwright, ragas, и др. — специфичны для носителя; RENAR нормирует только обязательность automation.location и last-run фиксации (V5+V6). |
| 6 | Бизнес-процессы продаж / договоров | Pre-sale, формулировка договорной стоимости, юридическая структура контрактов — вне области; RENAR работает с ТЗ как с входом и не нормирует процесс его создания на стороне клиента. |
| 7 | Project management practices | Agile-ceremonies, sprint planning, kanban-boards, story-points estimation — вне области; RENAR нормирует workflow артефактов требований, не management-overhead. |
| 8 | AI model selection и prompt engineering | Выбор LLM-провайдера, prompt-templates, fine-tuning стратегии — вне области; RENAR нормирует только обязательную фиксацию ai-provenance.generated-by и состязательный обзор (§9.4). |
| 9 | Конкретные нативные для носителя команды и hooks | специфичные для носителя CLI-команды (например, конкретные имена команд VCS), реализация hooks (§10.11) — специфичны для носителя и относятся к guide/03-tool-guide-*.md. |
| 10 | Юридическая интерпретация artifact-подписей | Электронная подпись, юридическая значимость, GDPR-обработка персональных данных в ТЗ — вне области стандарта; нормируется применимым законодательством. |
1.3.1 Принцип независимости от носителя¶
Нормативные главы стандарта RENAR используют независимую от носителя терминологию (§3.1). Зависящие от носителя имена (конкретные продукты, протоколы, команды) не появляются в нормативном тексте; они присутствуют только в guide/ (специфичные для носителя инструменты) и reference/ (примеры).
1.4 Область применимости (primary scope)¶
1.4.1 Контракт-ориентированная разработка¶
Нормативный primary-контекст RENAR — контракт-ориентированная разработка: проект, в котором:
- Существует ТЗ (явно сформулированное требование со стороны заказчика), которое после подписания становится неизменяемым (§7.4.1 ADAPT-source).
- Имеется идентифицируемая сторона клиента (заинтересованная сторона с полномочиями подписания, §5.3.6) — способная подтвердить acceptance (§10.4.2) и подписать ADAPT (§5.5).
- Реактивная двусторонняя client-side validation — состязательный обзор ТЗ обязателен; если обнаружены findings или требуется уточнение, forward интерпретация ТЗ обсуждается с клиентом через ADAPT (§7.3, §7.4.1). Если конвертация однозначна — validation сводится к зафиксированному вердикту «no findings» (без взаимодействия с клиентом).
- Delta-ТЗ workflow возможен — изменения scope формализуются через delta-ADAPT (§7.6), а не через скрытую переинтерпретацию.
- AI-агент доступен как primary author артефактов RENAR (§0.2.1). Без AI-агента стандарт остаётся применимым, но процессные издержки на ручное ведение артефактов с полным frontmatter, переходами жизненного цикла и графовыми связями делают соответствие RENAR непрактичным; команда либо принимает эти издержки, либо declared-stricter limit scope (§1.7.2) на критическое подмножество требований.
1.4.2 Типичные представители контракт-ориентированной разработки¶
| Контекст | Характеристики |
|---|---|
| Заказная разработка по ТЗ | Независимый vendor + идентифицируемый client; формальный договор; acceptance criteria. |
| Regulated industries | Compliance audit обязателен (медицина, финансы, госсектор); traceability requirements → tests → код требуется по нормативу. |
| Enterprise консалтинг | Third-party реализует по ТЗ клиента-корпорации; утверждение несколькими заинтересованными сторонами; журнал аудита. |
| Long-lived product с явным владельцем продукта | Владелец продукта играет роль представителя клиента для внутренних feature-ТЗ; внутренние SLA + audit обязательны. |
| Public-sector / government IT | Тендерные ТЗ; формальная приёмка; multi-year contracts. |
1.4.3 Spec-Driven Development (SDD) — современное имя¶
Контракт-ориентированная разработка с AI-ускорением — это форма Spec-Driven Development (§2.3.4). RENAR — нормативный стандарт для AI-native SDD; не альтернатива SDD, а его специализация в области управления требованиями.
1.5 Где RENAR неприменим (негативный scope)¶
RENAR нормативно неприменим в контекстах, где структурно отсутствуют предусловия §1.4.1. Заявление о соответствии RENAR (§13.4) для проектов в этих контекстах — несоответствующее (§13.8).
1.5.1 Lean startup / pure discovery¶
Продуктовая команда строит MVP в условиях неопределённости рынка; «требования» — гипотезы, валидируемые на пользователях, а не неизменяемые договорённости. Вне scope: отсутствует неизменяемое ТЗ (гипотезы перепроверяются после pivot); представитель клиента структурно отсутствует (внутренний продакт = автор + единоличный оценщик — нарушение §5.5.3); delta-ТЗ workflow не применим (pivot = смена scope целиком, не дельта). Lean startup команды могут заимствовать отдельные практики RENAR (AI-происхождение, состязательный обзор TC) без заявления о соответствии — допустимо как источник идей.
1.5.2 Pure R&D / исследовательские проекты¶
Научно-исследовательский проект без определённого результирующего scope (exploratory ML research, novel-algorithm prototyping без заказчика). Вне scope: ТЗ как неизменяемый артефакт отсутствует; acceptance criteria (QG-4 §10.4.2) не формализуемы — критерий «успеха» научного исследования не подписывается заранее; двойная подпись ADAPT неприменима.
1.5.3 Exploratory hackathon / proof-of-concept¶
Time-boxed exploratory работа без обязательной приёмки клиентом. Те же причины, что §1.5.1 + явный отказ от формальной приёмки.
1.5.4 Internal product без external client¶
Внутренний инструмент команды; «клиент» совпадает с автором; нет независимой заинтересованной стороны для двойной подписи ADAPT. При отсутствии независимого представителя клиента двойная подпись ADAPT (§5.5) структурно невозможна — client-signature.signed-by == architect-signature.signed-by нарушает §5.5.3. Это тот же базовый дефект, что в §1.5.1: структурное отсутствие двусторонности.
Реализация может локально применять подмножество практик RENAR (неизменяемые идентификаторы, состояния жизненного цикла, V1–V6 для собственной дисциплины), но не имеет права заявлять соответствие RENAR-N. Манифест либо не существует, либо явно декларирует «несоответствие».
Негативный сценарий: попытка объявить RENAR-N для internal product без независимого представителя клиента — несоответствующий (§13.8). Если внутренний продукт приобретает идентифицируемую заинтересованную сторону (внутренний Владелец продукта с полномочиями приёмки) — сценарий выходит из §1.5 в §1.4.2 «Long-lived product с явным владельцем продукта», применимо полное соответствие.
1.5.5 Негативные сценарии — конкретизация¶
| Сценарий | Почему несоответствующий |
|---|---|
| Проект без письменного ТЗ; требования — устные обсуждения | Нарушение §1.4.1 (1): ТЗ как неизменяемый артефакт отсутствует; ADAPT не имеет source (§7.4.1). |
| Проект с author == client (одно лицо подписывает обе стороны) | Нарушение §5.5.3 о двух независимых лицах в подписях ADAPT. |
| Проект, в котором scope пересматривается без формальной фиксации delta-ТЗ | Нарушение §7.6 delta-ADAPT workflow; нарушение §13.3 обязательное положение «ADAPT для каждого ТЗ». |
| Манифест объявляет tech-stack-specific требования (например, «обязательно использовать Python») | Нарушение §1.3 (3): tech stack вне scope стандарта; манифест несоответствующий. |
1.6 Связь с SENAR¶
1.6.1 RENAR как специализация SENAR¶
SENAR — методологическая база: 5 ценностей AI-native разработки, 14 правил, агенты-инструкции, общие Quality Gates (§10.2.3), 5 базовых ролей (§5.2).
RENAR — специализация SENAR в области инженерии требований: нормирует только те аспекты, которые SENAR оставляет на усмотрение доменного стандарта (модель данных артефактов, жизненный цикл, манифест соответствия). RENAR не дублирует SENAR и не переопределяет SENAR-конструкции.
1.6.2 Совместимость¶
Соответствующая RENAR реализация всегда является SENAR-совместимой. Обратное — не обязательно: SENAR-совместимый проект может не заявлять соответствие RENAR, если работает вне primary scope §1.4.
Несовместимость RENAR с SENAR в любой нормативной точке — баг стандарта RENAR; разрешается через формальную процедуру изменения стандарта SENAR с согласующей правкой в RENAR.
1.6.3 RENAR не альтернатива SENAR¶
Реализация не имеет права заявить «следуем RENAR вместо SENAR» — это нарушение §1.6.1. RENAR используется поверх SENAR; манифест соответствия проекта объявляет одновременно SENAR-version и RENAR-version (§13.4).
1.7 Политика закрытого списка (закрытый список)¶
1.7.1 Что закрыто на v1¶
Списки §1.2 (нормативные области), §1.3 (исключения), §1.4 (primary scope), §1.5 (negative scope) — закрытые. Локальные для проекта расширения и попытки нормировать через манифест исключённые области (§1.3 (3) tech stack, §1.3 (7) PM practices) — несоответствующий. Добавление новых primary-контекстов или перевод сценария из §1.5 в §1.4 — только через формальную процедуру изменения стандарта.
1.7.2 Declared-stricter допустимо¶
Реализация может ужесточить scope относительно нормативного минимума, явно декларируя в манифесте соответствия (§13.4) с маркером declared-stricter (§10.10.2): применять RENAR только к подмножеству требований (security-critical SR); требовать дополнительные artifact-типы (threat-models); запретить RENAR без представителя Клиента. Declared-stricter — допустимая локальная политика; соответствие нормативному уровню сохраняется.
1.7.3 Declared-weaker запрещено¶
Реализация не имеет права declared-weaker относительно §1.2 / §1.3 / §1.4: объявить соответствие RENAR для проекта в §1.5 negative scope; применять RENAR без ADAPT (нарушение §13.3.3); нормировать через локальный для проекта манифест исключённые области §1.3.
1.7.4 Путь расширения¶
Изменение §1.2 / §1.3 / §1.4 / §1.5 — только через формальную процедуру изменения стандарта (§13.9): исследовательский черновик с обоснованием → публичное обсуждение → повышение minor- или major-версии → руководство по миграции для существующих соответствующих проектов.
1.7.5 Master list of closed lists в RENAR¶
Настоящий параграф — единый индекс всех закрытых списков стандарта RENAR. Каждый перечисленный список нерасширяем локально на уровне проекта; изменения возможны только через формальную процедуру изменения стандарта (§13.9). Канонический источник для каждого списка — в указанной секции; остальные упоминания являются cross-references.
| # | Закрытый список | Канонический источник | Cross-refs |
|---|---|---|---|
| 1 | Нормативные области стандарта (10 пунктов) | §1.2 | §1.7.1 |
| 2 | Исключения из нормативной области (10 пунктов) | §1.3 | §1.7.1 |
| 3 | Primary scope: контексты применимости (4 признака + 5 типичных представителей) | §1.4 | §1.7.1 |
| 4 | Negative scope: контексты неприменимости (5 контекстов + 4 negative scenario) | §1.5 | §1.7.1 |
| 5 | Роли RENAR (specializations над SENAR §4) | §5 | §1.2 (10) |
| 6 | Категории backward findings ADAPT (7 категорий) | §7.4.4 | §13.3.7 |
| 7 | Типы спецификаций SPEC-* (9 типов: ARCH/API/DATA/INT/PROC/UI/AI/SEC/OPS) | §8.3 | §4.4.1, §13.3.4 |
| 8 | Нормативные принципы TC (закрытый список) | §9.2 | §13.3 |
| 9 | Типы TC (tc-type: 6 значений) |
§9.5 | §4.5.2 |
| 10 | Состояния жизненного цикла по типам артефактов (BR / SR / SPEC / TC / ADAPT / ТЗ) | §10.5–§10.8 | §4.7–§4.10 |
| 11 | Quality Gates: обязательные {QG-0, QG-1, QG-2}, опциональные {QG-3, QG-4} | §10.3, §10.4 | §10.10, §13.3.6 |
| 12 | независимые от носителя возможности версионирования V1–V6 | §3.x | §1.2 (6) |
| 13 | Уровни maturity RENAR-1..RENAR-5 (5 уровней) | §11.3 | §13.2, §13.9 |
| 14 | REQ-специфичные метрики (10 метрик) | §12.3 | §12.5 |
| 15 | Drift classes (нарушения требовательной инфраструктуры) | §4.11 | §4.2 |
| 16 | Запрещённые / устаревшие термины (non-canonical) | §4.14 | §4.2 |
Расширение любого закрытого списка проходит ту же формальную процедуру, что и изменение §1.2–§1.5 (§1.7.4, §13.9).
Политики закрытого списка на уровне глав (§10.10, §12.3, §13.9) являются специализациями настоящего §1.7 для соответствующих списков и не вводят независимых процедур.
1.8 Перекрёстные ссылки¶
| Источник | Применение |
|---|---|
| SENAR (полная методология) | Методологическая база RENAR (§1.6.1); RENAR не дублирует SENAR-нормы. |
| §5 Roles | Владение артефактами и роли — specializations над SENAR §4 (§1.2 (10), §1.6.1). |
| §2 Methodology positioning | Три фундаментальных утверждения (инверсия источника истины, waterfall-form ≠ classical waterfall, независимое от носителя версионирование) — обоснование scope §1.4. |
| §7 ADAPT | ADAPT как нормативное требование §1.4.1 (3) двусторонней client-side validation. |
| §10 Жизненный цикл и QG | Жизненный цикл + Quality Gates — нормативная область §1.2 (5). |
| §3 Версионирование носителя | возможности V1–V6 — нормативная область §1.2 (6); принцип независимости от носителя §1.3.1. |
| §13 Соответствие | Обязательные положения, манифест, потеря соответствия — нормативная область §1.2 (9); negative scenarios §1.5.5. |
core/renar-core.md |
Core-mode boundary case для §1.5.4 (internal product без external client). |
guide/02-transition-guide.md |
Practical guidance для проектов, переходящих с lean-стиля на контракт-ориентированную разработку (специфично для носителя). |
← Предыдущая: 00. Введение · Оглавление · Следующая: 02. Положение в типологии методологий →