Roles and Permissions Matrix · Business Analysis Notes

What it is#

In the BABOK® Guide, this technique identifies the roles involved in a solution’s activities and sets out who is authorized to perform each one. A role is a group of people who share common functions: “front-desk staff”, not “Maria”. A role can also be an external system that works with the solution through an interface.

The BABOK Guide breaks the work into four elements:

Identify roles: the user groups and external interfaces that act on the solution.
Identify activities: the functions, transactions, or data operations you want to control.
Identify authorities: which role may perform which activity.
Refinements: two common adjustments. Delegation lets a role temporarily pass an authority to someone else, for example during a holiday. Inheritance gives one role all the permissions of another, for example a manager who can do everything front-desk staff can do.

Wiegers and Beatty treat the same grid as a compact way to record one kind of business rule: constraints that say only certain roles may perform an operation. Instead of dozens of sentences like “only managers may approve refunds”, you mark the permitted cells in one grid.

When to use it#

Use it when:

the solution has several user groups with different rights, especially where data must be protected;
the business needs checks and balances: segregation of duties, approval limits, or audit trails that record who held which authority;
you specify how duties are split between users and external interfaces (BABOK task Specify and Model Requirements, 7.1);
you assess enterprise limitations and need to see which stakeholders hold which rights today (Assess Enterprise Limitations, 8.4);
you configure a packaged product. Wiegers and Beatty use a roles-and-permissions matrix as an input for setting up access in off-the-shelf software.

Use something else when:

you want to know who is responsible for project tasks, such as who writes, approves, or reviews the requirements. That is a RACI matrix, covered under Stakeholder List, Map, or Personas.
the activities are not known yet. Model the scope, processes, or use cases first; a matrix of vague activities hides gaps.
access depends on complex conditions (amount, time, customer type). Put those in business rules and reference them.

How to do it#

Fix the boundary. Decide which solution or module the matrix covers. One matrix per area stays readable.
List the roles. Take them from the stakeholder list and the organizational model. Write a one-line definition for each. Add external systems, scheduled jobs, and anonymous visitors if they exist.
List the activities. Derive them from use cases, user stories, or a functional decomposition. Phrase each as verb plus object (“Approve parts order”). Keep one level of detail across the whole matrix.
Agree a legend. For example: Y = allowed, O = own records only, A = approve, blank = not allowed. Default to “not allowed”, so every permission is a conscious decision.
Fill the cells with the people who own the rules: process owners, line managers, and whoever is responsible for security or compliance.
Add refinements. Record inheritance between roles and the delegation rules: who may delegate, to whom, for how long, and whether it is logged.
Check segregation of duties. Look for any role that can both create and approve the same item, or change data and also edit its audit trail.
Link each restriction to its reason (a business rule, policy, or regulation) so the reason survives staff changes.
Review and baseline, then derive test cases: an allowed and a denied test for each key cell.

Example#

The Workshop, a fictional chain of 12 bike-repair workshops, is adding online booking, repair-status notifications, and parts ordering. The business analyst drafts this matrix for the new system:

Activity	Customer	Front desk	Mechanic	Workshop manager	Owner	Parts supplier (system)
Book a repair slot	O	Y		Y
Reschedule or cancel a booking	O	Y		Y
Update repair status			Y	Y
Create a parts order			Y	Y
Approve a parts order above the limit				A	A
Confirm parts delivery date						Y
View revenue report (own workshop)				Y	Y
View revenue report (all workshops)					Y
Manage staff accounts				Y	Y

Refinements: the workshop manager inherits all front-desk permissions. A manager may delegate parts-order approval to a named senior mechanic for a fixed period, and the system logs every approval made under delegation.

The review exposed that, in the old paper process, mechanics could both create and approve large parts orders. The owner kept approval with managers and recorded the reason as a business rule.

Common mistakes#

Using names or job titles instead of roles → define roles by what people do; one person can hold several roles.
Going too deep too early → the BABOK Guide warns that too much detail makes the matrix slow to build. Start at function level; go to field level only for sensitive data.
Staying too high → broad activities hide roles and responsibilities. Check every use case step against the matrix.
Blank cells with no defined meaning → publish the legend and make “blank = not allowed” explicit.
Forgetting non-human roles → include interfaces, batch jobs, and integrations; they often hold the widest rights.
Ignoring temporary access → define delegation, expiry, and what happens when someone changes job or leaves.
Confusing it with RACI → this matrix governs use of the solution; RACI governs project work.

Template#

Template

Scope: <solution / module>    Version: <n>    Owner: <role>
Legend: Y = allowed | O = own records only | A = approve | blank = not allowed

| Activity (verb + object) | <Role 1> | <Role 2> | <Role 3> | <External system> | Rule / reason |
|---|---|---|---|---|---|
| <activity> |  |  |  |  | <rule ID or policy> |

Inheritance: <Role X> inherits all permissions of <Role Y>
Delegation: <who> may delegate <activity> to <whom>, for <max period>, logged: yes/no
Segregation-of-duties checks: <role> cannot both <action 1> and <action 2>

Checklist#

Every role has a one-line definition and is not a person’s name.
External systems and scheduled jobs are listed as roles.
The legend is published, and blank means “not allowed”.
Inheritance and delegation rules are written down.
No role can both create and approve the same item without a documented reason.
Each restriction points to a business rule or policy.
Test cases cover allowed and denied access for key cells.

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.39 “Roles and Permissions Matrix”.
Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide), technique 10.39.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 9 (business rules) and ch. 22 (packaged solutions).