Добрый день!

Вопрос касается области управления доступом (access control, rbac)

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

Например, если через Модель Предметной Области можно управлять изменениями предметной области, которые должны быть учтены в системе, то в области упраления доступом существуют модели (диаграммы, отчеты, схемы) через которые разработчик может управлять изменениями в правилах доступа?

Могу по другому сформулировать вопрос.
Наш проект начинался с небольшого набора функционала для которого достаточно было 5-6 ролей.
С течением времени проект разрастался и новый функционал требовал более тонкой настройки прав доступа.
У команды, на данный момент, нет опыта работы с такими методологиями, как, например, Role engineering (top-down, bottom-up, Hybrid), как описано в статье https://blogs.oracle.com/OracleIDM/entry/enterprise_role_definition_best_practices

Какие бы вы дали советы команде

• с чего начать (к каким материалам стоит обратиться),
• понять нужен или не нужен нам Role engineering

чтобы в конце-концов выстроить грамотный процесс проектирования и поддержки подсистемы управления доступом?

Я думаю, что можно начать отсюда:
https://en.wikipedia.org/wiki/Role-based_access_control
Хотя, наверное вы уже это прочитали...

Вообще, нужно идти ИМХО на форумы по ERP системам, и там искать ответ - как это устроено у них, н-р, в 1С, МС и САП. Здесь вряд ли кто-то даст ответ...

Я думаю, что можно начать отсюда:
https://en.wikipedia.org/wiki/Role-based_access_control
Хотя, наверное вы уже это прочитали...

Вообще, нужно идти ИМХО на форумы по ERP системам, и там искать ответ - как это устроено у них, н-р, в 1С, МС и САП. Здесь вряд ли кто-то даст ответ...

Спасибо за ответ, bas!
Почему я здесь вопрос задал?
Я думал про оформление бизнес требований некоторой фичи F в виде, скажем, User Story (из scum), или просто текстом.
И одним из пунктов я предполагал будет "Правила доступа". Ведь это тоже часть бизнес-логики фичи F.
Именно на данном шаге я задумался об оформлении этих требований.
Под сложностью описания требований я понимаю не столько перечисление ролей, которые могут иметь доступ к операции над объектом, сколько описание ограничений (особенно динамических)

• только мои пациенты
• пациенты в моей организации
• доступ по вертикальной иерархии подчинения
• доступ по территориальному признаку (федеральный, региональный, местный)
• и т.п.

Если, скажем, написать, что правила доступа фичи F, такие же, как у фичи N, то эта формулировка пораждает ряд вопросов:

• какие правила у фичи N?
• действительно ли правила повторяются?
• может быть, тут можно выполнить объединение правил?

Т.е. я подвожу к вопросу, должен ли системный аналитик формально описывать правила доступа, максимально полно, как, к примеру, матрицу (или другую форму представления правил)?
Для того, чтобы программисту только осталось внести изменения в код.

В итоге, если это действительно верно - полностью расписывать в требованиях правила доступа к фичи F - получается, что на этапе проектирования фичи F нужно выполнить некоторое подобие аудита правил доступа, т.е. некоторый процесс "пересмотра" существующих правил доступа, но уже с учетом новой фичи F.
Именно поэтому я вышел на процесс role engineering, правда, пока не смог определится с тем, поможет он в данном вопросе или нет

Если мой ход рассуждения неверен, Вы тоже, пожалуйста, скажите об этом.

Попробую спросить на форумах erp систем.
Еще раз сасибо за подсказку!

Я писал варианты такого документа. А еще посмотрите http://www.trackstudio.ru/ В системе очень неплохо реализована возможность настройки прав доступа. На сайте есть несколько статей и пример ТЗ на настройку.

Я писал варианты такого документа. А еще посмотрите http://www.trackstudio.ru/ В системе очень неплохо реализована возможность настройки прав доступа. На сайте есть несколько статей и пример ТЗ на настройку.

SALar, а Вы могли бы раскрыть состав и структуру этого документа? Я правильно понял, что у вас была форма документа, разработанная полностью внутри вашего проекта/компании?
Пример ТЗ, о котором вы говорили, не могу найти

С сайта трекстудии

SALar, огромное спасибо!
Думаю, именно такой документ я  и искал. По крайней мере его можно брать за основу для развития своего решения: матрица + немного текстового описания + диаграммы.
Плюс появилось желание регламентировать состав и структуру ТЗ для бизнес функций - сейчас у нас описание требований происходит в произвольной форме: тоже есть картинки, диаграммы, текстовое описание, но они не так структурированы, и не всегда можно уследить за их полнотой.

SALar, а вы не подскажете, что за нотация использовалась для диаграмм из Приложения?