03. Terms and definitions
Часть RENAR Standard v1.0-draft · ← Оглавление
3.1 Назначение главы
Глава нормирует canonical терминологию RENAR: одно определение на одну концепцию; единый источник истины для других глав, реализационных substrate, конформант-инструментов. Терминологический drift (§3.11.5) — отдельный класс нарушений conformance (§14.3.1 косвенно).
Глава фиксирует:
- Артефакты требований и спецификаций (§3.3–§3.5): BR, SR, TR, ADAPT, SPEC-*, TC и их типы.
- Lifecycle статусы (§3.6) — закрытый список per тип артефакта.
- Quality Gates (§3.7) — canonical из §10.3.
- Substrate термины (§3.8) — V1–V6 capabilities и сопутствующие понятия.
- Системная иерархия (§3.9) — система / подсистема / модуль.
- Provenance термины (§3.10) — ai-provenance, source-citation, traceability chain.
- Drift классы (§3.11) — closed list нарушений требовательной инфраструктуры.
- Connection terms (§3.12) — поля frontmatter, фиксирующие связи между артефактами.
- Mapping на родственные стандарты (§3.13) — SENAR, ISO/IEC 29148, BABOK, SAFe.
- Запрещённые / устаревшие термины (§3.14) — closed list non-canonical.
- Authority (§3.15) — порядок разрешения разногласий.
Глава не дублирует reference/01-glossary.md: эта глава содержит canonical normative определения короткой формы; reference/01 — развёрнутые объяснения с anti-patterns, history, и industry context (информационный материал).
3.2 Принцип canonical-only
RENAR выбирает один canonical термин на одну концепцию. Внутри substrate (frontmatter, ID, body normative paragraphs, scripts, CI hooks) используется только canonical. Mapping на родственные стандарты (§3.13) — для документации, migration, и интеграции с внешними системами; внутри substrate замены canonical на mapping-эквивалент не происходит.
При обнаружении non-canonical термина (по §3.14) в normative artefact — substrate-нативный hook (§10.11.1) обязан выдать warning при change-set; для RENAR-4+ (§12.7) — blocking error.
Multilingual проекты могут отображать canonical терминологию в UI на язык клиента (§3.13.3); это UI-перевод, не canonical-замена.
3.3 Артефакты требований
3.3.1 ТЗ — Техническое задание
ТЗ (TZ-YYYY-NNN) — immutable (§7.4.2) договорный артефакт, фиксирующий обязательства между клиентом и инженерной командой. После регистрации в substrate не редактируется. Изменения — через delta-ТЗ как новый immutable артефакт (§7.6).
3.3.2 ADAPT — Bridge artifact
ADAPT (ADAPT-NNN) — обязательный bridge artefact (§7.4.1) между ТЗ и иерархией требований. Содержит forward (инженерная интерпретация) + backward (вопросы клиенту) разделы. Каждое ТЗ обязано иметь ровно один корневой ADAPT в статусе approved (§14.3.3). Lifecycle: §3.6.4.
3.3.3 BR — Business Requirement
BR (BR-NN) — артефакт бизнес-уровня. Описывает наблюдаемый бизнес-эффект (business-outcome), а не способ его достижения. Декомпозируется в SR. Frontmatter — §6.5.2. Lifecycle: §3.6.1.
3.3.4 SR — System Requirement
SR (SR-NN) — артефакт системного уровня. Описывает обязательное поведение системы в рамках одного бизнес-эффекта. Имеет родительский BR (parent: BR-N) или родительский SR (при level: subsystem или level: module — §6.7). Frontmatter — §6.6.2. Lifecycle: §3.6.1.
3.3.5 TR — Task Requirement
TR (TR-NN) — артефакт уровня задачи исполнителя. Описывает actionable работу с goal + AC. Имеет родительскую цепочку implements: SR-N (или BR для тривиальных задач). Frontmatter — §6.7.2. Lifecycle: §3.6.2.
3.3.6 Иерархия
Иерархия требований:
ТЗ → ADAPT → BR → SR → TR → реализация
│
└── SPEC-* (параллельная ось, §3.4)SR может реализовывать SPEC через implements-spec[] (§8.6.2) — это связь, а не parent-edge.
3.4 SPEC артефакты
SPEC — артефакт структурного описания системы как параллельная ось требований (§8.2). Не parent-edge с SR; связан через constrained-by[] / implements-spec[] (§8.6). Lifecycle: §3.6.3.
3.4.1 Closed list 9 типов SPEC
Закрытый список (§8.3):
| Тип | Назначение |
|---|---|
SPEC-ARCH | Архитектура системы (контексты, контейнеры, компоненты, deployment view, quality attributes) |
SPEC-API | API contracts (REST / GraphQL / gRPC / async events) |
SPEC-DATA | Data model (schema, ERD, migrations, retention, PII classification) |
SPEC-INT | Integration (взаимодействие между подсистемами и внешними системами) |
SPEC-PROC | Process / workflow (бизнес-процессы, state machines, saga) |
SPEC-UI | UI / UX (экраны, навигация, accessibility, baselines) |
SPEC-AI | AI / ML (model cards, RAG, prompt engineering, eval strategy) |
SPEC-SEC | Security (authn / authz, threat model, secrets management) |
SPEC-OPS | Operations (deployment, observability, SLO/SLA, runbook) |
Project-local создание новых типов SPEC запрещено (§14.3.4).
3.5 Артефакты тестирования
3.5.1 TC — Test Case
TC (TC-NN) — артефакт верифицируемого критерия. Покрывает нормативные утверждения BR / SR / SPEC (через verifies[] с version pin, §9.4). Lifecycle: §3.6.5.
3.5.2 Closed list типов TC (tc-type)
Закрытый список (§9.5):
tc-type | Назначение |
|---|---|
acceptance | E2E-тесты бизнес-цели для BR (§9.5); runner-family: E2E + AI-валидатор |
ux | UX-тесты с VLM-judge (§9.6.1) для SPEC-UI |
system | Системные тесты общего назначения для SR / SPEC-PROC / SPEC-ARCH (§9.5) |
contract | Контрактные тесты (§9.6.3) для SPEC-API / SPEC-INT / SPEC-DATA |
eval | Eval-тесты для SPEC-AI с LLM-judge (§9.6.2); judge-модель обязана отличаться от модели реализации |
security | Security-тесты (§9.6.4) для SPEC-SEC по STRIDE-категориям |
3.5.3 Pos / neg парность
Нормативное требование (§9.7): каждое нормативное утверждение покрывается парой TC (positive scenario + negative scenario). Single-TC-coverage допускается только для утверждений-инвариантов (security STRIDE).
3.6 Lifecycle статусы
3.6.1 BR / SR
Закрытый список (§10.5): draft → approved → verified → accepted → deprecated. accepted — терминальный недеградируемый (§10.4.2, опционально); deprecated — терминальный.
3.6.2 TR
Закрытый список (§10.6): draft → approved → done; obsolete — альтернативный терминальный.
3.6.3 SPEC
Закрытый список (§10.7): draft → review → approved → verified; obsolete — терминальный.
3.6.4 ADAPT
Закрытый список (§10.8): draft → review → client-ready → answered → approved → frozen. frozen — терминальный immutable; изменения только через delta-ADAPT или errata.
3.6.5 TC
Закрытый список (§10.9): draft → ready → passing / failing → obsolete. passing ↔ failing — runner-managed transitions (§10.9.3), не gate-passages.
3.6.6 Backward findings (sub-state в ADAPT)
Закрытый список (§7.4.5): open → asked-to-client → answered → resolved → frozen; revised — возврат в asked-to-client.
3.6.7 Закрытые списки lifecycle — нерасширяемы project-local
Любой статус вне закрытого списка для соответствующего типа артефакта — нарушение conformance (§10.10.2).
3.7 Quality Gates
Canonical список из §10.3 + §10.4. Project-local создание новых gate-типов запрещено (§10.10.2, §14.3.6).
| Gate | Назначение | Статус conformance |
|---|---|---|
QG-0 — Approval (§10.3.1) | Approval артефакта для разработки / реализации | Required |
QG-1 — Implementation (§10.3.2) | Implementation valid (только для TC draft → ready) | Required |
QG-2 — Verification (§10.3.3) | Promote артефакта в verified | Required |
QG-3 — Architecture (§10.4.1) | Approval ADAPT (двойная подпись) / SPEC-ARCH | Опционально (declared или absent) |
QG-4 — Acceptance (§10.4.2) | Приёмка BR в accepted | Опционально |
Runner-managed transitions (ready → passing, passing → failing, и иные) — не Quality Gates (§10.9.3).
3.8 Substrate термины
3.8.1 Substrate
Substrate — система хранения и версионирования артефактов RENAR. Substrate-agnostic в смысле тоого, что RENAR нормирует capabilities (§3.8.2), не tools.
3.8.2 Capabilities V1–V6
Закрытый список из §11.3. Все шесть обязательны абсолютно для conformance (§14.3.2):
| Capability | Семантика |
|---|---|
V1 — Immutable history | Любое прошлое состояние артефакта восстановимо |
V2 — Atomic change unit | Изменения фиксируются как «всё или ничего» |
V3 — Diff & review | Предложенное изменение представимо как diff против baseline и проходит approve до интеграции в SoT |
V4 — Branching / change-set | WIP отделим от утверждённой правды; параллельные изменения независимы |
V5 — Cross-substrate version pin | Cross-substrate ссылка фиксирует конкретную версию артефакта |
V6 — Author + timestamp | Каждая atomic change unit имеет идентифицируемого author и timestamp ≥ секундной точности |
3.8.3 Atomic change unit
Изменение substrate (V2), удовлетворяющее свойству «всё или ничего» — substrate-нативная транзакция; промежуточные несогласованные состояния не наблюдаемы наружу. Конкретная substrate-native реализация (атомарная запись в distributed VCS, transaction в document store, иной механизм) — substrate-specific; описание форм выносится в guide/.
3.8.4 Version pin
Substrate-нативный механизм (V5), фиксирующий конкретную версию артефакта одного substrate из другого substrate через pair (artifact-id, version-id).
3.8.5 Audit trail
Substrate-нативная append-only коллекция событий gate-passage и transitions (§10.13). Каждое событие содержит timestamp, artifact-id, artifact-version, from-status, to-status, gate-id, actor, evidence-refs. Удаление не допускается (V1 retention, §10.13.3).
3.9 Системная иерархия
Закрытый список уровней (§6.7, §6.8):
| Уровень | Назначение |
|---|---|
system | Весь продукт целиком; верхний уровень; редко используется (кросс-подсистемные задачи) |
subsystem | Подсистема (например, отдельный сервис, фронтенд-приложение) |
module | Модуль внутри подсистемы |
Поле level фиксируется во frontmatter артефакта (BR / SR / TR). Иерархия может расширяться вниз через эволюцию подсистема → модуль (§6.9.1) или обратно (§6.9.3).
3.10 Provenance термины
3.10.1 ai-provenance
Frontmatter-блок (§12.7.1, RENAR-4 mandatory) фиксирующий происхождение AI-генерируемого артефакта. Обязательные поля:
| Поле | Семантика |
|---|---|
ai-provenance.generated-by | Идентификатор модели (<vendor>-<model>-<version>@<date>) |
ai-provenance.generated-at | UTC timestamp генерации |
ai-provenance.prompt-template | Substrate-native pointer на prompt template |
ai-provenance.context-tokens / output-tokens | Численные метрики |
ai-provenance.human-edits | Boolean — были ли ручные правки после генерации |
ai-provenance.cost-budget / cost-actual | Метрики затрат (источник для §13.3.9) |
3.10.2 Source citation
Inline pointer в body артефакта (RENAR-4 mandatory, §12.7.1) на источник конкретного нормативного утверждения. Формат — substrate-specific; типичные паттерны: [TZ-XXX §Y line Z], [ADAPT-NNN §A.B], маркер derived с pointer’ом на parent-артефакт.
3.10.3 Traceability chain
Цепочка артефактов от ТЗ до прогона TC, фиксирующая происхождение каждого assertions:
ТЗ → ADAPT → BR → SR → TR / SPEC → TC.last-runКаждое звено связано через canonical frontmatter-поля (§3.12). Traceability chain — source of truth для compliance audit (§13.5.3).
3.11 Drift классы (closed list)
Закрытый список восьми классов нарушений требовательной инфраструктуры. Изменение списка — formal change procedure (§14.9.3). Substrate-нативный hook (§10.11.1) обязан обнаруживать каждый класс на соответствующей точке enforcement.
| # | Класс | Что нарушено | Точка enforcement |
|---|---|---|---|
| 3.11.1 | Schema drift | Frontmatter артефакта не соответствует обязательной schema гл. 06/08/09 | Substrate hook на change-set; RENAR-3+ — blocking (§12.6.1) |
| 3.11.2 | Lifecycle drift | Артефакт вне closed list статусов (§3.6) или прошёл forbidden transition (§10.12) | Substrate hook на promote-transition |
| 3.11.3 | Source-of-truth drift | Реализационный код / derived артефакт расходится с SR / SPEC, на который ссылается через verifies[].version (V5) | Reconciliation hook RENAR-4+; регистрация как backward finding в delta-ADAPT |
| 3.11.4 | Implementation drift | Реализационный substrate перестал ссылаться на актуальную version requirements substrate (V5 pin устарел) | Auto-invalidate verified (§10.5.4) |
| 3.11.5 | Terminological drift | Использование non-canonical термина (§3.14) в normative artefact | Substrate hook на change-set; RENAR-4+ — blocking |
| 3.11.6 | Order / provenance drift | Артефакт ссылается на источник в более низком статусе чем требует §10.3.1 reference-validation | Substrate hook (§10.11.1) блокирует change-set |
| 3.11.7 | TC ↔ requirement provenance drift | TC потеряло verifies[] ссылку или last-run.requirement-version не совпадает с текущей version | Runner-managed: TC переводится в failing (§10.9.3) до повторного прогона |
| 3.11.8 | Test-fitting drift | Pass / Fail-критерии TC изменены одновременно с implementation-кодом, чтобы failing TC стал passing без устранения корня (§9.13) | Substrate hook через [test-spec-change] маркер; единое лицо не может одобрить оба change-set (§10.11.3) |
3.12 Connection terms (frontmatter fields)
Canonical имена полей, фиксирующих связи между артефактами:
| Поле | Артефакт-источник | Семантика |
|---|---|---|
parent | BR / SR | Один родитель в иерархии (BR-NN или SR-NN) |
children[] | BR / SR | Auto-derived обратное ребро (§6.x) |
implements | TR | Цепочка реализации (SR-N или BR-N) |
implements-spec[] | TR | Реализация спецификаций SPEC-* (§8.6.2) |
constrained-by[] | SR | Ограничения от SPEC-* (§8.6.1) |
depends-on[] | SPEC | Граф зависимостей между SPEC (§8.6.3) |
verifies[] | TC | Закрытый список верифицируемых артефактов с version (§9.4) |
verified-by[] | BR / SR / SPEC | Auto-derived обратное ребро от verifies[] |
source.adapt | BR / SR / SPEC | ADAPT, из которого выведен артефакт |
replaces / replaced-by | Любой | Замена при deprecation (§10.5.3) |
supersedes | Новая версия артефакта | Какой артефакт заменяется (взамен «реанимации» obsolete) |
last-run | TC | Результат последнего прогона runner’а (§9.12); bot-managed only |
Полная schema каждого артефакта — в reference/02-schemas.md.
3.13 Mapping на родственные стандарты
3.13.1 Артефакты требований
| RENAR canonical | SENAR (RU) | ISO/IEC 29148 | BABOK v3 | SAFe |
|---|---|---|---|---|
BR (Business Requirement) | БТ (Бизнес-требование) | Business Requirement | Business Need | Portfolio Epic / Strategic Theme |
SR (System Requirement) | СТ (Системное требование) | System Requirement / Software Requirement | Solution Requirement (Functional) | Feature |
TR (Task Requirement) | ТЗ (Требование к задаче) | Implementation Requirement | Transition Requirement | Story |
ADAPT | (RENAR-extension) | (n/a — formalised bridge artefact) | Stakeholder Requirement workshop output | (n/a) |
TC (Test Case) | ТК | Test Case (verifiable item) | Verification artefact | Story acceptance test |
SPEC-* (9 types) | (RENAR-extension) | Design Description (subset) | Solution Component (subset) | Enabler tech spec (subset) |
3.13.2 Lifecycle статусы
| RENAR canonical | ISO/IEC 29148 | CMMI |
|---|---|---|
draft | proposed | identified |
approved | agreed-to / baselined | committed |
verified | verified | validated |
accepted | accepted | accepted |
deprecated / obsolete | retired / superseded | obsolete / superseded |
3.13.3 Multilingual UI
Multilingual проекты могут отображать canonical терминологию в UI на язык клиента (RU пример):
| English (canonical) | Russian (UI-перевод) |
|---|---|
| Business Requirement | Бизнес-требование |
| System Requirement | Системное требование |
| Test Case | Тест-кейс |
| Quality Gate | Контрольная точка качества |
| Acceptance | Приёмка |
| Verified | Проверено |
| Approved | Утверждено |
| Deprecated | Устарело |
Это только UI-перевод. Frontmatter, ID, имена файлов, body normative paragraphs — всегда canonical латиница / canonical RU из этой главы.
3.14 Запрещённые / устаревшие термины
Closed list non-canonical терминов; substrate hook RENAR-4+ — blocking при обнаружении в normative artefact (§3.2).
| Запрещённый термин | Canonical замена | Почему |
|---|---|---|
| «User Story» как требование | SR | Story — единица планирования, не требование; story может реализовывать SR через implements |
| «Use Case» (формально как артефакт) | SPEC-UI + SR | Use case mixes UX и behavior; RENAR разделяет SPEC-UI (UX) и SR (поведение) |
| «Spec» (как родовой термин) | Конкретный SPEC-* или requirement / SR | «Spec» неоднозначно; используем точные термины |
| «Бизнес-логика» | SR | Термин кода, не требований |
| «Функциональность» | SR / TR | Слишком широкое |
| «Фича» / «Feature» (как требование) | BR (бизнес-уровень) или Feature в SAFe-context (не RENAR canonical) | Mixed Russian / English; RENAR использует BR |
| «Хотелка» | (никогда) | Договорный документ так не пишется |
| «Эпик» (как требование) | BR (бизнес-уровень) | Epic — единица планирования, не требование |
3.14.1 Устаревшие RENAR-specific labels
При migration с pre-v1.0 RENAR / Andersen Stack draft material встречаются устаревшие labels:
| Устаревший label | Canonical v1.0 замена |
|---|---|
UIC (UI Concept) | SPEC-UI (§8.5.6) |
AIC (AI Concept) | SPEC-AI (§8.5.7) |
TS (Technical Specification) | SPEC-ARCH или SPEC-OPS в зависимости от содержания |
INT-SR (Integration SR) | SR с constrained-by: [SPEC-INT-N] |
INT-TC (Integration TC) | TC с tc-type: contract |
TM (Module/Submodule SR) | SR с level: module (§6.7) |
QG-0 Context Gate (старое) | QG-0 Approval (canonical v1.0, §10.3.1) |
QG-1 Requirements Gate (старое) | QG-1 Implementation (canonical v1.0, §10.3.2) — semantic shift: ранее approval BR/SR, теперь только TC draft → ready |
QG-2 Implementation Gate (старое) | QG-1 Implementation (canonical v1.0, §10.3.2) |
QG-3 Verification Gate (старое) | QG-2 Verification (canonical v1.0, §10.3.3) |
Migration существующего requirements substrate со старыми labels — отдельный one-time процесс; substrate-нативный hook на change-set должен auto-detect устаревшие labels и предлагать canonical замены.
3.15 Authority
При разногласиях по термину порядок обращения:
- Эта глава (§3) — canonical для RENAR-стандарта.
- Соответствующая глава стандарта (06–14) — для специфичной семантики артефактов (например, ADAPT-специфика — в §7).
- SENAR §3 (терминология родительского стандарта).
- ISO/IEC 29148:2018 — для общеинженерной терминологии requirements.
- BABOK v3 — для business-аналитики терминов.
- Фиксация через formal change procedure стандарта (§14.9.3) — если все вышеперечисленные молчат.
Не использовать как источник терминологии:
- Тикеты ticket-систем (часто противоречивые).
- Чаты команды (slang ≠ canonical).
- Презентации и старые draft-материалы.
- Маркетинговые материалы.
3.16 Связь с другими главами
| Глава | Связь |
|---|---|
| 05 Положение в типологии методологий | §5.3 SoT inversion + §5.5 substrate-agnostic versioning — фундамент для §3.8 substrate терминов |
| 06 Иерархия требований | Frontmatter артефактов BR / SR / TR — §3.3, §3.9, §3.12 связи |
| 07 ADAPT | ADAPT-специфика — §3.3.2, §3.6.4, §3.6.6 backward sub-states |
| 08 Specifications | SPEC-* типы — §3.4, §3.6.3 lifecycle SPEC |
| 09 Test cases | TC — §3.5, §3.6.5; pos/neg парность — §3.5.3 |
| 10 Lifecycle и QG | Quality Gates canonical — §3.7; state machines per type — §3.6; closed list policy — §10.10 параллельно §3.11 / §3.14 |
| 11 Substrate versioning | V1–V6 определения — §3.8.2 |
| 12 Maturity model | ai-provenance mandatory на RENAR-4+ — §3.10 (источник критерия — §12.7.1) |
| 13 Metrics | Drift классы §3.11 — источник для метрик типа Reconciliation Findings (§13.3.10) |
| 14 Conformance | §14.3 mandatory clauses ссылаются на canonical терминологию этой главы |
| reference/01-glossary.md | Развёрнутые объяснения, anti-patterns, history — non-normative |