Use case diagram 

Use case diagram is a diagram that describes the functional requirements of the system. It models the the external users of the system (actors) and the way the systems is used (use cases) – an actor of a system is not necessary a human being, it could be just another system.

The requirements of a software system describe what the user expects from the system – in
other words, what the system will do for the user. When modeling a system both functional and nonfunctional requirements need to be considered. 

In the use case modeling approach, functional requirements are described in terms
of actors, which are users of the system, and use cases. A use case defines a sequence
of interactions between one or more actors and the system. The system is treated
as a black box – that is, dealing with what the system does in response to the actor’s
inputs, not the internals of how it does it. 

A use case always starts with input from an actor. A use case typically consists
of a sequence of interactions between the actor and the system.

Use case actors 

An actor represents a role played in the application domain, typically by a human
user. A user is an individual, whereas an actor represents the role played by all users
of the same type. 

Primary and Secondary Actors 

A primary actor initiates a use case. Thus, the use case starts with an input from
the primary actor to which the system has to respond. Other actors, referred to as
secondary actors, can participate in the use case 


To determine the use cases in the system, it is useful to start by considering the actors
and the interactions they have with the system. Each use case describes a sequence of interactions between the actor and the system.  


Each use case in the use case model is documented in a use case description, as

  • Use case name: Each use case is given a name.
  • Summary: A brief description of the use case, typically one or two sentences.
    Dependency: This optional section describes whether the use case depends
    on other use cases – that is, whether it includes or extends another use
  • Actors: This section names the actors in the use case. There is always a primary
    actor that initiates the use case. In addition, there may be secondary
    actors that also participate in the use case. For example in the Withdraw
    Funds use case, the ATM Customer is the only actor.
  • Preconditions: One or more conditions that must be true at the start of use
    case, from the perspective of this use case; for example, the ATM machine
    is idle, displaying a “Welcome” message.
  • Description of main sequence: The bulk of the use case is a narrative
    description of the main sequence of the use case, which is the most usual
    sequence of interactions between the actor and the system. The description
    is in the form of the input from the actor, followed by the response of the
  • Description of alternative sequences: Narrative description of alternative
    branches off the main sequence. There may be several alternative branches
    from the main sequence. For example, if the customer’s account has insufficient
    funds, display apology and eject card. The step in the use case at which
    the alternative sequence branches off from the main sequence is identified
    as well as a description of the alternative.
  • Nonfunctional requirements: Narrative description of nonfunctional
    requirements, such as performance and security requirements.
    Postcondition: Condition that is always true at the end of the use case (from
    the perspective of this use case) if the main sequence has been followed; for
    example, customer’s funds have been withdrawn.
  • Outstanding questions: During development, questions about the use case
    are documented for discussions with users. 

Use case relationships

When use cases get too complex, dependencies between use cases can be defined
by using the include and extend relationships. 

Inclusion use case :

a common sequence of interactions can
be extracted from several of the original use cases and made into a new use case,
which is called an inclusion use case. 


In certain situations, a use case can get very complex, with many alternative
branches. The extend relationship is used to model alternative paths that a use
case might take. A use case can become too complex if it has too many alternative,
optional, and exceptional sequences of interactions. A solution to this problem
is to split off an alternative or optional sequence of interactions into a separate use
case. The purpose of this new use case is to extend the old use case, if the appropriate
condition holds. The use case that is extended is referred to as the base use case,
and the use case that does the extending is referred to as the extension use case.

Use case diagram ELEMENTS 

An oval shape used to depict a use case in use case diagram
A man shape used to depict an actor in use case diagram
A straight line used to depict an association 
dashed arrow line used to depict extension  in use case diagram
dashed arrow used to depict inclusion in use case diagram

Use case diagram modeling example. 

Now we will try to model, our well know WordPress CMS. 

The model will be very simple it will include only 3 users and a couple of use cases. 




Leave a comment

Your email address will not be published. Required fields are marked *