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.