Role, Privilege

A privilege is a low-level user authority to do or see something in the system, which grants the ability to perform specific actions. A role is a collection of privileges presenting a convenient way to group privileges into a bundle that can be later assigned to the users. For example, a user with the Compliance Officer role is granted the privilege to View Payment Alert, Edit Payment Alert, and Resolve Payment Alert, yet he is not granted the privilege to Delete Alert. If the system is expected to restrict functions to particular users, it must implement the concept of roles/privileges. Selected system functions then can be linked to a specific privilege, so it is possible to state that "The button is enabled if the logged-in user has a 'Delete contact' privilege".

Since each privilege is associated with a particular system function, the list of system privileges is known when the system is deployed, and privileges cannot be modified on the fly. Roles, on the other hand, are usually created by administrators after the system is deployed. Roles enable them to assign privileges to users in batch - instead of assigning each user dozens of privileges, the administrator assigns a role containing all privileges. The evaluation mechanism then gets the user role, retrieves all its privileges, and compares them with the privilege required to perform the particular action. This also means that it does not make sense to document what a particular user role can do in the system, as it may change ad-hoc.

Actor, Role, Privilege

Very often, analysts are puzzled about the difference between the use case actor, system role, and underlying privileges. The confusion stems from the fact that actors and roles are very similar, they describe the same concept, very often overlap, yet they are not the same. The actor is somebody who performs the use case. Since use cases themselves are not directly implemented in the system, the actor remains just a virtual analytical entity. But in realization, developers implement screens, functions, buttons, etc. and need to know who exactly can display the screen, execute the function or click on the button. They need to know the privileges.

As you can see, the actor Order Processing Clerk can perform Process Order use case. But use cases do not include every action the user can do with the application, because it is not their goal. So, for example, setting a manual discount is not even mentioned in the use case. Use cases do not map 1:1 to system functions, neither the actors map to the roles. The Order Processing Clerk actor performs the Process Order use case, however, in the real application, the use case is broken down to individual functions, each requiring specific privilege, as depicted in the picture.

Antipatterns

Mixing System Privileges With Use Case Actors

As stated above, use case actors and privileges serve different purposes, each lying at a different level of abstraction. The use case scenario should not be controlled by low-level system privileges. Similarly, system specification aiming to provide concrete implementation instructions for development, should not work with abstract use case actors:

• Incorrect use case step: "User fills in the form and submits it. If the user has a privilege' PRIV12-No need to verify data', no checkings are done on the submitted data".
  • Use cases should not contain implementation details including low-level privileges
• Incorrect button behavior described in the system specification: "The button is enabled only if the user is member of the Legal Department"
  • If a developer is given such requirement, the instant question will come: "Which privilege does control whether the button is enabled or not?". Developers have no idea what the Legal department means.

Roles Hierarchy

Stakeholders sometimes state their requirements like this: "Branch Supervisor or any higher role can approve the request". A sharp analyst should immediately spot the ambiguity and ask for the concrete list of roles: "Branch Supervisor, Branch Manager, and Country Manager can approve the change". This is a correctly stated requirement that will most likely be implemented as a privilege Right to Approve Change, which will be assigned to roles Branch Supervisor, Branch Manager, and Country Manager.