Глоссарий RENAR
Назначение: единый источник canonical-терминов RENAR. При расхождении формулировок в проектной документации этот глоссарий — авторитетный. Источник:
research/05-glossary-terminology.md(informative),standard/03-terms.md(normative).
1. Authority chain
В случае разногласий по термину применяется порядок:
- Этот документ — canonical для RENAR.
standard/03-terms.md— нормативные определения главы стандарта.- ISO/IEC/IEEE 29148 — international standard для requirements engineering.
- BABOK Guide v3 — Business Analysis Body of Knowledge.
- Изменение через предложение поправки в полный RENAR Standard — если все источники молчат.
Не используются как источник терминов: тикеты в багтрекере, чаты команды (slang), устаревшие презентации, маркетинговые материалы.
2. Canonical термины
2.1 Уровни требований
| RENAR canonical | Полное название | RU (для UI) | Описание |
|---|---|---|---|
| BR | Business Requirement | Бизнес-требование | Бизнес-цель уровня заказчика. Что хочет получить организация. |
| SR | System Requirement | Системное требование | Инженерное требование к ПО. Verifiable. Один SR — одна проверяемая единица. |
| TM | Module/Submodule SR | СТ модуля | SR подсистемы. Используется для крупных модулей с собственной декомпозицией. |
| TR | Task Requirement | Требование к задаче | Implementation-level требование, deriving from SR. Единица планирования. |
| UIC | UI Concept | UI-концепция | UX-эталон / wireframe / interaction spec. Источник для UI-SR. |
| AIC | AI Concept | AI-концепция | AI architecture concept (prompt, model, eval criteria). Источник для AI-SR. |
| INT-SR | Integration SR | Интеграционное СТ | SR для контракта между сервисами / системами. |
| TC | Test Case | Тест-кейс | Verifiable artifact, проверяющий SR/BR. Поведение, не реализация. |
| INT-TC | Integration TC | Интеграционный TC | TC, проверяющий INT-SR. Обычно contract test. |
| TS | Technical Specification | Техническая спецификация | Design-level spec. Часть SPEC-* семейства (см. §2.5). |
Правило идентификации: в frontmatter id — RENAR canonical (BR-01, SR-05). При экспорте в другой substrate — applied mapping.
2.2 ADAPT artifact family
| Термин | Описание |
|---|---|
| ADAPT | Adaptive Document for Articulating Project’s TZ. Двусторонняя инженерная адаптация ТЗ. Forward (интерпретация) + backward (вопросы). Approved двойной подписью. |
| delta-ADAPT | ADAPT для delta-TZ. Цепочка: ADAPT-001 → ADAPT-001-delta-1 → ADAPT-001-delta-2. Применяются по порядку. |
| errata-ADAPT | Корректировка approved ADAPT (наша ошибка интерпретации). Не правит frozen-документ — добавляет отдельный артефакт. |
| Forward (in ADAPT) | Инженерная интерпретация каждого раздела ТЗ. Цитата → интерпретация → достроенные сценарии → scope. |
| Backward (in ADAPT) | Список проблем/вопросов к клиенту. Lifecycle: open → asked-to-client → answered → resolved → frozen. |
| Term mapping (in ADAPT) | Таблица «термин клиента → инженерное понимание». |
2.3 Backward categories (closed list)
ADAPT backward записи относятся к одной из 7 категорий. Список закрыт; новые добавляются только через изменение полного RENAR Standard:
| Категория | Описание |
|---|---|
contradiction | Противоречие внутри ТЗ. |
gap | Гэп — про это ТЗ молчит. |
hidden-assumption | Скрытое предположение инженера, требующее подтверждения. |
feasibility | Технически нереализуемое или дорогое требование. |
regulatory | Затрагивает законодательство / compliance. |
terminology | Неясный или конфликтующий термин клиента. |
scope | Уточнение границ scope (входит / не входит). |
2.4 Quality Gates (closed list)
| Gate | Применяется к | Условие пропуска |
|---|---|---|
| QG-0 Context Gate | Старт задачи | Goal + acceptance criteria + ≥ 1 негативный сценарий + scope. |
| QG-1 Requirements Gate | Перевод SR в approved | SR derived from approved ADAPT; trace до ТЗ есть. |
| QG-2 Implementation Gate | Перевод задачи в done | Все AC verified свидетельством; pos+neg TC зелёные; AI Review checklist пройден. |
| QG-3 Verification Gate | Перевод SR в verified | Все TC из verified-by зелёные; spot-check passed. |
| QG-4 Acceptance Gate | Принятие клиентом | Все BR покрыты verified SR; acceptance TC зелёные; клиент подписал. |
| QG-ADAPT-draft | Создание ADAPT | Forward охватывает все разделы ТЗ. |
| QG-ADAPT-review | Перевод в review | Все backward записи open или asked-to-client; нет draft. |
| QG-ADAPT-client-ready | Передача клиенту | Все backward asked-to-client; пакет вопросов собран. |
| QG-ADAPT-answered | После ответа клиента | Все backward answered. |
| QG-ADAPT-approve | Approval ADAPT | Все backward resolved; двойная подпись (клиент + архитектор). |
| QG-ADAPT-frozen | После approval | Immutable; BR/SR/SPEC generation разрешён. |
Список закрыт; новые QG-номера добавляются только через изменение полного RENAR Standard.
2.5 SPEC family (closed list)
| Тип | Назначение | Источник |
|---|---|---|
| SPEC-API | Контракт API endpoint (request/response, errors, semantics) | Forward ADAPT, INT-SR |
| SPEC-DATA | Data model (entities, attributes, constraints, lifecycle) | Forward ADAPT |
| SPEC-ARCH | Архитектурное решение (компоненты, потоки, ADR) | Forward ADAPT |
| SPEC-UI | UI specification (layout, interaction, accessibility) | UIC, Forward ADAPT |
| SPEC-SEC | Security spec (threat model, controls, auth/authz model) | Forward ADAPT, regulatory backward |
| SPEC-AI | AI spec (prompt, model, eval criteria, fallback policy) | AIC, Forward ADAPT |
Список закрыт; новые SPEC-типы добавляются только через изменение полного RENAR Standard.
2.6 Lifecycle статусы
| Статус | Применим к | Значение |
|---|---|---|
draft | все артефакты | В работе, не для использования другими |
review | все | На ревью, возможны изменения |
approved | ADAPT, SR, SPEC | Утверждён; immutable после двойной подписи (для ADAPT) или single (для SR/SPEC) |
verified | SR | Подтверждён зелёными TC + spot-check |
frozen | ADAPT | Approved + immutable; используется как источник для генерации BR/SR/SPEC |
deprecated | все | Устарел, не используется в новых артефактах |
replaced | все | Заменён другим артефактом через replaced-by |
obsolete | research/legacy | Полностью изъят из обращения |
2.7 Substrate capabilities (V1-V6)
RENAR substrate-agnostic. Артефакт хранится на любом substrate, удовлетворяющем capabilities:
| Capability | Описание |
|---|---|
| V1 Immutable history | После approval запись не редактируется (audit trail сохраняется). |
| V2 Atomic change | Создание/обновление артефакта — одной транзакцией (нет half-applied state). |
| V3 Stable identifier | ID артефакта переживает rename, относительный путь, миграцию между substrate. |
| V4 Cross-link | Артефакт может ссылаться на другой по ID; ссылка валидируется. |
| V5 Version pin | Артефакт может сослаться на конкретную ревизию другого (frozen pointer). |
| V6 Audit query | «Кто и когда подписал ADAPT-001» — отвечается одной командой substrate. |
Конкретные substrate: git с PR-ревью, Raven (документная БД с подписями), любая БД с историей и подписями. RENAR не требует git — только V1-V6.
2.8 AI provenance (canonical fields)
В frontmatter любого AI-generated артефакта:
| Поле | Тип | Описание |
|---|---|---|
ai-provenance.generated-by | string | Модель в формате <vendor>-<model>-<version>@<date>. Пример: anthropic-claude-opus-4-7@2026-05-15. |
ai-provenance.prompt-template | string | Путь к prompt template + версия. Пример: prompts/adapt-from-tz.md@v2.1. |
ai-provenance.context-tokens | integer | Токенов в input context. |
ai-provenance.output-tokens | integer | Токенов в output. |
ai-provenance.generation-time-ms | integer | Время генерации в миллисекундах. |
ai-provenance.human-edits | boolean | True если человек редактировал текст после AI-генерации. Обязательно true для approved-артефактов. |
2.9 Тестовые типы
Тип TC (type поле) | ISTQB соответствие | Применение |
|---|---|---|
system | System Testing | Проверка SR. |
acceptance | Acceptance Testing | Проверка BR (приёмочный). |
ux | (Usability extension) | Проверка UIC через VLM-judge / визуальное сравнение с baseline. |
eval | (AI-specific) | Проверка AIC через LLM-judge / метрики (BLEU, accuracy, hallucination rate). |
contract | Component Integration Testing | Проверка INT-SR через contract testing (Pact и аналоги). |
2.10 Связи (frontmatter поля)
| Поле | Назначение |
|---|---|
parent | Родитель в иерархии (BR → SR → TM); один источник. |
children | Дочерние артефакты (auto-derived). |
source.adapt | ADAPT, из которого выведен артефакт (canonical для BR/SR/SPEC). |
source.adapt-section | Раздел ADAPT (Forward §N). |
source.tz-section | Раздел ТЗ (informative, для traceability). |
verifies (в TC) | SR/BR, которые TC покрывает, с указанием requirement-version. |
verified-by (в SR) | TC, верифицирующие SR (auto-derived). |
derived-from | Template + версия (если артефакт создан из шаблона). |
replaces / replaced-by | Замена при deprecate. |
supersedes (в новом) | Какое требование заменяется. |
linked-tasks | Задачи, реализующие SR (через runtime, не через файлы). |
2.11 Имена файлов (default convention)
| Тип | Шаблон | Пример |
|---|---|---|
| ADAPT | adapt/ADAPT-NNN[-delta-N].md | adapt/ADAPT-001-main.md, adapt/ADAPT-001-delta-1.md |
| BR | br/BR-NN-<slug>.md | br/BR-01-notification-capture.md |
| SR | sr/SR-NN-<slug>.md | sr/SR-05-notification-feed.md |
| SR подсистемы | sr/<MODULE>-SR-NN.N-<slug>.md | sr/WMS-SR-01.2-pick.md |
| UIC | ui-concepts/UIC-NN-<slug>.md | ui-concepts/UIC-02-notification-feed.md |
| AIC | ai-concepts/AIC-NN-<slug>.md | ai-concepts/AIC-01-rag-strategy.md |
| INT-SR | int-sr/INT-SR-NN-<slug>.md | int-sr/INT-SR-01-princess-gerda.md |
| SPEC | specs/SPEC-<KIND>-NN-<slug>.md | specs/SPEC-API-03-orders.md |
| TC | tests/TC-NN-<slug>.md | tests/TC-01-login-success.md |
| INT-TC | tests/INT-TC-NN-<slug>.md | tests/INT-TC-01-pact-princess-gerda.md |
| ТЗ | tz/TZ-YYYY-NNN.md | tz/TZ-2026-001.md |
| Дельта-ТЗ | tz/TZ-YYYY-NNN-delta-N.md | tz/TZ-2026-001-delta-1.md |
| UX baseline | ai-concepts/baselines/UIC-NN-<scenario>.png | ai-concepts/baselines/UIC-02-feed-default.png |
| Eval dataset | ai-concepts/eval-datasets/AIC-NN-<slug>.jsonl | ai-concepts/eval-datasets/AIC-01-typical-queries.jsonl |
Convention; substrate-нативные хранилища могут использовать иную раскладку при условии stable identifiers (V3).
2.12 Маркеры change-record (informative)
В substrate, поддерживающем атомарные изменения с метаданными (git commit message, Raven change-record description), допустимы маркеры:
| Маркер | Назначение |
|---|---|
[delta:TZ-YYYY-NNN] | Изменение по delta-ТЗ. |
[test-spec-change] | Изменение Pass/Fail-критериев TC (отдельный approval). |
[baseline-update] | Обновление UX/eval baseline (отдельный approval). |
[coverage] | Bot-generated regeneration of coverage/test-plan/requirements summaries. |
[reconciliation] | Изменение от reconciliation-агента. |
[multi-model-disagreement] | Артефакт с расхождением AI-моделей — требует ручного review. |
[AI] | Префикс для AI-generated изменений. |
Substrate-нативный механизм может реализовать эти маркеры как поля change-record, теги или labels — конкретика не нормирована.
3. Cross-standard mapping
3.1 Уровни требований
| RENAR | ISO/IEC 29148 | BABOK | SAFe | Raven enum | SENAR (RU) |
|---|---|---|---|---|---|
| BR | Business Requirement | Business Need | Portfolio Epic / Strategic Theme | BT | БТ |
| SR | System / Software Requirement | Solution Requirement (Functional) | Feature | ST | СТ |
| TM | (extension) | (sub-component scope) | Story (sometimes) | TM | СТ модуля |
| TR | Implementation Requirement | Transition Requirement | Story | TK | ТЗ |
| UIC | (between BR/SR — design spec) | Stakeholder Requirement (UX subset) | (design level) | (extend) | UIC |
| AIC | (REQ-extension) | (n/a) | Enabler | (extend) | AIC |
| INT-SR | Interface Requirement | Solution Interface | Cross-feature integration | (related) | INT-СТ |
| TC | Test Case | Verification | Story acceptance test | test_case | ТК |
| TS / SPEC | Design Description | Solution Component | Enabler tech spec | (extend) | ТС |
3.2 Quality gates
| RENAR | SENAR | Raven | CMMI activity |
|---|---|---|---|
| QG-0 Context | QG-0 | VK-1 (start) | Requirements check before commitment |
| QG-1 Requirements | QG-1 | VK-1 | Requirements baseline |
| QG-2 Implementation | QG-2 | VK-2 | Verification |
| QG-3 Verification | QG-3 | VK-3 | Validation |
| QG-4 Acceptance | QG-4 | VK-4 | Customer acceptance |
3.3 Lifecycle статусы
| RENAR | Raven | ISO/IEC 29148 | CMMI |
|---|---|---|---|
draft | draft | proposed | identified |
approved | approved | agreed-to / baselined | committed |
verified | verified | verified | validated |
deprecated | obsolete | retired | obsolete |
replaced | (via replaces) | superseded | superseded |
3.4 Артефакты процесса
| RENAR | BABOK | SAFe | SENAR |
|---|---|---|---|
| ADAPT (Forward + Backward) | Requirements Analysis Document | Solution Intent (fixed + variable) | (n/a — RENAR-extension) |
| Work Order / ТЗ | Stakeholder commitment artifact | Customer order | (контекст) |
| delta-TZ | Change Request | (n/a — handled via Solution Intent updates) | (контекст) |
| Impact Analysis | Impact Analysis (BABOK §8) | (derived) | (контекст) |
| Spot-check | Random sampling QA | (n/a) | Rule 9.5 |
| Adversarial review | Independent verification | (n/a — REQ-extension) | (via ADR metric) |
| Reconciliation | Continuous improvement audit | Inspect & Adapt | Quality Sweep |
3.5 Multilingual UI projection
Frontmatter, ID, файлы — всегда canonical (английская латиница). UI может отображать русские переводы:
| Canonical | UI (RU) |
|---|---|
| Business Requirement | Бизнес-требование |
| System Requirement | Системное требование |
| Test Case | Тест-кейс |
| Quality Gate | Контрольная точка качества |
| Acceptance | Приёмка |
| Verified | Проверено |
| Approved | Утверждено |
| Deprecated | Устарело |
| Frozen | Замороженный |
| Backward finding | Замечание к ТЗ |
| Forward interpretation | Инженерная интерпретация |
UI-перевод не меняет canonical-идентификаторы в substrate.
4. Запрещённые / устаревшие термины
RENAR не использует следующие термины (даже если они встречаются в SENAR / отраслевой литературе):
| Термин | Что использовать вместо | Почему |
|---|---|---|
| User Story как требование | SR | Story — единица планирования, не требование. Story может реализовывать SR, но сама требованием не является. |
| Use Case (формально) | UIC + SR | Use case mixes UX и behavior. RENAR разделяет UIC (UX-эталон) и SR (поведение). |
| Spec (без квалификатора) | SR / BR / SPEC-API / SPEC-DATA / … | «Spec» неоднозначно. Используем точные термины. |
| Бизнес-логика как требование | SR | «Бизнес-логика» — термин кода, не требований. |
| Функциональность | SR / TR | Слишком широкое; не verifiable. |
| Фича (mixed-lang) | Feature (SAFe context) или SR (RENAR canonical) | Mixed Russian/English; неоднозначно. |
| Хотелка | (никогда) | Договорный документ так не пишется. |
| Эпик как требование | BR (бизнес-уровень) или Portfolio Epic (SAFe) | Epic — единица планирования, не требование. |
| «Тестировать руками» | spot-check (Rule 5 Core) или manual TC с type: acceptance | Расплывчатое; не verifiable evidence. |
| «Доделать» (как статус) | draft / review | Не из closed list lifecycle. |
| TODO в frontmatter | Backward запись в ADAPT (если про требование) или task в трекере (если про реализацию) | Открытые вопросы хранятся в правильном артефакте, не в комментарии. |
При обнаружении этих терминов в проектных артефактах — substrate-native warning (pre-commit hook в git, validation rule в Raven).
5. Versioning глоссария
Глоссарий — самостоятельный документ со своей версией. Изменение canonical-термина — major version bump (1.0 → 2.0) + migration script для всех проектных артефактов.
Текущая версия: 1.0-draft (Phase 7 наполнение).
Открытые вопросы (для v1.0 final):
- Canonical язык: латиница (BR/SR) или русский (БТ/СТ)? Решение draft: canonical латиница, RU только в UI projection (§3.5). Подтвердить на v1.0.
- TM уровень: оставить отдельный или достаточно naming convention
<MODULE>-SR-NN.N? Решение draft: оставить, но опционально. Подтвердить. - AIC ← AAC / AIA? Решение draft: AIC, для совместимости с существующими документами. Подтвердить.
- INT-TC как отдельный тип или naming convention? Решение draft: naming convention, не отдельный уровень. Подтвердить.
Глоссарий RENAR 1.0-draft — часть reference/. См. также 02-schemas.md, 03-ai-risk-register.md.