Единый артефакт системного аналитика, который фиксирует бизнес-термины (что означает для стейкхолдеров) и элементы данных (как термины проявляются в моделях, БД, API и интерфейсах). Глоссарий (business glossary) отвечает на «что это значит в бизнесе»; словарь данных (data dictionary) — «где и как это хранится/передаётся и по каким правилам». Один документ допустим, если внутри две явные секции с cross-reference по Term ID ↔ Element ID; иначе определения смешиваются с реализацией. Теория метаданных и полей словаря — в 03.03.03 Словарь данных (описание).
1. Назначение
Документ пишет системный аналитик с участием владельцев домена (business owner) и data steward; его читают разработка, QA, архитектор, информационная безопасность, владелец продукта и compliance на этапах выявления требований, проектирования и приёмке. Business owner утверждает определения терминов; data steward (часто SA) — строки словаря и согласование изменений с IT; при спорах между доменом и реализацией финальное слово по business meaning — у owner, по physical mapping — у steward после согласования с архитектором.
Шаблон закрывает четыре задачи:
- Единый язык домена — авторитетные определения терминов, синонимы и запрещённые формулировки; снижение неоднозначности в BRD, SRS, User Story и Use Case.
- Контракт данных — семантика, обязательность, правила валидации на уровне домена, источник и чувствительность каждого элемента; мост между бизнесом и persistence/API.
- Трассируемость «термин → требование → поле» — Term ID и Element ID связывают глоссарий с FR, колонками БД, properties REST/SOAP, полями сообщений и контролами UI; полная цепочка до test — в 10.01.15 Шаблон матрицы трассировки.
- Управляемый жизненный цикл терминов — статусы draft/approved/deprecated, changelog при переименованиях; breaking change в контрактах не остаётся «тихим» рефакторингом.
Глоссарий и словарь не заменяют спецификации БД, API, MQ и экранов — они связывают их через общую терминологию.
Правило single source of detail — где канон, а где только ссылка:
| Слой | Канон для | В GLOSS-* фиксируем | Детали — в артефакте |
|---|---|---|---|
| Глоссарий | business meaning | Term ID, определение, owner, синонимы | — |
| Словарь | семантика поля + cross-mapping | Element ID, Term ID, logical name, business-правила, чувствительность, valid/invalid | — |
| DB-spec | DDL и persistence | только Element ID + краткая ссылка | PK/FK, индексы, CHECK, точный тип — 10.01.03 Шаблон спецификации БД сервиса |
| API-spec | контракт синхронного обмена | Element ID + property name | schema, required, format, examples — 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API |
| MQ-spec | события и payload | Element ID + topic/field | schema version, headers — 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ) |
Если одно и то же поле описано и в словаре, и в DB/API spec — не дублируйте constraints: в словаре — business-смысл и правило plain language; в spec — исполнимая форма (DDL, JSON Schema). Расхождение между слоем и spec — defect spec или словаря, не «два канона».
2. Когда использовать
Подходит, если:
- на проекте несколько команд, интеграций или bounded context — риск расхождения
client/customer/ «контрагент»; - BRD/SRS содержат доменные термины, KPI и бизнес-правила, которые должны читаться одинаково бизнесом и IT;
- в одном релизе меняются БД, API, события и UI — нужен канонический реестр имён и атрибутов;
- домен регламентирован: отчётность, аудит, PII/PCI, retention — классификация данных должна быть явной;
- готовитесь к gate «готовность к разработке» (10.04 Чеклист аналитика перед стартом разработки) — термины и ключевые поля согласованы до детализации контрактов.
Не подходит или требует дополнения, если:
- нужен enterprise data catalog / MDM с lineage, quality rules и автоматической синхронизацией из production — шаблон покрывает аналитический контур проекта; на крупных программах экспортируйте в catalog или синхронизируйте с OpenAPI/DDL;
- достаточно 5–10 терминов без интеграций — см. minimal в §3.0;
- нужна только ER-диаграмма или DDL без бизнес-семантики — 10.01.03 Шаблон спецификации БД сервиса; словарь дополняет, не дублирует PDM;
- нужны пошаговые сценарии — 10.01.01 Шаблон User Story / 10.01.02 Шаблон Use Case; термины из глоссария используются в формулировках и AC, но не заменяют сценарии;
- один термин в разных bounded context имеет разные значения — flat-глоссарий без пометки контекста ведёт к ошибкам; явно укажите domain + context note или разделите реестры.
Входные условия: границы решения согласованы (02.01.04 Определение границ решения (Scope Modelling)), черновик терминов собран из интервью и документов (02.02.01 Интервьюирование и анкетирование, 02.02.03 Наблюдение и анализ документов), назначены business owner и data steward (02.01.03 Анализ заинтересованных сторон (Stakeholder Map)).
Правило golden source: глоссарий — единственный авторитетный источник бизнес-определений; SRS и API spec ссылаются на Term ID, а не переопределяют термин локально. Если в BRD уже есть встроенный глоссарий — извлеките термины в отдельный документ GLOSS-*, проставьте Term ID и в BRD оставьте только ссылки; дублирование без миграции нарушает golden source (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).
Agile-ритм: новый Term в спринте — draft в GLOSS-* → story/AC с placeholder Term ID (T-XXX-draft) → approval owner до merge в release branch; Element ID и mapping в API/БД — до начала разработки фичи, не post-factum в UAT.
3. Структура документа
Скопируйте блок в Confluence, RM-инструмент, Excel/Google Sheets или Git (markdown/CSV) — процесс ведения в Git описан в 07.05 Системы контроля версий (Git) для документации.
Три уровня полноты — выберите один и не смешивайте обязательность полей между уровнями:
| Уровень | Когда | Секции | Обязательность |
|---|---|---|---|
| minimal (§3.0) | 5–10 терминов, нет интеграций | только глоссарий + сокращённый паспорт | поля §3.0 |
| standard | типовой продукт с API/БД | §3.1–3.4, §3.6 (enum), §3.7 | поля с «да» в таблицах; «да*» — по наличию persistence/API |
| full | regulated, multi-service, formal CCB | standard + §3.2 (RFC), все appendix, RTM | все поля, включая «нет», где релевантно |
Поля с пометкой обяз. нужны для sign-off на выбранном уровне; остальные — по масштабу проекта.
Версии: версия документа gloss (GLOSS-*-v2) и версия enum / schema API (API-LEAVE-001 major) разведены: смена wording термина — minor документа; breaking rename поля или enum — major контракта + changelog и deprecated-политика (03.05.07 Управление версионированием API и жизненным циклом).
3.0. Minimal — только глоссарий
Если интеграций нет и терминов 5–10, достаточно одной таблицы без словаря данных и без §3.5. Обязательные поля: Term ID, термин, определение, owner, статус. Желательно: синонимы/запрещённые, источник, связь с FR. Паспорт (§3.1) — сокращённый: ID документа, продукт, версия, согласующий owner. При появлении API или БД — перейдите на standard, добавьте секцию словаря, не переписывая Term ID.
3.1. Паспорт артефакта (метаданные)
| Поле | Обяз. | Что писать |
|---|---|---|
| ID документа | да | Уникальный идентификатор: GLOSS-{DOMAIN}-{MODULE}-v{N} (напр. GLOSS-HR-LEAVE-v1). Префиксы Term/Element: T-{DOMAIN}-{NNN}, E-{ENTITY}-{ATTR} — локальная схема проекта; не путать с ID строк RTM (FR-, US-, TC-) — они в 10.01.15 Шаблон матрицы трассировки. |
| Продукт / проект | да | Система, программа или bounded context в scope. |
| Уровень полноты | да | minimal | standard | full — см. таблицу выше. |
| Версия, статус, дата | да | Draft → Review → Approved; автор последнего изменения. |
| Upstream: BRD / SRS / релиз | да | BRD-GOAL-xxx, SRS-HR-LEAVE-v2, epic или release ID. |
| Согласующие | да | Business owner (термины), data steward (словарь), представитель ИБ (если есть PII). |
| Связанные спеки | да | DB-SPEC, API, Producer/Consumer, FE, NFR, BPMN — ссылки по ID, не копирование полей. |
| Принципы ведения | да | Golden source; single source of detail (§1); правила именования (RU label / EN canonical / snake_case в API); locale UI отделён от канонического term. |
3.2. Принципы и процесс изменений
| Поле | Обяз. | Что писать |
|---|---|---|
| Жизненный цикл термина | да | draft → approved → deprecated; кто инициирует, кто утверждает. Согласование с требованиями: deprecated Term не удаляют, пока на него ссылаются approved FR — сначала обновите или закройте FR (02.05.05 Жизненный цикл требования); если FR deprecated, Term может оставаться approved для других FR или истории отчётности. |
| Change log терминов / RFC | да* | *Обяз. на уровне full и при formal CCB. Операционный журнал переименований и breaking change: Term/Element, старое → новое, sunset, alias period. Строки живут в том же GLOSS-* (лист «Change log») или в отдельном RFC-GLOSS-{NNN} со ссылкой из паспорта — выберите одно на проект. При 02.05.02 Управление изменениями (Change Control Board) в CCB-пакет идут строки change log + impact на API/БД; это не 02.05.02 Управление приоритетами в условиях изменчивости — там приоритизация, а не переименование терминов. |
| Naming convention | да | Таблица: бизнес-имя (RU) ↔ logical name ↔ physical name ↔ JSON path ↔ XML element. |
| Bounded context / multi-service | нет | Один Term ID — один business meaning; один Element ID может иметь разные physical name в разных сервисах (напр. employee_id vs emp_uuid) — укажите сервис в колонке physical name. Разные значения одного слова в разных контекстах — разные Term ID с context note. |
| KPI и вычисляемые термины | нет | KPI и формулы из BRD — отдельные Term ID в глоссарии (определение + формула plain language); в словаре — Element с типом «вычисляемое», ссылка на Term ID и правило расчёта. |
| Lint на ревью (gate) | да | Перед sign-off и gate (10.04 Чеклист аналитика перед стартом разработки): в SRS/API/story нет доменных терминов без Term ID или со статусом ≠ approved. Не регистрируем в глоссарии (lint не требует Term ID): технические типы и протоколы (UUID, HTTP, JSON, ISO 8601); стандартные заголовки и коды HTTP без доменного смысла; имена полей OpenAPI, если это чистый transport (requestId, timestamp); аббревиатуры из appendix Acronyms (§3.6). Регистрируем: объекты домена, KPI, статусы workflow, роли с бизнес-смыслом, enum-понятия (см. правило value ≠ term ниже). Согласованность glossary ↔ SRS до gate — через 08.04 Рецензирование и инспекции (техники Фейгана) или 08.03 Тестирование требований (статическое тестирование). |
3.3. Раздел «Глоссарий» (business glossary)
Реестр бизнес-терминов. Одна строка = один Term ID. Определение — plain language для domain owner, без деталей реализации.
Правило value ≠ term: код enum (PendingApproval, DRAFT) — значение, не Term. Term заводят для понятия («Статус заявки» → T-LEAVE-002); допустимые коды — в appendix LOV (§3.6) с расшифровкой. Отдельный Term на каждое значение enum не нужен, если код не фигурирует как самостоятельное бизнес-понятие в BRD/KPI. Исключение: код — отдельная сущность в отчётности или regulation (напр. «Код вида дохода по ФНС») — тогда свой Term ID.
| Поле | Обяз. | Что писать |
|---|---|---|
| Term ID | да | Стабильный ключ (T-LEAVE-001); не переименовывать при смене wording — меняется display name, ID остаётся. |
| Термин (business name) | да | Каноническое имя на языке бизнеса. |
| Определение | да | Одно предложение + при необходимости контекст, исключения, counterexamples. |
| Определение (i18n) | нет | Для regulated/domains: перевод или локализованная формулировка; каноническое определение — одно (обычно RU или EN по регламенту проекта). UI label ≠ определение — label в mapping UI словаря. |
| Домен / subject area | да | Напр. «Кредитование», «Клиент», «Leave Management». |
| Синонимы, аббревиатуры | да | Допустимые альтернативы; запрещённые синонимы, если путают (напр. «отпуск» ≠ «больничный»). |
| Владелец (business owner) | да | Роль или ФИО, утверждающий определение. |
| Data steward | да | Кто поддерживает реестр и согласует изменения с IT. |
| Статус | да | draft | approved | deprecated + версия/дата утверждения. |
| Связанные термины | нет | broader / narrower / related — для навигации по домену. |
| Источник определения | да | BRD п., регламент, закон, протокол воркшопа. |
| Связь с требованиями | да* | ID user story / FR / BR. *Минимум для ключевых терминов релиза. Для KPI и бизнес-целей — ссылка на 02.03.01 Классификация требований (БТ, ФТ, НФТ). |
3.4. Раздел «Словарь данных» (data dictionary)
Cross-reference слой: Element ID, семантика, mapping. Не дублирует DDL и JSON Schema — детали constraints каноничны в 10.01.03 Шаблон спецификации БД сервиса и API/MQ-шаблонах (§1). Группировка: по домену, сущности LDM или сервису (bounded context).
| Поле | Обяз. | Что писать |
|---|---|---|
| Element ID | да | Стабильный ключ (E-LR-STATUS); не менять при переименовании колонки без change log (§3.2). |
| Term ID (ссылка) | да* | Связь с глоссарием. *Обязательно для business-meaningful полей. Атрибут ссылается на Term атрибута, если он есть; иначе — на Term родительской сущности (напр. employeeId → «Сотрудник»). Атрибуты с самостоятельными бизнес-правилами (границы периода, лимиты, cross-field validation в BRD) — отдельный Term ID, даже если поле принадлежит родительской сущности. |
| Logical name | да | Имя на уровне домена / LDM. |
| Physical name | да | table.column, JSON path, XML element, topic field — где элемент живёт; при multi-service — префикс сервиса. Кратко; полная DDL — в DB-spec по Element ID. |
| Описание (business + technical) | да | Business — ссылка на Term ID, не дословное копирование глоссария; technical — роль поля в системе (1–2 предложения). |
| Тип (кратко) | да | UUID, enum, decimal(18,2) — для навигации; точный DDL/SQL type — в DB-spec. |
| Nullable, default | да | Business-обязательность; исполнимый default — в DB-spec / OpenAPI. |
| Cardinality, PK/FK | нет | Только ссылка на DB-spec или ER-фрагмент — не копировать из 10.01.03 Шаблон спецификации БД сервиса. |
| Допустимые значения | да* | Ссылка на LOV-ID в §3.6 или краткий список кодов; полный enum — appendix + синхронизация с OpenAPI/AsyncAPI/CHECK в spec. |
| Правила валидации | да | Business-правила plain language; формулы cross-field. Исполнимая validation — в spec, не здесь. |
| Источник данных | да | System of record, manual input, integration, вычисляемое. |
| Mapping в API (REST/SOAP) | да* | Property/parameter + spec-ID — 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API. *Если поле в синхронном контракте. |
| Mapping в события (AsyncAPI/MQ) | да* | Topic, payload field + spec-ID — 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ). *Если поле в асинхронном контракте. |
| Mapping в UI | нет | Label, control ID + FE-spec-ID — 10.01.09 Шаблон описания экранной формы и логики на FE; locale label ≠ canonical term. |
| Процесс / состояние | нет | Для workflow-полей — согласование имён состояний с 10.01.08 Шаблон сквозной фичи (BPMN-процесс); Term «Статус» ↔ states в BPMN, коды — в LOV. |
| Чувствительность | да | PII/PCI, masking, retention — 10.01.12 Шаблон нефункциональных требований (NFR); классификация согласуется с 08.07 Основы кибербезопасности для системного аналитика при необходимости. |
| Примеры valid/invalid | да | Для тест-дизайна и ревью; у invalid укажите сценарий (create, submit, update). |
3.5. Связи для трассировки (минимум в gloss/doc)
В глоссарии и словаре достаточно колонок «Связь с требованиями» (§3.3) и Term ID ↔ Element ID. Сводная матрица Term/Element → FR → spec → test — отдельный артефакт 10.01.15 Шаблон матрицы трассировки; строки RTM ссылаются на Term ID и Element ID из этого документа, а не дублируют определения. Типы связей для RTM: Term ↔ FR, Element ↔ entity/API/event/UI, FR ↔ spec ↔ test.
3.6. Приложения
| Поле | Обяз. | Что писать |
|---|---|---|
| Справочники (enum / LOV) | да* | LOV-ID, код, расшифровка, owner; единый источник кодов для API, AsyncAPI и БД. *Если есть перечисления. Коды привязаны к Term понятия (напр. T-LEAVE-002), не к отдельным Term на каждое значение — см. value ≠ term (§3.3). |
| Acronyms | нет | Аббревиатуры проекта; перечисленные здесь не требуют Term ID при lint gate. |
| Deprecated terms | да | Старое имя → новое, срок миграции, alias в API/событиях; дублирует строки change log (§3.2) в человекочитаемом виде. |
| Открытые вопросы | нет | Нерешённые определения с владельцем и дедлайном. |
| Changelog документа | да | Версионный журнал GLOSS-*: версия документа, дата, автор, summary изменений. Отличие от change log (§3.2): changelog — «выпущена v1.3»; change log — «Term T-LEAVE-001 переименован, sunset API alias». |
3.7. Чеклист качества перед sign-off
- Выбран уровень minimal / standard / full; обязательные поля уровня заполнены.
- Глоссарий и словарь — две явные секции (или minimal §3.0); business-определения не содержат типов SQL и имён таблиц.
- Single source of detail: constraints не продублированы между словарём и DB/API spec; в spec есть Element ID.
- У каждого ключевого термина релиза есть Term ID, owner, статус approved.
- У business-meaningful полей есть Element ID и семантически верная ссылка на Term ID; атрибуты с отдельными бизнес-правилами — свой Term.
- Enum: Term на понятие, коды в LOV; lint gate без ложных срабатываний на технические термины и Acronyms (10.04 Чеклист аналитика перед стартом разработки).
- Enum в LOV совпадает с OpenAPI, AsyncAPI и CHECK в БД (проверка в spec, не в словаре).
- PII/retention помечены; ссылки на NFR-ID заполнены.
- Mapping REST/SOAP ↔ MQ ↔ БД ↔ UI ↔ BPMN согласован с артефактами 10.01 того же релиза.
- Change log и changelog документа разведены; deprecated-политика: alias period, sunset, версия API (03.05.07 Управление версионированием API и жизненным циклом).
- Примеры valid/invalid есть для полей с нетривиальной валидацией; invalid привязан к переходу/операции.
- Согласованность glossary ↔ SRS проверена (08.04 Рецензирование и инспекции (техники Фейгана) / 08.03 Тестирование требований (статическое тестирование)).
- Сводная трассировка Term/Element → FR → spec → test — в 10.01.15 Шаблон матрицы трассировки или явная ссылка на RTM-ID.
4. Пример заполнения
Урезанный фрагмент для иллюстрации связок Term ↔ Element ↔ spec. Полный перечень полей — §3.3 и §3.4; не копируйте этот блок как эталон таблицы.
Сценарий: HR Portal — модуль заявок на отпуск (данные условны).
Паспорт: GLOSS-HR-LEAVE-v1 · HR Portal / leave-service · standard · Approved · v1.2, 2026-03-10 · Upstream: BRD-GOAL-011, SRS-HR-LEAVE-v2 · Согласующие: HR Director (owner), SA Иванова (steward) · Связанные: DB-LEAVE-v2, API-LEAVE-001, PROD-LEAVE-001, BPMN-LEAVE-01, NFR-DATA-007
Принципы. Golden source — этот документ. Single source: DDL/checks — DB-LEAVE-v2; JSON Schema — API-LEAVE-001. API: camelCase; БД: snake_case. UI label RU — отдельно от canonical EN term. Изменение approved-термина — change log + changelog документа; breaking rename API = новая major-версия.
Глоссарий (фрагмент)
| Term ID | Термин | Определение | Домен | Синонимы | Запрещено | Owner | Статус | Source | FR |
|---|---|---|---|---|---|---|---|---|---|
| T-LEAVE-001 | Заявка на отпуск | Формализованный запрос сотрудника на использование оплачиваемых или неоплачиваемых дней отпуска за указанный период; не включает больничный и командировку. | Leave | «заявление на отпуск» | «отпуск» как синоним заявки | HR Director | approved | BRD §4.2 | SRS-REQ-038, US-0238 |
| T-LEAVE-002 | Статус заявки | Текущее состояние заявки в workflow согласования; определяет доступные действия ролей. Коды состояний — LOV-LEAVE-STATUS (§3.6), не отдельные Term. | Leave | — | «стадия», «phase» | HR Director | approved | UC-Leave-03, BPMN-LEAVE-01 | SRS-REQ-039 |
| T-LEAVE-003 | Сотрудник | Физическое лицо, состоящее в трудовых отношениях с организацией и идентифицируемое в IAM; субъект, от имени которого создаётся заявка. | HR Core | «работник» | «пользователь системы» | HR Director | approved | BRD §3.1 | SRS-REQ-037 |
| T-LEAVE-004 | Начало периода отпуска | Первый календарный день запрашиваемого отпуска; задаётся сотрудником при создании заявки; не может быть позже окончания периода. | Leave | «дата начала» | — | HR Director | approved | BRD §4.2 | SRS-REQ-040 |
Словарь данных (фрагмент)
| Element ID | Term ID | Logical | Physical | Тип | Null | Правило / LOV | Spec ref | Чувств. | Valid | Invalid (сценарий) |
|---|---|---|---|---|---|---|---|---|---|---|
| E-LR-STATUS | T-LEAVE-002 | status | leave_request.status | enum | нет | LOV-LEAVE-STATUS | DB-LEAVE-v2 §3.2; API-LEAVE-001 | internal | PendingApproval | Approved при create |
| E-LR-EMPLOYEE | T-LEAVE-003 | employeeId | leave_request.employee_id | UUID | нет | FK → IAM | DB-LEAVE-v2 §3.1 | PII | 550e8400-… | пустая строка при submit |
| E-LR-PERIOD-START | T-LEAVE-004 | periodStart | leave_request.start_date | date | нет | start ≤ end; не в прошлом при submit | API-LEAVE-001 | internal | 2026-04-01 | 2025-01-01 при submit |
LOV-LEAVE-STATUS (фрагмент appendix). Term: T-LEAVE-002. Коды: Draft, PendingApproval, Approved, Rejected, Cancelled — расшифровки и owner HR Director; синхрон с BPMN-LEAVE-01 states.
Deprecated (фрагмент). Term T-LEAVE-010 «Leave application» → заменён на T-LEAVE-001; API alias leaveApplication до 2026-09-01 — строка в change log §3.2.
Трассировка: сводная матрица RTM-HR-LEAVE-v1 — T-LEAVE-001 → US-0238 → E-LR-* → DB-LEAVE-v2, API-LEAVE-001 → TC-UAT-012 (10.01.15 Шаблон матрицы трассировки).
5. Связанные артефакты
На входе (upstream)
| Артефакт | Связь |
|---|---|
| Vision & Scope, BRD | Источник терминов, KPI, бизнес-правил; встроенный glossary → extract в GLOSS-* — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) |
| SRS, черновик FR | Формулировки требований должны использовать approved Term ID — 02.03.03 Спецификация требований (SRS, Use Case, User Story) |
| 10.01.01 Шаблон User Story / 10.01.02 Шаблон Use Case | Акторы и объекты домена → кандидаты в глоссарий; Term ID в описании или AC |
| Интервью, воркшопы, регламенты | 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии |
| ER-диаграмма / LDM (черновик) | 03.03.01 ER-диаграммы (сущность-связь), 03.03.02 Логическая и физическая модель данных |
| 10.01.11 Шаблон ролевой модели | Кто утверждает/редактирует термины (data steward, domain owner) |
На выходе (downstream)
| Артефакт | Когда создавать / обновлять |
|---|---|
| 10.01.03 Шаблон спецификации БД сервиса | DDL и constraints по Element ID; словарь не дублирует PDM |
| 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API | Properties с Term/Element ID; enums из LOV appendix |
| 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ) | Имена полей payload, schema version |
| 10.01.08 Шаблон сквозной фичи (BPMN-процесс) | States/gateways ↔ Term workflow-статусов; коды — LOV, не дублировать BPMN в глоссарии |
| 10.01.09 Шаблон описания экранной формы и логики на FE | Labels, маски, validation messages → Term ID |
| 10.01.12 Шаблон нефункциональных требований (NFR) | Классификация данных, retention, audit, локализация |
| 10.01.15 Шаблон матрицы трассировки | Term/Element → FR → spec → test |
| Test data / fixtures | Примеры valid/invalid из словаря |
Типичный порядок работы аналитика
- Собрать кандидатов в термины из BRD, интервью, legacy-документов → черновик глоссария (draft); glossary из BRD — extract, не дублировать.
- Согласовать определения с domain owner на воркшопе; зафиксировать Term ID, LOV для enum-понятий и запрещённые синонимы.
- Ввести Element ID для ключевых атрибутов до детализации API и БД; в спеках ссылаться на ID, не на «красивые» названия.
- Параллельно с 10.01.03 Шаблон спецификации БД сервиса, API/MQ-спекой и 10.01.08 Шаблон сквозной фичи (BPMN-процесс) заполнить mapping и согласовать workflow-states.
- Ревью согласованности glossary ↔ SRS (08.04 Рецензирование и инспекции (техники Фейгана)); gate: lint Term ID с учётом исключений (§3.2).
- При переименовании — строка change log, запись changelog документа, deprecated-политика, обновление 10.01.15 Шаблон матрицы трассировки и контрактов (02.05.02 Управление изменениями (Change Control Board) при formal change control).
6. Связи с другими разделами базы
- Словарь данных: теория, метаданные, ISO 11179 — 03.03.03 Словарь данных (описание)
- ER-диаграммы и LDM/PDM — 03.03.01 ER-диаграммы (сущность-связь), 03.03.02 Логическая и физическая модель данных
- Bounded context и ubiquitous language — 03.06.02 Основы Domain-Driven Design
- Классификация требований: KPI/БТ vs поля ФТ — 02.03.01 Классификация требований (БТ, ФТ, НФТ)
- BPMN и workflow-семантика — 10.01.08 Шаблон сквозной фичи (BPMN-процесс), 03.04.01 BPMN 2.0 - введение и основы
- OpenAPI, AsyncAPI, версионирование контрактов — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf), 03.05.07 Управление версионированием API и жизненным циклом
- Трассировка и качество требований — 02.03.04 Трассировка требований (концепция), 02.04.03 Управление качеством требований, 02.04.01 Верификация и валидация (V&V)
- Ревью и статическое тестирование требований — 08.04 Рецензирование и инспекции (техники Фейгана), 08.03 Тестирование требований (статическое тестирование)
- Жизненный цикл термина vs требования — 02.05.05 Жизненный цикл требования
- НФТ и классификация данных — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 08.07 Основы кибербезопасности для системного аналитика
- Стандарты BA/SA — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)
- Чеклист перед стартом разработки — 10.04 Чеклист аналитика перед стартом разработки
7. Источники и дополнительные материалы
Книги и стандарты
- DAMA International — Data Management Body of Knowledge (контекст glossary, metadata, data dictionary) — https://www.dama.org/
- IIBA — BABOK Guide (глоссарий как техника снижения неоднозначности) — https://www.iiba.org/standards-and-resources/babok/; своды знаний в базе — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)
- ISO/IEC 11179-1:2015 — метаданные и регистрация элементов данных (data elements) — https://www.iso.org/standard/50382.html
Статьи и практики
- IBM — Data governance / business glossary (glossary в рамках data governance) — https://www.ibm.com/topics/data-governance
- Microsoft Learn — Business glossary in Purview (поля метаданных, stewardship) — https://learn.microsoft.com/en-us/purview/concept-business-glossary