Матрица ролей и прав · Конспекты по бизнес-анализу

Что это#

В Руководстве BABOK® матрица ролей и прав (roles and permissions matrix) определяет роли, участвующие в действиях решения, и устанавливает, кто имеет право выполнять каждое из них. Роль — группа людей с общими функциями: «сотрудники стойки приёма», а не «Мария». Ролью может быть и внешняя система, которая работает с решением через интерфейс.

Руководство BABOK делит работу на четыре элемента:

Определение ролей: группы пользователей и внешние интерфейсы, которые воздействуют на решение.
Определение действий: функции, транзакции или операции с данными, которые нужно контролировать.
Определение полномочий: какая роль может выполнять какое действие.
Уточнения: две частые настройки. Делегирование позволяет роли временно передать полномочие кому-то другому, например на время отпуска. Наследование даёт одной роли все права другой — например, управляющему, который может делать всё, что могут сотрудники стойки приёма.

Вигерс и Битти рассматривают такую же таблицу как компактный способ записать один вид бизнес-правил — ограничения, по которым операцию могут выполнять только определённые роли. Вместо десятков предложений вида «возврат денег могут одобрять только руководители» вы отмечаете разрешённые ячейки в одной таблице.

Когда применять#

Применяйте технику, когда:

у решения несколько групп пользователей с разными правами, особенно если данные нужно защищать;
бизнесу нужны сдержки и противовесы: разделение обязанностей, лимиты на утверждение или журналы аудита, где видно, у кого какие были полномочия;
вы описываете, как обязанности распределены между пользователями и внешними интерфейсами (задача BABOK 7.1 «Спецификация и моделирование требований»);
вы оцениваете ограничения предприятия и нужно увидеть, какие права у каких заинтересованных сторон есть сегодня (задача 8.4 «Оценка ограничений предприятия»);
вы настраиваете готовый продукт. Вигерс и Битти используют матрицу ролей и прав как исходные данные для настройки доступа в коробочном ПО.

Выберите другую технику, когда:

нужно понять, кто отвечает за задачи проекта, например кто пишет, утверждает или рассматривает требования. Это матрица RACI, она описана в технике «Реестр, карта или персоны заинтересованных сторон»;
действия ещё неизвестны. Сначала смоделируйте границы, процессы или варианты использования: матрица из расплывчатых действий скрывает пробелы;
доступ зависит от сложных условий (сумма, время, тип клиента). Запишите их как бизнес-правила и сошлитесь на них.

Как это делать#

Зафиксируйте границу. Решите, какое решение или модуль охватывает матрица. Одна матрица на область остаётся читаемой.
Перечислите роли. Возьмите их из реестра заинтересованных сторон и организационной модели. Для каждой напишите определение в одну строку. Добавьте внешние системы, задания по расписанию и анонимных посетителей, если они есть.
Перечислите действия. Выведите их из вариантов использования, пользовательских историй или функциональной декомпозиции. Формулируйте каждое как глагол плюс объект («Утвердить заказ запчастей»). Держите один уровень детализации во всей матрице.
Согласуйте условные обозначения. Например: Д = разрешено, С = только свои записи, У = утверждает, пусто = запрещено. По умолчанию действует «запрещено», чтобы каждое разрешение было осознанным решением.
Заполните ячейки вместе с владельцами правил: владельцами процессов, линейными руководителями и теми, кто отвечает за безопасность и соответствие нормативным требованиям.
Добавьте уточнения. Запишите наследование между ролями и правила делегирования: кто может делегировать, кому, на какой срок и фиксируется ли это в журнале.
Проверьте разделение обязанностей. Ищите роли, которые могут и создать, и утвердить один и тот же объект или изменить данные и при этом править их журнал аудита.
Свяжите каждое ограничение с его причиной (бизнес-правилом, политикой или нормативным требованием), чтобы причина не потерялась при смене сотрудников.
Проведите ревью и зафиксируйте базовую версию, затем выведите тест-кейсы: для каждой ключевой ячейки — тест на разрешённый и тест на запрещённый доступ.

Пример#

«Мастерская», вымышленная сеть из 12 веломастерских, добавляет онлайн-запись, уведомления о статусе ремонта и заказ запчастей. Бизнес-аналитик составляет черновик матрицы для новой системы:

Действие	Клиент	Стойка приёма	Механик	Управляющий мастерской	Владелец	Поставщик запчастей (система)
Забронировать время на ремонт	С	Д		Д
Перенести или отменить бронь	С	Д		Д
Обновить статус ремонта			Д	Д
Создать заказ запчастей			Д	Д
Утвердить заказ запчастей сверх лимита				У	У
Подтвердить дату поставки запчастей						Д
Смотреть отчёт о выручке (своя мастерская)				Д	Д
Смотреть отчёт о выручке (все мастерские)					Д
Управлять учётными записями сотрудников				Д	Д

Уточнения: управляющий мастерской наследует все права стойки приёма. Управляющий может на фиксированный срок делегировать утверждение заказов запчастей конкретному старшему механику, и система записывает в журнал каждое утверждение, сделанное по делегированию.

Ревью показало, что в старом бумажном процессе механики могли и создавать, и утверждать крупные заказы запчастей. Владелец оставил утверждение за управляющими и записал причину как бизнес-правило.

Частые ошибки#

Имена или должности вместо ролей → определяйте роли по тому, что люди делают; один человек может совмещать несколько ролей.
Слишком глубоко слишком рано → Руководство BABOK предупреждает, что избыточная детализация замедляет построение матрицы. Начните с уровня функций; до уровня полей спускайтесь только для чувствительных данных.
Слишком высокий уровень → широкие действия скрывают роли и обязанности. Сверьте с матрицей каждый шаг вариантов использования.
Пустые ячейки без определённого смысла → опубликуйте условные обозначения и явно укажите, что «пусто = запрещено».
Забыты роли, за которыми не стоят люди → включите интерфейсы, пакетные задания и интеграции; часто именно у них самые широкие права.
Временный доступ без правил → определите делегирование, срок действия и то, что происходит, когда человек меняет должность или уходит.
Путаница с RACI → эта матрица регулирует использование решения, а RACI — работу над проектом.

Шаблон#

Шаблон

Область: <решение / модуль>    Версия: <n>    Владелец: <роль>
Обозначения: Д = разрешено | С = только свои записи | У = утверждает | пусто = запрещено

| Действие (глагол + объект) | <Роль 1> | <Роль 2> | <Роль 3> | <Внешняя система> | Правило / причина |
|---|---|---|---|---|---|
| <действие> |  |  |  |  | <ID правила или политика> |

Наследование: <Роль X> наследует все права <Роли Y>
Делегирование: <кто> может делегировать <действие> <кому>, на срок до <макс. срок>, запись в журнал: да/нет
Проверки разделения обязанностей: <роль> не может одновременно <действие 1> и <действие 2>

Чек-лист#

У каждой роли есть определение в одну строку, и это не имя человека.
Внешние системы и задания по расписанию перечислены как роли.
Условные обозначения опубликованы, и пустая ячейка означает «запрещено».
Правила наследования и делегирования записаны.
Ни одна роль не может и создавать, и утверждать один и тот же объект без задокументированной причины.
Каждое ограничение ссылается на бизнес-правило или политику.
Тест-кейсы покрывают разрешённый и запрещённый доступ для ключевых ячеек.

Источники и что почитать#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Рус. изд.: Руководство к своду знаний по бизнес-анализу (Руководство BABOK®), версия 3.0. Техника 10.39 «Матрица ролей и прав».
Watermark Learning. BABOK v3 Study Tables. 2016 (учебное пособие к Руководству BABOK). Техника 10.39.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 9 (бизнес-правила) и гл. 22 (коробочные решения).