UML Use Case Diagram – Used from a Business Analyst’s Perspective
The word ‘use case’ is so often just thrown into a business conversation without necessarily having a sound understanding of its meaning. So what does ‘use case’ really refer to?
A use case in the context of Business Analysis is the complete picture of how a user will be use a particular piece of functionality for a new or change system. It is a description of the steps a user will take to perform a function (and what the system will perform to execute that function), it describes the success scenario when these steps are followed and it also describes the exception scenarios when steps are not followed in the correct sequence. The use case will sketch the situation in the form of pre-conditions that must be true before the use case is performed, it will also describe purpose of performing the use case. In a nutshell, it is a detailed description of what the system is expected to do when a user uses the system in a particular way.
So if we then take the next step and ask: What is a UML Use Case Diagram? The answer to this question is that it is a visual representation of the key functions that a system can perform showing the use cases, the actors, the system and the interactions between these components.
Let’s use an example to describe a UML use case diagram here.
The basic components of the UML Use Case Diagram
System: The rectangle box depicts the system boundary. This box must be labelled with the system name.
Use Case: Each UML Use Case on the diagram must be shown as an oval shape. Each UML Use Case only describes one piece of functionality. You must use specific terminology and an active verb in your description.
Actors: Using a stick figure you must identify the different types of users of the system. For each user type you must have stick figure on the outside of the rectangle border.
Associations: Each Actor will be interacting with the system via certain UML Use Cases as represented on your diagram. This depends on the actor’s role.
Relationships between Use Cases – Stereotypes: There are also relationships that exist between some use cases. Take note that at least one of the use cases which have a relationship with another use case will not have a direct association with an actor. This is because at least one the use cases are a pure system use case (examples: validation function/use case, calculation of some sort). Watch the YouTube video for a clear explanation of this difference.
Two types of stereotypes/relationships:
- <<Uses>> or <<Includes>>: This relationship type means that a use case (that is also interacting with the actor) will always call this use case to complete the function it is performing. Note the term <<uses>> are now replaced by UML with <<includes>>.
- <<Extends>>: This relationship type means that the use case (that is also interacting with the actor) will only when certain conditions are met, use the other use case which it has a relationship with.
UML Use Case Diagram – watch this short video to see how to practically apply this as a Business Analyst
How should a Business Analyst use a UML Use Case Diagram?
The original intent of the UML Use Case Diagram is that of a more system design level modelling tool (I recommend Creately.com) to help developers understand the actual system design to follow when building a solution. In the context of a more business focussed use of the UML Use Case Diagram we would like to highlight that as a Business Analyst it is much more important for you to demonstrate the key functional areas required with the appropriate actor interactions using the UML Use Case Diagram than what it is to get each use case technically right for the audience of the software development side of things.
The UML Use Case Diagram is a very handy Business Analysis technique to use with the business to demonstrate the scope of functionality and clarify that it is sound and correct than what it is to get every technical detail correct from the start. There are many technical system analysts and solution designers who can assist you to get your UML Use Case Diagram technically correct at a later stage of the project life cycle if this is important for the more technical phases of the project. Getting the original functional requirements right using the UML Use Case Diagram with the business is more important from the Business Analysts point of view than having it technically sound.
What if I have more than 9 use cases to demonstrate on my UML Use Case Diagram?
You simply create more than one UML Use Case Diagram by grouping UML Use Cases into logical groups and displaying that way. You can even consider doing a high level functional UML Use Case Diagram which is then supported with a next level of UML Use Case Diagram s to ensure you include all the key UML Use Cases on your diagram.
