Modeling User Roles

I noticed an interesting question on the UML forum which I think a lot of people are struggling with, therefore I took the effort to put it on my blog.

The problem was the following:
- You have a set of use cases and a large set of roles.
- The stakeholders are not only interested in the use cases as such, but they also want to see which role has which responsibility. In other words : Who can do what?

You could take up the minimum authorisation level in the preconditions of the different use cases, but this has as a drawback that you don't have any comprehensive overview.

So use cases are not sufficient. People with a requirements background tend to propose solutions which imply that you start introducing an actor per role and build huge inheritance trees of actors. You can see this illustrated in the following figure:

The drawback of this however is that this quickly becomes a whole mess if you have a huge number of roles.

Instead of trying to model everything using a use case diagram, the solution is to use a class diagram.
The idea I like to introduce is based on RBAC (Role Based Access Control). This is a simplified view :

Roles are made up of operations, which group functions.

The solution is to draw an object diagram (using a UML class diagram) and to create 'Function' objects that have a name that links to the UC (e.g. a function "Withdraw money " to refer to the "Withdraw money" use case).
If you feel that your use case names are not stable enough, then add a prefix (e.g. UC1) to uniquely identify the use case.

Next, you can create 'Role' objects that are referring (using an association relationship) to those functions. One such a role object can be "administrator" for example.

In case you have too many functions, group them into 'operations' and instead of drawing an object diagram with roles and functions, draw a object diagram with roles and operations.

Depending on the level of detail of the uses cases you'll either choose to refer to functions (level of detail : low) or operations (level of detail : high).

If you're afraid to create a spider web of relations between roles & functions (or operations), you can use different diagram instances where you model 3 roles per diagram for example (to make sure it's very readable and understandable).

When properly layed out, such diagrams can also be presented to your stakeholders. Roles and functions are a language they can understand.
This is a very simple example of such a diagram:

This is the most elegant solution, based on UML class diagrams and RBAC. It's not a good idea to model this using use case diagrams. UML has different diagrams, and nowhere it is written that you should be restrained to using use case diagrams when modeling requirements.