04. Термины и определения¶
Часть RENAR Standard v1.0-draft · ← Оглавление
4.1 Зачем единый словарь терминов¶
Одно и то же слово у двух команд часто значит разное: для одной «спека» — это SR, для другой — макет экрана, для третьей — целый API-контракт. Пока термины плавают, рушится прослеживаемость и буксует любой разговор о соответствии. Эта глава убирает разночтения: справочник по формулировкам, который читают при согласовании артефактов, проверке носителя и подготовке оценки соответствия. Она фиксирует одно имя на каждую концепцию и тем гасит терминологический дрейф между командами и инструментами. После оглавления переходите к §4.3–§4.5 по типам артефактов, §4.6–§4.7 для состояний и гейтов, §4.8–§4.10 для носителя и происхождения, §4.11/§4.14 для drift-классов и запрещённых терминов; индекс закрытых списков — §1.7.5.
Глава нормирует каноническую терминологию RENAR: одно определение на одну концепцию; единый источник истины для других глав, реализационных носителей, инструментов проверки соответствия. Терминологический дрейф (§4.11) — отдельный класс нарушений соответствия (§13.3.1 косвенно).
Глава не дублирует reference/01-glossary.md: эта глава содержит канонические нормативные определения короткой формы; reference/01 — развёрнутые объяснения с антипаттернами, историей и отраслевым контекстом (информационный материал).
4.2 Принцип «только канонически黶
RENAR выбирает один канонический термин на одну концепцию. Внутри носителя (frontmatter, ID, нормативные абзацы тела, scripts, CI hooks) используется только канонический термин. Сопоставление с родственными стандартами (§4.13) — для документации, миграции и интеграции с внешними системами; внутри носителя замены канонического термина на эквивалент из таблицы сопоставления не происходит.
При обнаружении неканонического термина (по §4.14) в нормативном артефакте — нативный для носителя hook (§10.11.1) обязан выдать предупреждение при change-set; для RENAR-4+ (§11.7) — блокирующая ошибка.
Многоязычные проекты могут отображать каноническую терминологию в UI на язык клиента (§4.13.3); это UI-перевод, не каноническая замена.
4.3 Артефакты требований¶
4.3.1 ТЗ — Техническое задание¶
ТЗ (TZ-YYYY-NNN) — неизменяемый (§7.4.2) договорный артефакт, фиксирующий обязательства между клиентом и инженерной командой. После регистрации в носителе не редактируется. Изменения — через delta-ТЗ как новый неизменяемый артефакт (§7.6).
4.3.2 ADAPT — мостовой артефакт (bridge artifact)¶
ADAPT (ADAPT-NNN) — обязательный мостовой артефакт (§7.4.1) между ТЗ и иерархией требований. Содержит forward (инженерная интерпретация) + backward (вопросы клиенту) разделы. Каждое ТЗ обязано иметь ровно один корневой ADAPT в статусе approved (§13.3.3). Жизненный цикл: §4.6.4.
4.3.3 BR — Business Requirement¶
BR (BR-NN) — артефакт бизнес-уровня. Описывает наблюдаемый бизнес-эффект (business-outcome), а не способ его достижения. Декомпозируется в SR. Frontmatter — §6.5.2. Жизненный цикл: §4.6.1.
4.3.4 SR — System Requirement¶
SR (SR-NN) — артефакт системного уровня. Описывает обязательное поведение системы в рамках одного бизнес-эффекта. Имеет родительский BR (parent: BR-N) или родительский SR (при level: subsystem или level: module — §6.7). Frontmatter — §6.6.2. Жизненный цикл: §4.6.1.
4.3.5 TR — Task Requirement¶
TR (TR-NN) — артефакт уровня задачи исполнителя. Описывает практически выполнимую работу с goal + AC. Имеет родительскую цепочку implements: SR-N (или BR для тривиальных задач). Frontmatter — §6.7.2. Жизненный цикл: §4.6.2.
4.3.6 Иерархия¶
Иерархия требований:
SR может реализовывать SPEC через implements-spec[] (§8.6.2) — это связь, а не parent-ребро.
4.4 SPEC артефакты¶
SPEC — артефакт структурного описания системы как параллельная ось требований (§8.2). Не parent-ребро с SR; связан через constrained-by[] / implements-spec[] (§8.6). Жизненный цикл: §4.6.3.
4.4.1 Закрытый список 9 типов SPEC¶
Закрытый список (§8.3):
| Тип | Назначение |
|---|---|
SPEC-ARCH |
Архитектура системы (контексты, контейнеры, компоненты, deployment view, quality attributes) |
SPEC-API |
API contracts (REST / GraphQL / gRPC / async events) |
SPEC-DATA |
Модель данных (схема, ERD, migrations, retention, PII classification) |
SPEC-INT |
Integration (взаимодействие между подсистемами и внешними системами) |
SPEC-PROC |
Process / workflow (бизнес-процессы, машины состояний, 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) |
Проект не имеет права создавать новые типы SPEC локально (§13.3.4).
4.5 Артефакты тестирования¶
4.5.1 TC — Test Case¶
TC (TC-NN) — артефакт верифицируемого критерия. Покрывает нормативные утверждения BR / SR / SPEC (через verifies[] с version pin, §9.4). Жизненный цикл: §4.6.5.
4.5.2 Закрытый список типов 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-категориям |
4.5.3 Pos / neg парность¶
Нормативное требование (§9.7): каждое нормативное утверждение покрывается парой TC (positive scenario + negative scenario). Единичное TC-покрытие допускается только для утверждений-инвариантов (security STRIDE).
4.6 Статусы жизненного цикла¶
4.6.1 BR / SR¶
Закрытый список (§10.5): draft → approved → verified → accepted → deprecated. accepted — терминальный недеградируемый (§10.4.2, опционально); deprecated — терминальный.
4.6.2 TR¶
Закрытый список (§10.6): draft → approved → done; obsolete — альтернативный терминальный.
4.6.3 SPEC¶
Закрытый список (§10.7): draft → review → approved → verified; obsolete — терминальный.
4.6.4 ADAPT¶
Закрытый список (§10.8): draft → review → client-ready → answered → approved → frozen. frozen — терминальный immutable; изменения только через delta-ADAPT или errata.
4.6.5 TC¶
Закрытый список (§10.9): draft → ready → passing / failing → obsolete. passing ↔ failing — runner-managed transitions (§10.9.3), не gate-passages.
4.6.6 Backward findings (sub-state в ADAPT)¶
Закрытый список (§7.4.5): open → asked-to-client → answered → resolved → frozen; revised — возврат в asked-to-client.
4.6.7 Закрытые списки жизненного цикла — нерасширяемы локально на уровне проекта¶
Любой статус вне закрытого списка для соответствующего типа артефакта — нарушение соответствия (§10.10.2).
4.7 Quality Gates¶
Канонический список из §10.3 + §10.4. Проект не имеет права создавать новые gate-типы локально (§10.10.2, §13.3.6).
| Gate | Назначение | Статус соответствия |
|---|---|---|
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).
4.8 Термины носителя¶
4.8.1 Носитель¶
Носитель (в полях и коде — substrate) — система хранения и версионирования артефактов RENAR. RENAR независим от носителя: нормирует возможности (§4.8.2), а не инструменты.
4.8.2 Возможности V1–V6¶
Закрытый список из §3.3. Все шесть обязательны абсолютно для соответствия (§13.3.2):
| Возможность | Семантика |
|---|---|
V1 — Неизменяемая история |
Любое прошлое состояние артефакта восстановимо |
V2 — Атомарная единица изменения |
Изменения фиксируются как «всё или ничего» |
V3 — Сравнение различий и рецензирование |
Предложенное изменение представимо как diff против опорного состояния и проходит утверждение до интеграции в источник истины |
V4 — Ветвление / набор изменений |
Черновики отделимы от утверждённой истины; параллельные изменения независимы |
V5 — Сквозная фиксация версии |
Ссылка между носителями фиксирует конкретную версию артефакта |
V6 — Автор и отметка времени |
Каждая атомарная единица изменения имеет идентифицируемого автора и отметку времени ≥ секундной точности |
4.8.3 Атомарная единица изменения¶
Изменение носителя (V2), удовлетворяющее свойству «всё или ничего» — нативная для носителя транзакция; промежуточные несогласованные состояния не наблюдаемы наружу. Конкретная реализация (атомарная запись в распределённом VCS, транзакция в document store, иной механизм) специфична для носителя; описание форм выносится в guide/.
4.8.4 Фиксация версии¶
Нативный для носителя механизм (V5), фиксирующий конкретную версию артефакта одного носителя из другого через пару (artifact-id, version-id).
4.8.5 Журнал аудита (audit trail)¶
Нативная для носителя 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).
4.9 Системная иерархия¶
Закрытый список уровней (§6.7, §6.8):
| Уровень | Назначение |
|---|---|
system |
Весь продукт целиком; верхний уровень; редко используется (кросс-подсистемные задачи) |
subsystem |
Подсистема (например, отдельный сервис, фронтенд-приложение) |
module |
Модуль внутри подсистемы |
Поле level фиксируется во frontmatter артефакта (BR / SR / TR). Иерархия может расширяться вниз через эволюцию подсистема → модуль (§6.9.1) или обратно (§6.9.3).
4.10 Термины происхождения¶
4.10.1 ai-provenance — каноническая схема¶
Frontmatter-блок (§11.7.1, RENAR-4 обязательно) фиксирующий происхождение AI-генерируемого артефакта. Настоящая секция — единственный канонический источник схемы; chapter-level YAML примеры в §6.5.2, §6.6.2, §8.5, §9.3 ссылаются сюда и не определяют независимых полей.
| Поле | Обязательно? | Семантика |
|---|---|---|
ai-provenance.generated-by |
обязательно | Идентификатор модели (<vendor>-<model>-<version>@<date>) |
ai-provenance.generated-at |
обязательно | UTC timestamp генерации (ISO-8601) |
ai-provenance.prompt-template |
обязательно | нативный для носителя pointer на prompt template (<path>@<version>) |
ai-provenance.context-tokens |
обязательно | Размер контекста на входе (integer) |
ai-provenance.output-tokens |
обязательно | Размер вывода (integer); источник для метрик §12.3 |
ai-provenance.human-edits |
обязательно | Boolean — были ли ручные правки после генерации (информационное поле; см. §4.10.1.1) |
ai-provenance.generation-time-ms |
optional | Latency генерации в миллисекундах; рекомендуется на RENAR-5 для cost/latency budget мониторинга (§11.8.1) |
ai-provenance.cost-budget |
optional на RENAR-4, обязательно на RENAR-5 | Запланированный budget стоимости генерации |
ai-provenance.cost-actual |
optional на RENAR-4, обязательно на RENAR-5 | Фактическая стоимость; источник для §12.3.9 Cost per Approved Requirement |
Добавление новых полей в схему — только через формальную процедуру изменения стандарта (§13.9). Локально определённые ai-provenance.* поля проектом-реализацией являются declared-stricter extension (§10.10.2) и не нарушают соответствия, но не считаются каноническими.
4.10.1.1 Семантика human-edits¶
human-edits — информационное поле для traceability и observability, не gating-флаг. Значение human-edits: true означает, что артефакт был отредактирован вручную после первичной AI-генерации; оно не запускает auto-rejection. Нормативное правило P3 (§9.2) — «инженер не пишет TC вручную» — нормирует происхождение, не последующие правки. Реализация на носителе может (declared-stricter) дополнительно требовать review для артефактов с human-edits: true; это локальное ужесточение, не часть базового соответствия RENAR-N.
4.10.2 Указание источника (source citation)¶
Inline pointer в body артефакта (RENAR-4 обязательно, §11.7.1) на источник конкретного нормативного утверждения. Формат специфичен для носителя; типичные паттерны: [TZ-XXX §Y line Z], [ADAPT-NNN §A.B], маркер derived с pointer на parent-артефакт.
4.10.3 Цепочка прослеживаемости (traceability chain)¶
Цепочка артефактов от ТЗ до прогона TC, фиксирующая происхождение каждого утверждения:
Каждое звено связано через канонические frontmatter-поля (§4.12). Цепочка прослеживаемости — источник истины для ревизии соответствия (§12.5.3).
4.11 Drift классы (закрытый список)¶
Закрытый список восьми классов нарушений требовательной инфраструктуры. Изменение списка — формальная процедура изменения стандарта (§13.9.3). Нативный для носителя hook (§10.11.1) обязан обнаруживать каждый класс на соответствующей точке контроля.
| # | Класс | Что нарушено | Точка контроля |
|---|---|---|---|
| 4.11.1 | Schema drift | frontmatter артефакта не соответствует обязательной схеме гл. 06/08/09 | hook носителя на change-set; RENAR-3+ — blocking (§11.6.1) |
| 4.11.2 | Lifecycle drift | Артефакт вне закрытого списка статусов (§4.6) или прошёл forbidden transition (§10.12) | hook носителя на promote-transition |
| 4.11.3 | Source-of-truth drift | Реализационный код / производный артефакт расходится с SR / SPEC, на который ссылается через verifies[].version (V5) |
Reconciliation hook RENAR-4+; регистрация как backward finding в delta-ADAPT |
| 4.11.4 | Implementation drift | Реализационный носитель перестал ссылаться на актуальную version носителя требований (V5 pin устарел) |
Auto-invalidate verified (§10.5.4) |
| 4.11.5 | Terminological drift | Использование non-canonical термина (§4.14) в нормативном артефакте | hook носителя на change-set; RENAR-4+ — blocking |
| 4.11.6 | Order / provenance drift | Артефакт ссылается на источник в более низком статусе чем требует §10.3.1 reference-validation | hook носителя (§10.11.1) блокирует change-set |
| 4.11.7 | TC ↔ requirement provenance drift | TC потеряло verifies[] ссылку или last-run.requirement-version не совпадает с текущей version |
runner-managed: TC переводится в failing (§10.9.3) до повторного прогона |
| 4.11.8 | Test-fitting drift | Pass / Fail-критерии TC изменены одновременно с реализационным кодом, чтобы failing TC стал passing без устранения корня (§9.13) | hook носителя через [test-spec-change] маркер; единое лицо не может одобрить оба change-set (§10.11.3) |
4.12 Термины полей связи (frontmatter, Connection terms)¶
Канонические имена полей, фиксирующих связи между артефактами:
| Поле | Артефакт-источник | Семантика |
|---|---|---|
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 |
Полная схема каждого артефакта — в reference/02-schemas.md.
4.13 Сопоставление с родственными стандартами (Mapping)¶
4.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) |
ТЗ (Требование к задаче) | (нет прямого класса; детализация system / system-element requirement) | Solution Requirement (detailed) | 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) |
4.13.2 Статусы жизненного цикла¶
| 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 |
4.13.3 Многоязычный UI¶
Многоязычные проекты могут отображать каноническую терминологию в UI на язык клиента (RU пример):
| English (canonical) | Russian (UI-перевод) |
|---|---|
| Business Requirement | Бизнес-требование |
| System Requirement | Системное требование |
| Test Case | Тест-кейс |
| Quality Gate | Контрольная точка качества |
| Acceptance | Приёмка |
| Verified | Проверено |
| Approved | Утверждено |
| Deprecated | Устарело |
Это только UI-перевод. Frontmatter, ID, имена файлов, нормативные абзацы тела — всегда каноническая латиница / канонический RU из этой главы.
4.14 Запрещённые / устаревшие термины¶
Закрытый список неканонических терминов; hook носителя RENAR-4+ — blocking при обнаружении в нормативном артефакте (§4.2).
| Запрещённый термин | Каноническая замена | Почему |
|---|---|---|
| «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 — единица планирования, не требование |
4.14.1 Устаревшие RENAR-specific labels¶
При migration с pre-v1.0 draft material встречаются устаревшие labels:
| Устаревший label | Каноническая 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 Gate (канонический v1.0, §10.3.1) |
QG-1 Requirements Gate (старое) |
QG-1 Implementation Gate (канонический v1.0, §10.3.2) — semantic shift: ранее approval BR/SR, теперь только TC draft → ready |
QG-2 Implementation Gate (старое) |
QG-1 Implementation Gate (канонический v1.0, §10.3.2) |
QG-3 Verification Gate (старое) |
QG-2 Verification Gate (канонический v1.0, §10.3.3) |
Migration существующего носителя требований со старыми labels — отдельный однократный процесс; нативный для носителя hook на change-set должен auto-detect устаревшие labels и предлагать канонические замены.
4.15 Порядок разрешения разногласий (Authority)¶
При разногласиях по термину порядок обращения:
- Эта глава (§4) — канонический для RENAR-стандарта.
- Соответствующая глава стандарта (06–14) — для специфичной семантики артефактов (например, ADAPT-специфика — в §7).
- SENAR §3 (терминология родительского стандарта).
- ISO/IEC 29148:2018 — для общеинженерной терминологии requirements.
- BABOK v3 — для business-аналитики терминов.
- Фиксация через формальную процедуру изменения стандарта (§13.9.3) — если все вышеперечисленные молчат.
Не использовать как источник терминологии:
- Тикеты ticket-систем (часто противоречивые).
- Чаты команды (slang ≠ канонический).
- Презентации и старые draft-материалы.
- Маркетинговые материалы.
4.16 Связь с другими главами¶
| Глава | Связь |
|---|---|
| 02 Положение в типологии методологий | §2.3 инверсия источника истины + §2.5 независимое от носителя версионирование — фундамент для §4.8 терминов носителя |
| 06 Иерархия требований | frontmatter артефактов BR / SR / TR — §4.3, §4.9, §4.12 связи |
| 07 ADAPT | ADAPT-специфика — §4.3.2, §4.6.4, §4.6.6 backward sub-states |
| 08 Specifications | SPEC-* типы — §4.4, §4.6.3 жизненный цикл SPEC |
| 09 Test cases | TC — §4.5, §4.6.5; pos/neg парность — §4.5.3 |
| 10 Жизненный цикл и QG | Quality Gates канонические — §4.7; машины состояний по типам — §4.6; политика закрытого списка — §10.10 параллельно §4.11 / §4.14 |
| 03 Версионирование носителя | V1–V6 определения — §4.8.2 |
| 11 Maturity model | ai-provenance обязательно на RENAR-4+ — §4.10 (источник критерия — §11.7.1) |
| 12 Metrics | Drift классы §4.11 — источник для метрик типа Reconciliation Findings (§12.3.10) |
| 13 Соответствие | §13.3 обязательные положения ссылаются на каноническую терминологию этой главы |
| reference/01-glossary.md | Развёрнутые объяснения, anti-patterns, history — ненормативный |