01. Область применения¶
Часть RENAR Standard v1.1 · ← Оглавление
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 + подпись архитектора; ACTZ (протокол уточнения ТЗ) с двусторонней подписью | 07 |
| 3 | Закрытый список 12 типов спецификаций (SPEC-ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS / TEST / DOC / UC) | 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-значения, инварианты согласованности.
- Состояния жизненного цикла + переходы — машины состояний комплекта описания, задачи, ADAPT и реализации TC (§10.7); 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, п. 7). Любой порядок работ, при котором предусловия выполнены, соответствует стандарту; последовательность, приведённая в руководстве или примере, — один из возможных порядков, а не норма. Организация вправе добавлять свои артефакты и правила — это declared-stricter (§1.7.2), пока не нарушены закрытые списки и предусловия.
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 нормирует жизненные циклы артефактов и предусловия их переходов (§1.2.1), не порядок работ (текст пункта уточнён в v1.1, ADR-027). |
| 8 | AI model selection и prompt engineering | Выбор LLM-провайдера, prompt-templates, fine-tuning стратегии — вне области; RENAR нормирует только обязательную фиксацию блока ai-provenance в составе §4.10.1 — включая prompt-template как указатель с версией, но не содержание шаблона — и состязательный обзор (§7.10.2). |
| 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) — способная подтвердить приёмку (§10.4.2) и подписать ACTZ (§5.5).
- Реактивная двусторонняя client-side validation — состязательный обзор ТЗ обязателен; если обнаружены findings или требуется уточнение, вопросы выносятся клиенту протоколом ACTZ (§7.13), а его решения фиксируются в 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.4.4 Подтверждение первой стороной — концепт на входе¶
Отдельный вид применимости, добавленный в v1.1 (§13.9): внешнего заказчика нет, и его роль никто не имитирует. Признаки:
- Вход — концепт, а не ТЗ: письменное описание будущей системы, составленное ответственным лицом организации и замороженное им (V6 автор и отметка времени). Концепт занимает место ТЗ как источник (
source.tz-sectionуказывает на его раздел) и получает те же обязанности неизменяемости (§7.4.1). - Контрактный контур не возникает. ACTZ (§5.5, §7.13) беспредметен — выносить решения некому; двусторонняя подпись не имитируется одним лицом. Обратная находка, требующая решения по концепту, закрывается пересмотренным разделом концепта, подписанным тем же ответственным лицом:
decided-inуказывает на него (§7.4.5). - Состязательный обзор обязателен без исключений (§7.4.1, §13.3.3): он — единственная независимая проверка в этом виде, поэтому AR с вердиктом «находок нет» обязана нести предъявимое обоснование, модель рецензента фиксируется, а ACR (§12.3.6) ведётся обязательно.
- Предъявление — против концепта. Релизный гейт AT (§10.4.3) беспредметен: AT выводятся из контракта, которого нет. Готовность предъявляется записью верификации версии комплекта (QG-2, §10.3.3) с подписью ответственного лица; записи ручного прохода по сценариям (§9.20) — дополнительный канал обнаружения, в доказательство готовности не входят.
- Маркировка вида применимости. Манифест объявляет
confirmation: first-party(§13.4.2); заявление о соответствии — подтверждение первой стороной в смысле ISO/IEC 17050-1, не приёмка второй стороной.
Вид ортогонален уровню зрелости: потолка RENAR-N он не задаёт. Появление идентифицируемой заинтересованной стороны с полномочиями приёмки переводит проект в контракт-ориентированный вид (§1.4.1) отзывом декларации; ретроспективная переоценка не требуется.
Совмещение ролей в этом виде — норма, а не отклонение: одно лицо может совмещать роли (§5.5.5); состязательная проверка людьми при этом отсутствует, и это принимаемый компромисс, который стандарт не компенсирует дополнительными механизмами, а честно называет.
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: ТЗ как неизменяемый артефакт отсутствует; критерии приёмки (QG-4 §10.4.2) не формализуемы — критерий «успеха» научного исследования не подписывается заранее; двусторонняя подпись ACTZ неприменима.
1.5.3 Exploratory hackathon / proof-of-concept¶
Time-boxed exploratory работа без обязательной приёмки клиентом. Те же причины, что §1.5.1 + явный отказ от формальной приёмки.
1.5.4 Internal product без ответственного лица и письменного концепта¶
Внутренний инструмент, у которого нет ни ответственного лица, готового заморозить концепт и подписать подтверждение первой стороной (§1.4.4), ни самого письменного концепта: требования живут в обсуждениях, «клиент» не назван. Отсутствие внешнего заказчика само по себе из области применимости не выводит — выводит отсутствие лица, отвечающего за описание. Имитация двусторонней подписи ACTZ одним лицом (client-signature.signed-by == vendor-signature.signed-by) остаётся нарушением §5.5.3: правильный путь — вид §1.4.4, где ACTZ беспредметен.
Реализация может локально применять подмножество практик RENAR (неизменяемые идентификаторы, состояния жизненного цикла, V1–V6 для собственной дисциплины), но не имеет права заявлять соответствие RENAR-N. Манифест либо не существует, либо явно декларирует «несоответствие».
Негативный сценарий: попытка объявить RENAR-N для internal product, у которого нет ни замороженного концепта, ни ответственного лица, — несоответствующий (§13.8). Если у продукта появляется ответственное лицо и письменный концепт — сценарий выходит из §1.5 в §1.4.4 (подтверждение первой стороной); если появляется идентифицируемая заинтересованная сторона с полномочиями приёмки — в §1.4.2 «Long-lived product с явным владельцем продукта», применимо полное соответствие.
1.5.5 Негативные сценарии — конкретизация¶
| Сценарий | Почему несоответствующий |
|---|---|
| Проект без письменного ТЗ; требования — устные обсуждения | Нарушение §1.4.1 (1): ТЗ как неизменяемый артефакт отсутствует; ADAPT не имеет source (§7.4.1). |
| Проект без второй стороны, в котором одно лицо подписывает ACTZ за обе стороны | Нарушение §5.5.3: двусторонняя подпись не имитируется; без второй стороны ACTZ беспредметен, применяется вид §1.4.4 с confirmation: first-party. |
| Проект, в котором scope пересматривается без формальной фиксации delta-ТЗ | Нарушение §7.6 delta-ADAPT workflow; нарушение §13.3 обязательное положение §13.3.3 «реактивный ADAPT: состязательный обзор на каждое ТЗ, 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: контексты применимости (5 признаков + 5 типичных представителей; вид «подтверждение первой стороной» §1.4.4 с 5 признаками, v1.1) | §1.4 | §1.7.1 |
| 4 | Negative scope: контексты неприменимости (4 контекста + 4 негативных сценария; §1.5.4 и сценарий 2 переопределены в v1.1) | §1.5 | §1.7.1 |
| 5 | Роли RENAR (specializations над SENAR §4) | §5 | §1.2 (10) |
| 5bis | Типы оси требований (3 типа: BR / SR / TR) | §6.2 | §13.3 |
| 5ter | Уровни декомпозиции (3: система / подсистема / модуль) | §6.3 | §6.4, §4.9 |
| 6 | Категории backward findings ADAPT (7 категорий) | §7.4.4 | §13.3.7 |
| 7 | Типы спецификаций SPEC-* (12 типов: ARCH/API/DATA/INT/PROC/UI/AI/SEC/OPS/TEST/DOC/UC) | §8.3 | §4.4.1, §13.3.4 |
| 8 | Нормативные принципы TC (закрытый список, P1–P9) | §9.2 | §13.3 |
| 9 | Типы TC (tc-type: 6 значений; business вместо прежнего acceptance) |
§9.5 | §4.5.2 |
| 10 | Состояния жизненного цикла по объектам: комплект описания (draft / approved / superseded), TR, ADAPT, реализация TC; BR / SR / SPEC / TC-норма собственных состояний не имеют |
§10.5–§10.9 | §4.7–§4.10 |
| 11 | Quality Gates: обязательные {QG-0, QG-1, QG-2}, опциональные {QG-3, QG-4} — переходы комплекта описания, TR, ADAPT и допуск реализации TC | §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-специфичные метрики (11 метрик) | §12.3 | §12.5 |
| 15 | Drift classes (нарушения требовательной инфраструктуры) | §4.11 | §4.2 |
| 16 | Запрещённые / устаревшие термины (non-canonical) | §4.14 | §4.2 |
| 17 | Модальные операторы языка описания (5: должен / не должен / следует / не следует / допускается; введён v1.1 по §13.9) | §15.2 | §11.5 |
Расширение любого закрытого списка проходит ту же формальную процедуру, что и изменение §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 |
Концептуальный обзор стандарта для человека-читателя (не нормативный). |
guide/02-transition-guide.md |
Practical guidance для проектов, переходящих с lean-стиля на контракт-ориентированную разработку (специфично для носителя). |
← Предыдущая: 00. Введение · Оглавление · Следующая: 02. Положение в типологии методологий →