Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  User Roles or Privileges screen for intranet application
Previous Previous
 
Next Next
New Post 3/6/2017 7:11 AM
Unresolved
User is offline IamModernAnalyst
1 posts
No Ranking


User Roles or Privileges screen for intranet application 

I am trying to details user stories on a 'User Role and Privileges' screen for an Intranet web application GUI part.

And its a mix and match of Few screens and their within functionality access.
The usual way is having a matrix like structure where we can list down screen names/Interfaces and then in the 2nd step user can choose between the function allowed for that role within the selected screen. 

Is there any GUI idea someone have come across, other than this traditional two step approach (an out of the box, of fancy GUI for Roles screen)? 

 

Thanks

 
New Post 10/14/2019 5:59 AM
User is offline dadi 01
2 posts
No Ranking


Re: User Roles or Privileges screen for intranet application 
 IamModernAnalyst wrote

I am trying to details user stories on a 'User Role and Privileges' screen for an Intranet web application GUI part.

And its a mix and match of Few screens and their within functionality access.
The usual way is having a matrix like structure where we can list down screen names/Interfaces and then in the 2nd step user can choose between the function allowed for that role within the selected screen. 

Is there any GUI idea someone have come across, other than this traditional two step approach (an out of the box, of fancy GUI for Roles screen)? 

 

Thanks


I am trying to details user stories on a 'User Role and Privileges' screen for an Intranet web application GUI part.

 

 

 
New Post 10/16/2019 1:03 AM
User is offline Stewart F
119 posts
7th Level Poster


Re: User Roles or Privileges screen for intranet application 

Hi Iam, 

So on the screen(s) I assume that someone with suitable access can edit those privileges? 

First of all, I want break this down into:

a. Who can see what

b. Who can do what

I would write both of these as a Feature. Then, taking the first one "Who can see what" describe who has the ability to enter the screens. Usually with a User Role/Privilege screen it isn't viewable to all, usually just those in a Support or Management role. 

Next, having defined who can see the screen, you need to ascertain what those people can do in it. Strangely, the one thing that people often forget is the privileges to see the privileges.

In terms of how the screen should look as a whole, there is no definitive answer to that. You are right that typically it is a matrix view that is the most common. However, ask yourself these questions:

1. How many Users are there that will have their permissions/privileges set on the screen? If there are less than 20, you can probably place them all on it, and have a number drown DDLs or radio buttons (DDL = Drop Down Lists) However, if there are a lot more Users, then I would suggest a parameter at the top of the screen whereby you select the User, then have a page below with all of the permissions/privileges placed into groups (So for example all permissions around the Internet in one group, all around what folders they can access in you system I another and so on). This approach makes it easier to find individual permissions if only one needs to be changed. Don't make the User Journey reliant on the User going through every single setting. 

2. Are all permissions set in one place - your screen(s)? If they aren't then ask why that is. If necessary provide a link to the other permission settings screens - although personally I would have them all set in one place. 

3. Do you have groups of Users that would allow Users to have their privileges set via a User Profile? So for example a User Profile called "Management" - anyone in that group has the same core permissions (these can be edited if required individually). It makes the User setting all of these privileges much easier (also the person who authorises them). 

4. Don't forget your authorisation process, Is that part of your screen processes or is it separate? If it is part of it, then you need to think of a way for the authoriser to do this remotely. Generally, the authoriser will be a manager of some sort. By default, they are busy and not always available when you want them to be, so put in place a process for them to authorise the permissions when THEY want to do it.

I often see on this forum BAs asking for "are there any 'out of the box' solutions". Bear in mind that no 'Out of the box' solution will just work for you. You will always need to do some tinkering with it - usually by the vendor themselves. This actually makes it slower than building it yourself and you are not guaranteed to get exactly what you want. Instead, you'll get what the Vendor wants - usually restricted to the number of Users you are setting permissions for. Added to that, you will also need to plug it into you core systems for it to work - that will also take time and a LOT of money. I would strongly advise against it.

Is there another method that isn't the two step process - no, not really. Not unless you want to add more steps! A privilege will always:

1. Need to define who it is for

2. State what they are being assigned

3. Authorisation for Point 2

4. Setting those privileges into 'production'. I.e. making them actually happen. 

If you have any other questions let me know.

 
New Post 10/18/2019 8:13 AM
User is offline dadi 01
2 posts
No Ranking


Re: User Roles or Privileges screen for intranet application 
Modified By Chris Adams  on 10/18/2019 1:48:20 PM)
 Stewart F wrote

Hi Iam, 

So on the screen(s) I assume that someone with suitable access can edit those privileges? 

First of all, I want break this down into:

a. Who can see what

b. Who can do what

I would write both of these as a Feature. Then, taking the first one "Who can see what" describe who has the ability to enter the screens. Usually with a User Role/Privilege screen it isn't viewable to all, usually just those in a Support or Management role. 

Next, having defined who can see the screen, you need to ascertain what those people can do in it. Strangely, the one thing that people often forget is the privileges to see the privileges.

In terms of how the screen should look as a whole, there is no definitive answer to that. You are right that typically it is a matrix view that is the most common. However, ask yourself these questions:

1. How many Users are there that will have their permissions/privileges set on the screen? If there are less than 20, you can probably place them all on it, and have a number drown DDLs or radio buttons (DDL = Drop Down Lists) However, if there are a lot more Users, then I would suggest a parameter at the top of the screen whereby you select the User, then have a page below with all of the permissions/privileges placed into groups (So for example all permissions around the Internet in one group, all around what folders they can access in you system I another and so on). This approach makes it easier to find individual permissions if only one needs to be changed. Don't make the User Journey reliant on the User going through every single setting. 

2. Are all permissions set in one place - your screen(s)? If they aren't then ask why that is. If necessary provide a link to the other permission settings screens - although personally I would have them all set in one place. 

3. Do you have groups of Users that would allow Users to have their privileges set via a User Profile? So for example a User Profile called "Management" - anyone in that group has the same core permissions (these can be edited if required individually). It makes the User setting all of these privileges much easier (also the person who authorises them). 

4. Don't forget your authorisation process, Is that part of your screen processes or is it separate? If it is part of it, then you need to think of a way for the authoriser to do this remotely. Generally, the authoriser will be a manager of some sort. By default, they are busy and not always available when you want them to be, so put in place a process for them to authorise the permissions when THEY want to do it.

I often see on this forum BAs asking for "are there any 'out of the box' solutions". Bear in mind that no 'Out of the box' solution will just work for you. You will always need to do some tinkering with it - usually by the vendor themselves. This actually makes it slower than building it yourself and you are not guaranteed to get exactly what you want. Instead, you'll get what the Vendor wants - usually restricted to the number of Users you are setting permissions for. Added to that, you will also need to plug it into you core systems for it to work - that will also take time and a LOT of money. I would strongly advise against it.

Is there another method that isn't the two step process - no, not really. Not unless you want to add more steps! A privilege will always:

1. Need to define who it is for

2. State what they are being assigned

3. Authorisation for Point 2

4. Setting those privileges into 'production'. I.e. making them actually happen. 

If you have any other questions let me know.

 

 

Is there any GUI idea someone have come across, other than this traditional two step approach (an out of the box, of fancy GUI for Roles screen)? 
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Agile Analysis ...  User Roles or Privileges screen for intranet application

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC