The users who will be using the system will have different roles (which will be granted when the user is created). Based on this role assigned he will be given access to different parts of application or different functionality of application.
This access details for various roles should be mentioned further in your requirement. If it is not mentioned pl. ask the BA but don't start working with any assumption.
Also if you don't understand the requirement pl. confirm your understanding with BA without going any further.
e.g. of Test Case:
User having one particular role should not have access to the part of application which is meant for other role etc..
Adding to what Denis said, many times by roles they mean permission groups, so a group may not necessarily mean to have wider or shorter permissions but to have permissions over different areas of the system.
Based on previous bugs I've seen on this area I would suggest a couple of scenarios/paths I would think to test around this:
(1)what happens if a user is assigned to more than 1 group/role. With different permissions on different areas of the system; and (2) all the subject of customization of roles (if applicable).
I agree with Sanket, if in doubt, ask! Look at all the assumptions presented here already. You have a "Super User" already. You may not have one at all. It might be roles like Sales, Accounting, Inventory, etc.
goldyfish12345, I have found the easiest way to test role based functionality is to draw up a matrix (I use a spreadsheet). I usually put the functionality of the system down the first column, and list the roles across the top row. I then check off the role's access to the functionality in their related columns. This will give you a structured basis to test the roles have the correct access to functionality in the system, and at the same time, you can ensure that the role doesn't have access to parts of the system they shouldn't have. You can then set up your user accounts in the system based on this matrix to test against.
Depending on how your system's access model is set up - you will possibly need to consider inherited roles, or multiple roles, ensuring the user account can access all functionality in all associated roles.