I need help to realize what is the best way to design some Actors and Use cases on my subsystem.
This subsystem is about manage multiple accounts for users, administrators and a superuser with the next 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 best way to design these use cases to avoid redundacy on use case descriptions and make unnecessary use cases?
Are there any rules to inherit use cases to actors and apply some conditions on the use case description so the behavior of the use case will change according to the actor? (I'm looking for rules or syntax and examples if it is posibble)
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.
Then, for CRUD operations, I want achieve the same but I have other problem in addition which is if I should separate every operation or not since their goal are the same but their behavior also changes between actors (for create a user just ask for email auth while for create an admin ask for email & phone auth).
This is what the title's question try to achieve:
The final design needs to be CRUD use cases and login use cases (total=5), with their own descriptions each one, who only connect to User, and Admin and SuperUser inherit from User. Maybe some additional uses cases for authentications with "extend" or "include" relationships
Thanks in advance!
Aucun commentaire:
Enregistrer un commentaire