The Role of Business Analysts in Roles & Permissions Mapping
/Mapping of Roles and Permissions is a key task in any software development project that should be planned as part of system implementation. BAs should not wait until the project is almost over before performing the role mapping exercise, which should ideally, be done in collaboration with key stakeholders. The Audit team and system analysts who understand how the system functions for example, should also be involved in this exercise.
Lapses and security issues that arise as a result of granting permissions to the wrong person can become a source of embarrassment to the business. The level of access each system user needs to have should therefore, be carefully defined and tested upfront.
If the roles and permissions mapping exercise is not properly done, the project may well be at stake. The Roles and Permission Matrix technique can be applied by a business analyst (in collaboration with key stakeholders) to ensure that users are mapped correctly to the right level of access or permissions that they should have. Defining this type of matrix is particularly useful in:
- Identifying the key roles within the organization
- Discovering additional roles that require access to the system
- Discovering roles that should not have access to certain system functions and
- Denoting who can perform which activities/tasks within the organization
A role can be defined as a classification of a group of people who have common functions. It can be linked to a collection of permissions, and a person inherits those permissions when he is assigned that role. In some cases, individuals with the same job titles may have different roles.
Quick tips for business analysts involved in role mapping:
- Work in collaboration with stakeholders who understand the system and how access rights are configured.
- Review existing inventories of roles within the business. Sources of organizational roles include job descriptions, discussions with stakeholders, user guides and manuals, system-defined roles (pre-configured roles which are defined out of the box e.g. ERP software)
- Review existing process models, RACI matrix, use cases, CRUD matrix, and functional decomposition models to identify all the roles and the level of access each person should have.
Here’s a simple example:
Have you got additional tips on roles and permissions mapping?
Picture Attribution: “Zero One Background Shows Internet Connecting And Network ” by Stuart Miles/Freedigitalphotos.net
User story maps are an interesting and collaborative way of eliciting user requirements. One of the reasons why I find it so powerful is because it provides a unique approach for aligning discussions relating to the user, their goals, the process that supports the accomplishment of their predefined goals; and the requirements that need to be addressed to solve business problems.