This technique involves the specification of actions that are allowed to be taken by actors in different, defined roles in an organization. While these can and should be defined in general use, as a practical matter this most often comes up in the design of software systems, where roles and permissions can be rigorously defined and enforced.
I analyzed operations in dental offices on two separate occasions. Five roles were defined: dentist, hygienist, assistant, helper, and administrator. The industry is governed by formal regulations that define what dental operations dentists, hygienists, and assistants can (with increasing limitations) perform. Helpers cannot perform any type of work on patients, but they can support and prepare spaces, supplies, and equipment for the other workers. Administrators handle paperwork, billing, communication, ordering, and scheduling for the office. The activities and permissions for each role could be expressed in the form of the matrix shown below, though the example in the figure is for a more generalized engineering operation.
The things that must be defined are:
- Roles: These are categories to which packages of permissions can be defined. Individuals or users are assigned roles.
- Activities: These define the specific activities that may be performed by personnel in each role.
- Authorities (Permissions): These show who can do what.
The roles and activities define a two-dimensional matrix, while the permissions show the ability of the permission for each combination. In many computer systems, the permissions are enforced based on the roles assigned to each user when they log in.
These permissions can take many forms. File systems often define roles for what kinds of users can manipulate files in different ways. More involved IT systems may define an almost infinite variety of roles and operations. Considering the figure above, we see a number of roles (and families of roles), and operations. This example is notional. Many operations can be defined for many different classes of operations. It you can think of it, you can define and implement it. The key, as always, is to ensure the designers, maintainers, and users of a system clearly understand how the system is to be defined and used.