Ролевая модель (Role Model) — артефакт системного аналитика, который фиксирует кто (субъекты и роли) что может делать с какими объектами в системе или домене. Это не замена User Story / Use Case (там — сценарии и акторы), не спецификация API (там — контракты), но источник требований для авторизации (authorization), UI (видимость действий), интеграций и NFR по безопасности. На проекте модель обычно опирается на RBAC (Role-Based Access Control): роль → набор разрешений; при необходимости — иерархия ролей, ограничения и атрибуты (ABAC). ReBAC (Relationship-Based Access Control — права через граф «кто кому/чему связан») в flat-матрице не описывается: выносите в 10.01.13 Шаблон архитектурного решения (ADR) и отдельный каталог связей. Теория RBAC/ABAC, least privilege и модель угроз — в 08.07 Основы кибербезопасности для системного аналитика и 08.02 Нефункциональные требования (НФТ) — классификация и стандарты; здесь — только поля рабочего документа.

1. Назначение

Документ пишет системный аналитик; его читают архитектор, разработка (BE/FE), QA, информационная безопасность, владелец продукта и compliance на этапах проектирования, реализации и приёмке.

Шаблон закрывает четыре задачи:

  • Контракт авторизации — проверяемая матрица «субъект/роль × ресурс × операция» с явным allow/deny; не «по договорённости на встрече».
  • Мост бизнес → реализация — бизнес-роли из BRD и акторы из Use Case переводятся в разрешения (permissions), которые реализуют API gateway, policy engine, ACL в БД и guards на FE.
  • Единый каталог для смежных артефактов — User Story, REST API, экранные формы, BPMN и NFR ссылаются на Role ID и Permission ID как на канонический источник политики доступа.
  • Точка трассировки и тестирования — Role Model → SRS (FR/NFR) → API scopes → UI matrix → security test cases; основа для UAT и regression по границам ролей.

Ролевая модель относится к авторизации, а не к аутентификации (authentication): вход в систему (SSO, MFA, пароль) — отдельный контур; здесь — проверка прав после входа.

2. Когда использовать

Подходит, если:

  • в системе несколько ролей с разным доступом к данным и операциям;
  • Use Case / User Story описывают акторов, но не фиксируют полномочия в проверяемом виде;
  • нужны требования для API (403/404 policy, scopes), FE (видимость кнопок/полей), BPMN (назначение задач по ролям);
  • домен регламентирован: SoD (Separation of Duties), least privilege, аудит критичных операций;
  • микросервисы или несколько модулей — нужен canonical role catalog на bounded context или продукт, чтобы права не расходились между командами (граница контекста — 03.01.03 Декомпозиция системы на подсистемы и модули, роли в доменах — 03.06.02 Основы Domain-Driven Design).

Не подходит или требует дополнения, если:

  • приложение без разграничения доступа между пользователями — полная матрица избыточна, но для API, audit и интеграций часто достаточно одной роли AuthenticatedUser и default deny на остальное; NFR «все равны» не отменяет фиксацию Permission ID;
  • нужен только пошаговый сценарий без системной модели прав — 10.01.02 Шаблон Use Case / 10.01.01 Шаблон User Story;
  • детали контракта endpoint'ов — 10.01.04 Шаблон спецификации REST API; ролевая модель задаёт policy, API spec — контракт с обратной трассировкой на Permission ID;
  • выбор RBAC vs ABAC vs ReBAC, central IAM, модель хранения прав — архитектурное решение в 10.01.13 Шаблон архитектурного решения (ADR);
  • провижининг пользователей в AD/LDAP, жизненный цикл учётных записей — корпоративная политика IdM; в артефакте — ссылка и маппинг групп, не полный реестр пользователей;
  • практически все решения зависят от атрибутов (отдел, регион, классификация данных) — flat-матрица «роль × ресурс» неполна; добавьте блок правил ABAC (§3.9) или отдельный ADR;
  • права зависят от графа связей (org hierarchy, sharing, delegation chains) — ReBAC; flat-матрица §3.8 не заменяет ADR и отдельный каталог связей.

Входные условия: границы продукта/модуля зафиксированы (02.01.04 Определение границ решения (Scope Modelling), 03.01.02 Моделирование контекста системы (Context Diagram)), ключевые сценарии и акторы известны (10.01.02 Шаблон Use Case), термины согласованы (10.01.14 Шаблон глоссария и словаря данных). Перед разработкой убедитесь, что матрица и default deny есть — см. 10.04 Чеклист аналитика перед стартом разработки.

Актор Use Case ↔ Role ID: актор UC — источник сценариев и операций; Role ID — модель прав. Связь many-to-many: один актор может мапиться на несколько ролей, одна роль — на несколько акторов; системные акторы и Guest / anonymous документируются отдельно. Маппинг фиксируйте таблицей в §3.5, не подменяя Role ID именем актора из диаграммы (03.02.01 Диаграмма прецедентов (Use Case Diagram) — теория акторов).

Permission sets vs чистая матрица: пока ролей ≤ 10–15 и permissions повторяются редко — достаточно §3.8. Переходите на именованные permission sets, когда одни и те же наборы из 5+ permissions дублируются в трёх и более ролях или матрица становится нечитаемой.

Уровень зрелости RBAC (NIST): в метаданных явно укажите, что заявлено в проекте — flat RBAC, иерархия ролей, ограничения (cardinality, SoD) или администрирование ролей. Не обещайте в документе уровень, который команда не реализует.

3. Структура документа

Скопируйте блок в Confluence, RM-инструмент или репозиторий документации. Поля с пометкой обяз. нужны для «готовности к разработке»; остальные — по контексту и уровню зрелости RBAC.

MVP (Flat RBAC, первая итерация): §3.1–3.8, §3.13–3.16. §3.9 — пометка N/A, если нет атрибутных условий. §3.10 — только при Hierarchy в метаданных. §3.11 — только при SoD в метаданных или regulated-домене. §3.12 — по чувствительности ресурсов из §3.6.

3.1. Метаданные

ПолеОбяз.Что писать
ID документадаУникальный идентификатор, напр. RM-PORTAL-001. Схема ID — 10.01.15 Шаблон матрицы трассировки.
НазваниедаПродукт / модуль + «Ролевая модель», напр. «HR Portal — Leave Management».
Версия, статус, датадаDraft → Review → Approved; автор последнего изменения.
Версия релиза / APIдаСвязь RM vX.Y ↔ релиз продукта или major версия API; breaking change в правах = новая версия RM и impact в downstream — 02.05.05 Жизненный цикл требования.
Продукт / сервисдаСистема, bounded context или набор микросервисов в scope.
Уровень RBAC (NIST)даFlat / Hierarchy / Constrained / Administrative — что реально будет в релизе.
Upstream: BRD / SRS / EpicдаBRD-GOAL-xxx, черновик SRS-REQ-xxx, epic ID.
Владелец модели (business owner)даРоль или ФИО, утверждающий изменения ролей.
Процесс изменениядаКто инициирует, кто согласует (ИБ, compliance), где фиксируется changelog — см. 02.05.02 Управление изменениями (Change Control Board) при формальном процессе.

3.2. Цель и область

ПолеОбяз.Что писать
Цель документада1–2 предложения: зачем модель (напр. «разграничить доступ к заявкам на отпуск и отчётам по регионам»).
Scope (внутри)даПриложения, модули, интеграции, входящие в модель.
Out of scopeдаЧто явно не входит: провижининг в AD, MFA, модель другого продукта, внутренние роли вендора, отдельный каталог OAuth-клиентов (если вынесен в ADR), ReBAC / граф связей (если не flat RBAC).

3.3. Принципы и правила

Здесь — решения продукта, одинаковые для BE, FE и policy engine. Маппинг на endpoint и control — в §3.13.

ПолеОбяз.Что писать
Default denyдаТекстом: «Всё, не указанное в матрице как allow, запрещено».
Least privilegeдаРоли получают минимум прав для выполнения функции.
Разрешение конфликта allow/denyдаОдно правило на весь продукт: напр. «deny wins» или «явный приоритет в колонке Priority».
Политика 403 vs 404даПо типу операции: get-by-id чужого ресурса — 404 или 403; list/collection — пустой результат vs 403; create/update без права — 403. Согласовать с API и FE до заполнения §3.13.
Anonymous / publicнетКакие ресурсы доступны без роли; Role ID Anonymous или отдельный каталог public permissions.
Multi-tenantнетПри необходимости: tenant_id в ABAC, cross-tenant deny по умолчанию.
ДелегированиенетМожет ли субъект временно передать полномочия; срок, аудит grant/delegate.
Временные роли / break-glassнетEmergency access: кто утверждает, срок, обязательный аудит.
Маппинг на IdMнетГруппа AD / claim SSO ↔ Role ID; не путать роль приложения и группу каталога.

3.4. Модель субъекта (Subject)

К кому применяются роли и строки матрицы — фиксируйте явно до заполнения глоссария. Единая таксономия типов субъекта (не путать с типом роли business / integration в §3.5):

ПолеОбяз.Что писать
Тип субъектадаhuman_user / service_account / api_client (OAuth client credentials) / delegate (действует от имени другого).
Subject ID / claimдаЧто попадает в policy: user_id, sub, client_id, service_principal.
Источник ролейдаIdM, локальная БД, JWT claims, API key metadata.
В scope матрицыдаДа/нет: попадает ли тип в §3.8 или права описаны в отдельном листе (напр. каталог M2M-клиентов — 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ) с перекрёстной ссылкой на Permission ID).
Role ID для типадаКакие Role ID из §3.5 допустимы; для service_account и api_client — роли с типом integration в §3.5, не смешивать с business без обоснования.

service_account и api_client либо получают строки в той же матрице §3.8, либо отдельный лист/ADR с теми же Permission ID — канон остаётся в каталоге §3.7.

3.5. Глоссарий ролей

ПолеОбяз.Что писать
Role IDдаСтабильный идентификатор, напр. ROLE-EMP-01, ROLE-MGR-REG-WEST.
Название ролидаПонятное бизнес-имя: «Сотрудник», «Руководитель региона Запад».
Описание / назначениедаКакую функцию выполняет; не должность из HR «один к одному» — оргструктура (manager, dept) задаётся атрибутами ABAC (§3.9), не отдельной HR-ролью на каждую должность.
Тип ролидаBusiness / system / integration (сервисный аккаунт, batch job, M2M-клиент).
Business ownerдаКто отвечает за смысл и изменения роли.
Жизненный циклнетКак запрашивается, кем утверждается, как отзывается.
ТрассировкадаSRS-REQ-xxx, US-xxx, UC-xxx — ссылки, не пересказ.
Маппинг актор UC → Role IDда*Таблица: UC Actor ↔ Role ID (1:N). *Обязательно, если есть Use Case.

Правило именования: паттерн «функция + контекст» (ClaimReviewer_Region), не ФИО и не «Admin на всё» без обоснования.

3.6. Каталог ресурсов

ПолеОбяз.Что писать
Resource ID / типдаИдентификатор типа объекта: leave_request, report:balance, screen:FE-LEAVE-LIST-02. Первый сегмент Permission ID (§3.7) должен совпадать с Resource ID или быть его префиксом (report:balance → Permission report:balance:export).
ОписаниедаЧто за сущность или технический объект.
ИерархиянетРодитель/дочерние ресурсы (папка → документ).
Чувствительность данныхнетКлассификация по 08.02 Нефункциональные требования (НФТ) — классификация и стандарты; доменные ограничения (PCI, персональные данные) — 08.06 Юридические и регуляторные требования РФ (PCI-DSS).
Источник в модели данныхнетСущность из 10.01.03 Шаблон спецификации БД сервиса или термин из 10.01.14 Шаблон глоссария и словаря данных.

3.7. Каталог операций

ПолеОбяз.Что писать
Operation IDдаНормализованное имя: create, read, update, delete, approve, export, configure или доменный глагол.
Permission IDдаАтомарное право. Соглашение: {resource_id}:{operation_id} или {resource_id}:{operation_id}:{scope}. Примеры: leave_request:approve (два сегмента); leave_request:read:own, leave_request:read:team (третий сегмент scope — когда одна операция над ресурсом даёт разные строки матрицы). {resource_id} = Resource ID из §3.6. Scope фиксируйте в каталоге, если BE/policy engine проверяет его как часть permission string. Динамические условия (dept, status, owner) — в §3.9 (ABAC), не в Permission ID, кроме стабильных scope из каталога.
ОписаниедаЧто означает операция в домене; избегать синонимов «редактировать» / «изменить» в разных местах.

3.8. Матрица доступа (основной артефакт)

Одна строка = одна комбинация Role ID + Permission ID + Effect. Не декартово произведение «все роли × все ресурсы»: каждое право — явная запись из каталога §3.7. Колонка Resource ID дублирует первый сегмент Permission ID для читаемости и сверки с §3.6. При иерархии ролей (§3.10) строки задаются для листовых ролей или явно помечаются «наследуется от родителя».

ПолеОбяз.Что писать
Role IDдаИз глоссария ролей.
Resource IDдаИз каталога ресурсов; = первый сегмент Permission ID.
Permission IDдаИз каталога операций §3.7 — каноническая колонка для трассировки в API/FE.
Effectдаallow / deny; при конфликте — только по правилу из §3.3.
Условие (ABAC)нетRule ID из §3.9 (предпочтительно) или согласованный inline одной строкой. Если Rule ID — правило обязано быть в §3.9.
ОбоснованиедаID требования (SRS-REQ-038) или бизнес-правило.
ПримечаниянетОграничения по времени, объёму данных, audit level.

Checklist матрицы: для каждой значимой бизнес-операции из Use Case — хотя бы одна строка с явным allow или deny.

3.9. Правила ABAC (при атрибутах)

Заполняйте, если в §3.8 есть условия или домен «только свои / команда / регион». Flat RBAC без атрибутов — раздел N/A.

ПолеОбяз.Что писать
Rule IDдаНапр. ABAC-OWN-01.
Атрибутдаowner, manager, dept, tenant_id, status, claim из SSO.
Операторда=, in, !=, matches.
Значение / источникдаsubject.id, user.claims.dept, константа.
Применяется к Permission IDдаОдно или несколько permissions из §3.7.

Согласованность с §3.8: каждый Rule ID в колонке «Условие» матрицы имеет строку здесь; inline в матрице допустим только для тривиальных правил и с пометкой «inline, без Rule ID» в changelog — иначе BE и QA расходятся в интерпретации.

3.10. Иерархия и композиция ролей

ПолеОбяз.Что писать
Родительская рольнет*Role ID старшей роли. *Обязательно, если заявлен уровень Hierarchy в NIST.
Включает ролинет*Таблица «роль A включает роли B, C». *Обязательно при Hierarchy.
Effective permissionsнет*Правило вычисления: напр. «union дочерних allow, затем minus deny родителя и потомка; deny wins из §3.3». *Обязательно при Hierarchy.
Permission setsнетИменованные наборы permissions (PS-LEAVE-READ), переиспользуемые ролями — см. критерий в §2.

Документируйте иерархию явно: «тихое» наследование — частая причина неожиданного расширения прав.

3.11. SoD и конфликты

Разделяйте два смысла: (1) SoD ролей — пары Role ID, которые IdM не должен назначить одному субъекту; (2) операционные правила — запрет действия над объектом (создатель ≠ approver) через ABAC/deny в §3.8, не через псевдо-SoD «на одну заявку».

ПолеОбяз.Что писать
Конфликтующие роли (SoD)нет*Пары Role ID, несовместимые на одном subject. *Обязательно в финансах, HR, compliance.
Конфликтующие операциинетБизнес-запреты уровня объекта (не смешивать с SoD ролей); реализуются ABAC или deny в матрице.
ОбоснованиенетСсылка на регуляторику или политику ИБ.

3.12. Исключения, эскалации и аудит

ПолеОбяз.Что писать
Роль / режимнетSuper-admin, support read-only, emergency access.
Условия активациинетTicket, двойное утверждение, срок действия.
Аудит: allowда*События при успешном доступе к операциям с высокой чувствительностью (классификация из §3.6 / NFR). *Обязательно для ресурсов с чувствительностью ≥ internal/confidential.
Аудит: denyдаЯвно: все deny, только deny на критичные permissions, или только break-glass; по умолчанию рекомендуется audit deny на approve/delete/export.

«Критичный домен» операционализируйте через классификацию ресурса (§3.6) и NFR — 10.01.12 Шаблон нефункциональных требований (NFR), не субъективно.

3.13. Маппинг на реализацию

Master-detail: Role Model — канонический источник Permission ID и политики. Здесь только привязка Permission ID к endpoint, control, lane — без повторного обсуждения 403/404 (решение в §3.3). Спецификации API и FE обязаны содержать обратную трассировку Permission ID.

ПолеОбяз.Что писать
Permission → APIда*Permission ID ↔ endpoint/method ↔ policy name — 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API; семантика HTTP — 07.02 Работа с API (практика). *Для каждого значимого API в scope.
Permission → UIда*Control ID ↔ Permission ID — 10.01.09 Шаблон описания экранной формы и логики на FE.
Permission → BPMNнетCandidate groups: имя group = Role ID (или таблица group name ↔ Role ID) — 10.01.08 Шаблон сквозной фичи (BPMN-процесс); нотация пулов/дорожек — 06.02.02 Пулы, дорожки и артефакты.
Permission → messagingнетProducer/Consumer topic/action ↔ Permission ID — 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ).
OAuth scopes / claimsнетScope ↔ Permission ID; детали протокола — 03.05.05 Безопасность API.
События аудитанетИмя события, payload, retention — 10.01.12 Шаблон нефункциональных требований (NFR).

3.14. Тестовые сценарии доступа

ПолеОбяз.Что писать
Test IDдаНапр. TC-RM-012-positive, TC-RM-012-negative.
Субъект / Role IDдаRole ID и при необходимости тип subject.
Действие / ресурсдаЧто проверяем.
Ожиданиеда200 + данные / 403 / 404 / пустой list / скрытый UI / audit log — по §3.3.
ТрассировканетUC / US / API operation / Permission ID.

Минимум: positive и negative на границах каждой ключевой роли; включая смену id в URL (horizontal privilege escalation) — 08.07 Основы кибербезопасности для системного аналитика.

Статическая проверка до Review (08.03 Тестирование требований (статическое тестирование)): покрытие операций из UC строками матрицы; orphan Permission ID без маппинга API/UI; симметричные deny на путях эскалации (approve/delete/export); согласованность Rule ID §3.9 ↔ колонка «Условие» §3.8.

3.15. Открытые вопросы и история изменений

ПолеОбяз.Что писать
TBDнетВопрос, владелец, срок решения.
История измененийдаВерсия, дата, автор, суть; breaking change в правах = changelog, версия RM и impact на API/FE/релиз.

3.16. Чеклист качества перед Review

  • Default deny и единое правило конфликта allow/deny (§3.3) зафиксированы.
  • Модель субъекта (§3.4): human_user / service_account / api_client — кто в матрице, кто в отдельном листе M2M.
  • Соглашение Permission ID (§3.7) соблюдено: scope в ID vs ABAC в §3.9.
  • У каждой роли — уникальный Role ID; роли ≠ должности HR; маппинг UC Actor ↔ Role ID заполнен.
  • Матрица: одна строка = один Permission ID; ABAC-правила (§3.9) согласованы с колонкой «Условие».
  • Политика 403 vs 404 (§3.3) согласована с API и FE; §3.13 содержит только маппинг.
  • Иерархия (если есть): таблица наследования + правило effective permissions.
  • SoD ролей (§3.11) отделён от операционных deny/ABAC («не approve own»).
  • Маппинг Permission → API/UI/messaging заполнен; downstream ссылается на Permission ID как на master.
  • Есть negative test cases, в т.ч. чужой resource id; статическая сверка по §3.14.
  • Версия RM связана с версией релиза/API; трассировка к BRD/SRS и 10.01.15 Шаблон матрицы трассировки заполнена.
  • Review по процессу — 08.04 Рецензирование и инспекции (техники Фейгана).

4. Пример заполнения

Сокращённый фрагмент для HR Portal — модуль Leave Management (данные условны).

Метаданные: RM-HR-LEAVE-001 · HR Portal — Leave Management · v1.0 · релиз 2026.3 · Approved · Уровень RBAC: Flat + SoD · Upstream: BRD-GOAL-011, SRS-REQ-038–040 · Владелец: Product Owner HR · Изменения: через CCB.

Цель. Разграничить доступ сотрудников, руководителей и HR к заявкам на отпуск и отчётам по балансу.

Scope. HR Portal, модуль Leave Management, REST API leave-service. Out of scope: провижининг в Active Directory; роли модуля Payroll; ReBAC.

Принципы (§3.3). Default deny. Deny wins при конфликте. Least privilege. Get-by-id чужой заявки — HTTP 404; list — только свои/командные записи (filter server-side). Аудит: grant на leave_request:approve; deny на leave_request:approve и get-by-id чужой заявки.

Субъекты (§3.4): human_user (JWT sub) — в матрице §3.8; service_account leave-sync-job — ROLE-SVC-01 (тип роли integration), отдельная строка в §3.8.

Маппинг UC → Role:

UC ActorRole ID
EmployeeROLE-EMP-01
Line ManagerROLE-MGR-01
HR SpecialistROLE-HR-01

Глоссарий ролей (фрагмент):

Role IDНазваниеТипОписание
ROLE-EMP-01СотрудникbusinessПодаёт и просматривает свои заявки
ROLE-MGR-01РуководительbusinessСогласует заявки подчинённых (атрибут manager, не отдельная HR-должность)
ROLE-HR-01HR-специалистbusinessДоступ к заявкам и отчётам в рамках отдела
ROLE-SVC-01Leave sync jobintegrationBatch-синхронизация заявок (service_account)

Правила ABAC (фрагмент):

Rule IDАтрибутОператорЗначениеPermissions
ABAC-OWN-01owner=subject.idleave_request:read:own
ABAC-MGR-01manager=subject.idleave_request:read:team, leave_request:approve
ABAC-NO-SELF-APPROVEcreator!=subject.idleave_request:approve
ABAC-HR-01deptinuser.claims.deptreport:balance:export

Каталог операций (фрагмент):

Permission IDResource (§3.6)Описание
leave_request:createleave_requestСоздать заявку
leave_request:read:ownleave_requestЧитать свои заявки (scope :own)
leave_request:read:teamleave_requestЧитать заявки подчинённых (scope :team)
leave_request:approveleave_requestСогласовать / отклонить
report:balance:exportreport:balanceЭкспорт отчёта по балансу

Матрица доступа (фрагмент):

Role IDResource IDPermission IDEffectУсловиеREQ
ROLE-EMP-01leave_requestleave_request:createallow—SRS-REQ-038
ROLE-EMP-01leave_requestleave_request:read:ownallowABAC-OWN-01SRS-REQ-038
ROLE-EMP-01leave_requestleave_request:approvedeny—SRS-REQ-039
ROLE-MGR-01leave_requestleave_request:read:teamallowABAC-MGR-01SRS-REQ-039
ROLE-MGR-01leave_requestleave_request:approveallowABAC-MGR-01, ABAC-NO-SELF-APPROVESRS-REQ-039
ROLE-HR-01report:balancereport:balance:exportallowABAC-HR-01SRS-REQ-040

SoD ролей (IdM): Иллюстрация паттерна из finance-домена, не часть HR scope: одному human_user нельзя одновременно назначить ROLE-AUDITOR-01 и ROLE-ACCOUNTANT-01. Не путать с ABAC-NO-SELF-APPROVE — правило на уровне объекта заявки.

Permission sets: N/A (ролей 3, дублирования наборов нет).

Маппинг на реализацию (фрагмент):

Permission IDAPIUI
leave_request:approvePOST /leave/requests/{id}/approve — policy pol-leave-approveКнопка BTN-approve на FE-LEAVE-LIST-02
leave_request:read:ownGET /leave/requests — filter enforced server-sideСписок только своих записей

Тестовые сценарии:

  • TC-RM-001 · ROLE-EMP-01 · GET /leave/requests/REQ-1001 (чужая) → 404, audit deny.
  • TC-RM-002 · ROLE-MGR-01 · POST approve заявки подчинённого → 200, audit grant.
  • TC-RM-003 · ROLE-MGR-01 · POST approve своей заявки → 403 (ABAC-NO-SELF-APPROVE).

Трассировка (10.01.15 Шаблон матрицы трассировки, фрагмент):

Req IDPermission IDSolution (IDs)Test
SRS-REQ-038leave_request:create, leave_request:read:ownRM-HR-LEAVE-001, API-LEAVE-001, FE-LEAVE-LIST-02TC-RM-001
SRS-REQ-039leave_request:read:team, leave_request:approveRM-HR-LEAVE-001, API-LEAVE-001TC-RM-002, TC-RM-003
SRS-REQ-040report:balance:exportRM-HR-LEAVE-001, API-LEAVE-002TC-RM-004 (gap)

Цепочка: BRD-GOAL-011 → SRS-REQ-038–040 → UC-LEAVE-012, UC-LEAVE-013 → Permission ID → API-LEAVE-001, FE-LEAVE-LIST-02 → TC-RM-001–003.

5. Связанные артефакты

На входе (upstream)

АртефактСвязь
Vision & Scope, BRDБизнес-роли, оргконтекст, compliance — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
Scope / ContextГраница продукта и системы — 02.01.04 Определение границ решения (Scope Modelling), 03.01.02 Моделирование контекста системы (Context Diagram)
10.01.02 Шаблон Use CaseАкторы и операции — источник строк матрицы; маппинг актор ↔ Role ID
10.01.01 Шаблон User StoryРоли в формулировке «Как [роль]…»
10.01.14 Шаблон глоссария и словаря данныхЕдиные термины для ресурсов и ролей
10.01.13 Шаблон архитектурного решения (ADR)RBAC vs ABAC vs ReBAC, central IAM, M2M-клиенты
Stakeholder MapВладельцы бизнес-ролей — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map)

На выходе (downstream)

АртефактКогда создавать
SRS (FR / NFR)«The system shall enforce role-based access according to [Role Model vX]» + audit, session, least privilege — формулировки и классификация: 02.03.01 Классификация требований (БТ, ФТ, НФТ), 02.03.03 Спецификация требований (SRS, Use Case, User Story)
10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP APIAuthorization, scopes — трассировка на Permission ID; 403/404 по §3.3 RM
10.01.09 Шаблон описания экранной формы и логики на FEControl ID ↔ Permission ID
10.01.08 Шаблон сквозной фичи (BPMN-процесс)Candidate groups = Role ID
10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ) / 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ)Права producer/consumer ↔ Permission ID; субъекты service_account / api_client часто в отдельном листе §3.4
10.01.12 Шаблон нефункциональных требований (NFR)Аудит, классификация данных, session
10.01.03 Шаблон спецификации БД сервисаRow-level constraints при хранении прав в данных
10.01.15 Шаблон матрицы трассировкиREQ → Permission ID → API / FE / test → релиз

Типичный порядок работы аналитика

  1. Субъекты (§3.4) и операции из Use Case + сущности из модели данных → черновик ролей и permissions; соглашение Permission ID (§3.7).
  2. Матрица allow/deny + правило конфликта + default deny + политика 403/404 (§3.3).
  3. ABAC-правила (§3.9) и SoD ролей (§3.11) отдельно от операционных deny.
  4. Review с ИБ и business owner — 08.04 Рецензирование и инспекции (техники Фейгана).
  5. Маппинг Permission → API, FE, BPMN, messaging (§3.13); downstream ссылается на Permission ID как на master.
  6. Тестовые сценарии access → QA; строки в 10.01.15 Шаблон матрицы трассировки; версия RM ↔ релиз — 02.05.05 Жизненный цикл требования; breaking change — 02.05.02 Управление изменениями (Change Control Board).

6. Связи с другими разделами базы

Здесь — теория, которую сознательно не дублируем в полях шаблона (артефакты upstream/downstream — §5):

7. Источники и дополнительные материалы

Книги и стандарты

Статьи и практики