Use Case Model Guideline – Best Tips & Guidance For 2024

Actor’s will be used to model the humans, other systems and hardware devices that interact with the System. Each actor should have a name that represents the role of the actor and is understood by the audience of the use-case model.

For each actor, a brief description of the actor’s responsibilities with respect to the system will be recorded. With a complex, multi-dimensional organisation, it is also important to capture the type/part of the organisation that the actor belongs to.

Where possible the description should also include the number of users represented by this actor, the location of the actors and the frequency with which the actor will interact with the system. In addition to being described on the various use-case diagrams, the actors should also appear on a separate diagram(s) documenting the actors and any relationships that exist between the actors.

Distinguishing between Actors and Security Roles

Be aware of clouding the activity of identifying Actors with being caught up in the Access Permissions of those Actors.  Many systems handle access permissions through the creation of User Profiles and the allocation of individuals to those profiles.  The result of this is that a group of users who have a particular Role, represented by one Actor in the Use Case Model, may have different permissions when it comes to the ability to initiate a Use Case or to perform particular steps or flows within a Use Case. 

Take an Actor called Bank Teller, and a Use Case called Transfer Money.  Janet is a Bank Teller and is associated with a User Profile that has minimal access to the system.  Amanda on the other hand, has access to most functionality of the system.  John has a level of access somewhere between Janet and Amanda.  

When Janet tries to initiate this Use Case she will get an error message informing her that she does not have access to perform a Transfer of Money.  When John accesses the system, he is able to perform a transfer, but he gets an error if he tries to transfer a sum greater than £5,000.  Amanda on the other hand will not receive any errors with respect to her security permissions to transfer money.

The tendency here may be to create three Actors, for example, Bank Teller minimal access, Bank Teller medium access, Bank Teller high access.  This should not be done, stick with one Actor and handle the different security permissions within the flow of events or business rules of the Use Case.

The overuse of ‘Super User’ and ‘Any User’ Actors

In contrast to the above example of creating a proliferation of Actors representing differing levels of access permission, be aware of the overuse of ‘generalised’ actors within your Use Case Model.

A Use Case Model with ‘Super User’ or ‘Any User’ Actors with a relationship to a high percentage of the Use Cases may indicate that the Project Team have not spent enough time understanding the roles in the organisation that will get value out of using the system.  If this is the case, there should be a serious concern over whether the system when deployed into the user community is going to meet the users needs. 

This is not to deter people from using generalised Actors to create a simplified view of the Use Case Model, as long as the analysis has occurred on who the real Actors are.  In addition, the ‘Use Case perspective’ view of the Use Case diagram that appears in the Use Case Specification should represent the true Actors associated with the Use Case rather than the generalised Actor.