Lessons learnt from many business analysis engagements and projects have helped conclude some useful use case model guidelines. Having guidelines on a project and an organisation (as a whole) is helpful to ensure that teams and business analysis provide use case models and documenting use cases that are understandable for others to read.
This article describes the information to be captured, and the permitted notational relationships within the use-case model, and will help you to incorporate guidelines that you can use on your projects. Some readers may be interested in a recommended use case training course
.
The use case model is one of the artefacts in the unified modelling language (UML) that a business analyst can used and has been popular when doing use case analysis and use case specifications and documenting use cases.
Table of Contents
Use Case Model Guidelines Actors
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.
Use Case Modelling Guidelines – Use Cases
Use Cases will be used to describe the Actor goal being achieved through performing that Use Case. Use Cases contain functional requirements of the System as well as any non-functional requirements specific to that Use Case. Each use case should have a name that indicates what is achieved by its invocation.
The name you choose can make understanding the Use Case easier or more difficult. An active Use Case name such as ‘Enter an Order’ is a better choice than a passive name such as ‘Order Entry’. Active names imply that something gets done, passive names tend to sound more like functions.
The standard guidance is that a Use Case should be named in the format verb noun (e.g. Transfer Business, Place Order, Merge Agents), however, this name may need to consist of several words to be understood (e.g. Submit Additional Loan Information). No two Use Cases can have the same name. Once the use case has become stable, the name should be prefixed by a unique number of the format UC99.
Each Use Case must include a brief description that describes the purpose of the Use Case and the value produced for its Actors. Reading the brief description should enable the reader to understand the scope of the use case. Generally, a single paragraph will suffice for the brief description.
“Communicates” Relationship
The “communicates” relationship between an actor and a use case will be used to show the actors that interact with the use case. The following rules are to be considered when using the “communicates” relationship:
if an actor initiates the use case, the “communicates” relationship should flow from the actor to the use case (the arrow should point towards the use case)
if an actor receives an output from a use case, the “communicates” relationship should flow from the use case to the actor (the arrow should point towards the actor)
if an actor is ‘involved’ with (but does not initiate) a use case, the “communicates” relationship should not have a direction (a line should be displayed instead of an arrow)
if the ‘communicates’ relationship is between the Use Case and an actor representing an external system, the communicates relationship should be named to reflect the nature of the interface (e.g. for the ‘Place Order’ Use Case for an online shop there may be an interface to an inventory management system to get the current stock position for an item in the Order, in this scenario, a communicates relationship should be created between the Use Case and the actor named ‘Get Current Stock Position’)
“Include” Relationship
The “include” relationship will be used between Use Cases to extract processing from a Use Case. This may be done either because processing which is common to another Use Case has been found or because the Use Case has become too large to understand easily or an existing Use Case which can be initiated in it’s own right forms part of another Use Case. The “include” relationship will flow from the main Use Case to the included Use Case and be labelled with a stereotype of “include”.
NOTE: Within the flow of events, the main Use Case will explicitly “invoke” the included Use Case.
“Extend” Relationship
The use of the “extend” relationship regularly causes confusion due to the many different definitions of how it is to be used. It has therefore been inconsistently used within projects to date. Also, the Analysis & Design discipline does not treat this relationship any differently than the “includes” relationship when designing a Use Case.
Therefore, this relationship will not be used within Use Case Models produced. The “include” relationship will be used to model that a relationship exists between 2 Use Cases and the “including” use case will specify any conditional logic regarding how the use case is included.
“Generalises” Relationship
The “generalises” relationship between use cases will NOT be used. This is due to the complexity it adds to the use-case model.
However, the “generalises” relationship will be used between Actors if it results in a use-case diagram that is simpler and easier to understand. The “generalises” relationship simplifies the model by replacing a number of specific actors by a more general actor that captures the commonalities between the specific actors.
NOTE: when using the generic actor, validate that it would be correct to replace the generic actor with ALL of the specific actors that the generic actor represents.
Use Case Training
If you wish to learn further with use cases – Business Analyst Mentor has a list of recommended use case training courses.
Use Case Template
Here is a free Use Case Template from Bridging the Gap
