Is my use-case diagram and scenario correct?

Question

Good day to everyone, I'm learning UML and I need an advice concerning use-cases please. I'm designing a member manager system. Country admin can manage all (sub)organizations and users. I created also a customer admin so that customers are able to manage users of their (sub)organizations. Customer admin can't manage organizations and he can see only his own (sub)organization and it's users. I'v drawn this use-case diagram:

And I'v written the scenario this way:

--- BEGIN ---
Use-case name: Set Up Organization Tree
Description: Allow country admins or customer admins to set up the organization
  structure. Country admins can see or update all members of their country. Customer
  admins can see or update members of their own organization only. 
Actors:
  - Primary actor - Country admin
  - Secondary actor – Customer admin

Basic-flow: Set up an organization structure in the country root
  1) Log in
  2) View organization tree
  3) Create a new organization
  4) Create a new user within the organization
  5) Set the password of the user
  6) 2 to 5 may repeat
  7) Log out

Alternate fow: Set up user accounts within the existing organization
  1) Log in
  2) View organization tree
  3) Create a new user within the selected organization
  4) Set the password of the user
  5) 2 to 5 may repeat
  6) Log out
--- END ---

I'm not sure whether it is correct. Organizations can be created in the basic flow so it describes what the country admin can do. In the alternate flow users only can be created so it describes what both - the country admin and customer admin - can do. But the fact that customer admin can see his own organization only is not visible here. Also I'm not sure whether I can describe it all in single use-case alternate flows or whether I should create two separate use-cases. One for the country admin and one for the customer admin. If I created separate use-case diagram for country admin I think I shoudl not mention customer admin there and then I also should not draw customer admin actor and the actor generalization? Many thanks in advance.

Vojtech

EDIT 1:

Here's updated version:

And updated scenatio:

--- BEGIN ---
Use-case name: Create New Customer Organizational Structure
Description: Allow country admin to create new organizational structure of the customer including users. Allow customer admins to create new users within the existing organizational structure. The country admin can see or update all members of the country. The customer admin can see or update users of his/her own organization only.

Actors:
- Country admin
- Customer admin


Basic-flow: Country admin creates new customer organizational structure

Pre-conditions:
- The country admin is logged in
- The customer organizational hierarchy doesn't exists in the Member Manager

Flow of events: Create New customer Organizational Structure 
1) The country admin views the organization tree
2) The country admin creates a new organization
3) The country admin creates a new user within the organization
4) The country admin sets the password of the user
5) 1 to 4 may repeat

Post-condition:
- Customer organizational hierarchy is created
- Customer users are created
- Each user has a password


Alternate fow: Country admin creates new user in the existing organizational structure

Pre-conditions:
- The country admin is logged in
- The country admin can see or edit all members of the country
- The customer organizational hierarchy exists in the Member Manager
- The user that is going to be created doesn't exist

Flow of events:
1) The country admin views organization tree
2) The country admin creates a new user within the selected organization
2) The country admin sets the password of the user
4) 1 to 3 may repeat

Post-condition:
- New users are created in the selected organization
- Each user has a password


Alternate fow: Customer admin creates new user in the existing organizational structure

Pre-conditions:
- The customer admin is logged in
- The customer admin can see or edit members of his own organization only
- The customer organizational hierarchy exists in the Member Manager
- The user that is going to be created doesn't exist

Flow of events;
1) The customer admin views organization tree
2) The customer admin creates a new user within the selected organization
2) The customer admin sets the password of the user
4) 1 to 3 may repeat

Post-condition:
- New users are created in the selected organization
- Each user has a password

--- END ---

There are two alternate flws in my scenario now:

- Alternate fow: Country admin creates new user in the existing organizational structure
- Alternate fow: Customer admin creates new user in the existing organizational structure

Is it necessary to mention them both? They are the same as the country admin is specialization of the customer admin. Also I mentioned that the customer admin can see members of his own organization only whereas the country admin can see all members of the country in the scenario description, pre-conditions and diagram note. Is it the way how it should be?

Thank you. Vojtech

Answer 1

Your diagram looks good. Your model reader can conclude that both actors have the same UCs and CountryAdmin one additional. Special rules and restrictions (like that the Customer admin can only see his own organization should be separatelly specified).

Regarding the flows, they have several errors that should be fixed. I assume that you've mistaken in the UC title (in the description the title is "Set Up Organization Tree" and on the diagram "Creatr Organization"). Even if it's not the case, the most of the errors are general:

1. It seems that you extended UC scenarios too much over the limits of the UC. Most of the steps correspond to other UCs! You should not have "login", "logout" and other similar actions in every UC, that's why they are defined separatelly. So, you should only concentrate on the atomic action of the UC itself.
2. Description of the UC does not fit the scenarios at all! In the scenario you create new users, and the title is "set up the organization". This is unclear. UC title should clearly mark it's aim and this should be achieved through a successfull scenario.
3. It should be clearly indicated under what conditions will each flow be invoked.

I suggest you to fix this problems and post the new version of the scenarios. Then we can fine tune them further.

UPDATE (after the 1st rework):

Your UCs must be refined themselves first, so the scenario writing will come natural. You missed some UCs now and others are too big.

• login and logout must be there as separate use cases. Login has the postcondition "user is logged in". You used the corresponding precondition correctly!
• preconditions/postcondition apply to a UC as a whole, not to individual flows, as further explained in the following concrete points.
• I would break the main flow in 2 UCs: first 2 steps correspond to a UC "Create new organization", while the steps 3-4 could give a UC "Create user". The step 5 is not necessary
• The alternative flows maps entirely on "Create User", you should just refine the preconditions a bit. They are always common, but you can split in 2 flows, depending on the user
• I would refine the preconditions/postconditions. You should keep the low count of them, as they merely indicate if the UC can start. All other rules should be moved inside the concrete scenarios. For example "Each user has a password" is kind of obvious/too detailed, it is enough to say that the user was created. "The user that is going to be created doesn't exist" - this does not make sense, as cannot be evaluated in that moment. :)

Try to see UCs more concrete and closed. They should have a single and simple goal. Alternative flows should show different ways to achieve the goal and should not make different things. All flows have the same preconditiona and all should have the same postconditions (except the ones with errors of course). Use rules inside the UC scenarios to define the alternative flows (e.g. main scenario is for "customer admin" and the alt. flow is for "country admin".

I would suggest you to rework the model once more and post it back. :)