on use case diagrams, but before we get started if you want more business analysis training and tips,
be sure to subscribe to the page and turn on the notification bell
with that said let's get started.
So let's talk about what you're going to learn today we're going to go over what is a use case,
the main components of a use case diagram, then we'll look at an example of how to navigate and
interpret a use case diagram, and then we'll look at some use case diagram best practices.
So what is a use case?
A use case is a functionality within a system that will allow the user
to achieve a goal. Now, a use case diagram is a visual representation of the relationships between
actors and key use cases within a solution. It also depicts the scope of that solution.
Now, the standard notation for the use case diagram
is a part of the unified modeling language.
The main components of a use case include the system boundary box, the system name,
actors, use cases, associations, relationships, and goals.
Now, let's look at each of these in more detail.
So the system boundary box represents the boundary of a system or solution it's presented as a large
rectangular box surrounding the use case. Any use case inside of the rectangle is considered
to be within scope and any use case outside of that rectangle is considered to be out of scope.
Then, we have the system name. The system name represents the name of the system or solution
being defined. It's located at the top center of the system boundary box.
Now, we have our actors. An actor is any person or system
that uses or interacts with the use case in order to achieve a goal.
Each actor is given a role to represent their interaction with the solution. Now the name of
human actors should always be in the form of a role and should not specify an actual name.
Also, actors must interact with at least one use case. Now actors can meet in the form of a human
or an external system. When they are in the form of a human they are represented with this little
stick figure here but when actors are external systems they're represented with smaller boxes.
Generally, there are two types of actors primary and secondary primary actors are
located on the left side of the system boundary box while secondary reactors
are located on the right side of the system boundary box.
The next component is the actual use cases a used case is the action taken by an actor
in order to complete or accomplish a task each use case should map to a functional requirement.
Now use cases are represented by a horizontal oval and you use case names to generally include a verb
that describes an action and a noun that describes an element that is being impacted by the use case.
Next, we have associations. Associations show the interaction between actors and the use cases. An
association line indicates the actor's ability to perform functionality within a use case. One
thing to note is that only primary actors can initiate use cases secondary actors can only
react to a use case. Generally, there will only be association lines between actors
and base use cases not with any sub-use cases. Now association lines are solid and do not have arrows
and that's because they don't represent system flow. They only represent interaction
next we have relationships now relationships are the connections between different use cases
such as extend, include, and generalize. It also refers to connections between actors.
Now the include relationship is any functionality that is shared between one or more use case. The
include use cases is a required function and must be completed in order for the base to use case
to be successfully executed. Including relationships are represented with
dashed lines with an arrow pointing from the base use case toward the included use case.
An extended relationship can be any additional functionality to a base use case.
When used this way the extended use case can be optional and does not impact the execution of
the base use case. Extended use cases can also be an exception to a base use case.
Extended use cases are also represented with the dashed line
but these have arrows pointing toward the base use case from the extended use case.
Now the next relationship we have is generalization.
This is the relationship between two use cases when a child use case inherits the functionality
of the parent use case. The child use case is also more specialized
and includes specific functionality this is used when two or more use cases have common behavior.
In order to provide examples of these relationships, it's necessary to define
the term base use case. So the base use case is the main use case that has a particular goal. It
may use the functionality of another use case in an include relationship or it may utilize
optional or exception functionality in the extend relationship. A base use case can also
be the parent use case to one or more child use cases in a generalization relationship.
The generalization relationship can also
apply to actors where the child actors inherit the general functionality of a parent actor.
So for example you may have a general customer actor
and that role may be segmented into two different levels of authorization.
So the regular customer might inherit the general customer capabilities but they'll also have
maybe additional capabilities and privileges for maintaining their service.
The new customer on the other hand may have limited functionality or capabilities.
So while they are inheriting the general customer functionality
they may have deposit or withdrawal limitations for a short period of time.
Now let's look at goals. The goal is the end result of key use cases.
Various scenarios may occur within a use case but the goals are represented through the naming
convention of the use case in a verb-noun format. So, for example, complete is your verb and online
transaction is your noun so the goal here is to fully execute or complete the online transaction.
And a general rule when determining which use cases to use in a use case
diagram is to identify the requirements that enable the user to achieve a particular goal.
Now let's take a look at the use case diagram of a banking system.
So to start we're using the banking system to define the boundary of our solution. Then
we have our system name here at the top center of the system boundary box which is "banking system".
Next, we have our actors as you can see we have our primary actors on the left
and our secondary actress on the right.
Here we have our customer as a general actor and our new and regular actors as our child actors.
We also have our bank employee as our secondary actor
who may have some type of interaction with the online transactions and we also have our external
database that might also interact with the online transaction likely to pull or store data.
Then we have our use cases. Our base use cases are complete online transaction and complete
mobile transaction and we also have several sub-use cases. The online payments and online
transfers are two variations of the complete online transaction use case. Since this is
a generalization relationship they inherit the functionality and relationships of the complete
online transaction use case. Then we have our login use case which is an included relationship
to both the complete online transactions case and the complete mobile transaction use case.
This means that both of these use cases require the login functionality in order to
be successfully executed then we have our invalid login which is an exception to the login use case.
Notice we have several association lines between the actors and the base use cases.
And again we have our relationships. Here we have the include relationship, an extension
relationship, as well as a generalization relationship. We also have a generalization
between the actors, so now that you know the components
of a use case and how to interpret it, let's look at some best practices.
So first you want to be sure to keep the use case names short and simple. These diagrams are
intended to simplify complex information. Also, your use case names should include
a verb and a noun so use case naming should be action-oriented
verbs convey action which is why we have actors. Then be sure to model functionality from the user
perspective. The purpose is to illustrate how a user interacts with the solution.
Also, human actors should be notated as roles and not names.
In general, system functionality is role-based, not individual-based.
Then be sure to position actors and use cases logically. While use cases
don't show flow or sequence, having the use cases logically placed can make it easier to interpret.
Also, only model key functionality that enables user goals. Not all features or
requirements will need to be illustrated in the use cases diagram. Only those that have
clear goals or relationships with those use cases. And finally, do not try to model detailed flows or
sequence. This type of detail is better suited for flow diagrams or sequence diagrams.
Well, there you have it folks that's what you need to know in order to create
clear and simple use case diagrams.
if you learned something new tell me about it in the comments. I'd love to hear your feedback!
Also, be sure to check out all the business analysis and ba certification
training we have for you at theba.com that's t-h-e-b-a-d-o-c. com
Thank you so much for watching be sure to have a productive and prosperous day
and I'll see you next time! Bye now!