UML: How to reduce use cases for user accounts system to avoid redundancy and unnecessary use cases?

Question

I need help to reduce the use cases on my subsystem.

This subsystem is about manage multiple accounts for users, administrators and a superuser with the following requirements:

The system shall manage users accounts, where there are:

• Users: can create, read, update, delete and block their own accounts, also login.

  Create needs email authentication. Login should ask for 2-step auth (optional)

• Admins: can manage all users accounts (CRUD, block and login) as a user. Also read only and login their own account.

  Login needs 2 step authentication.

• Superuser: can manage both users and admin accounts (CRUD, block, logins) and their own superuser account.

  Create admin needs email & phone auth.
  Login is same as admins, needs 2 step auth.
  Can delegate the superuser access to another admin.

The system's flow need to be clear just with use case diagram and use case descriptions (without other type of diagram)

What is the right way to design these use cases to avoid redundacy on use case descriptions and make unnecessary use cases on diagram?

For example, on this system, the user, admin, and superuser have a Login Use Case each one. User Login ask for 2 step auth (optional) while on admin and superuser the 2 step auth must be always required.

SuperUser inherits from Admin who inherits from User.

The final goal I am looking for is to make (for instance) these 3 login uses cases into one that connects to the User Actor only so Admin and SuperUser inherit the use case but, due to the behavior is different for every Actor, I want to put one Login Use Case Description which changes the behavior according to the Actor type who triggers the Login. So instead of have 3 Login Use Cases (one for each actor), I have just 1 use case and 1 description that works for all.

Answer 1

What you seem to look for is the parametrised use-cases, which is a concept promoted by Alistair Cockburn for textual use-cases.

The typical example is CRUD when the same use-case description is used over and over again with a slight variant for each operation. The approach is the to have a parametrised use case where the parameter is the operation (create, read, update, delete).

The same concept doesn't exist in UML notation as far as I know. So you would typically have either a use case Manage XYZ and describe the details in the narratives, or the four use-cases Create XYZ , Update XYZ , Delete XYZ , Read XYZ . Personally I prefer the first, so that the use-case convey the big picture.

Instead of multiplying the same use-cases for the different actors, you could also use less use-cases and use contraints to explain in plain text the special rules that apply to the different categories of actors for the different use-cases.

Finally, I'd like to add that use-cases are not meant to model flows and sequence of events. Use cases are meant to identify different goals that would translate to different kind of interactions. In this regard I wonder if it could make sense to distinguish Manage own account and Manage other user account since this correspond to very different goals.