2. Outline
Introduction
What is Use Case
Why We Use UseCase
Reading Use Case Diagram
Components Of Use Case
Relationship Of Use Case
How To Create Use case Diagram
Benefits Of Use Case
2
4. What is UseCase
• A formal way of representing how a
business system interacts with its
environment
• Illustrates the activities that are
performed by the users of the
system
• A scenario-based technique in the
UML
4
5. A Use Case description will generally
includes:
○ General comments and notes describing the use
case.
○ Requirements
○ Scenarios
○ Constraints
5
6. Why We Use UseCase
In a traditional Software Requirements
Specification (SRS), features are presented
without context. For example:
The system shall log credit payments to the
accounts receivable system.
The lack of context makes room for
ambiguity.
○ When does this event happen?
○ Is the order relative to other events
significant?
○ Who triggers the event?
○ What happens when the accounts
receivable system is unavailable?
6
7. Where to Use a Use Case Diagram?
Use case diagrams specify the events of a
system and their flows. But use case
diagram never describes how they are
implemented.
Use case diagram can be imagined as a
black box where only the input, output, and
the function of the black box is known
7
8. Reading Use Case Diagram
Starting with the actor check-in employee
(1) you can find associations between the
two use cases check-in (2) and express
check-in (3). This means that persons who
interact with the IT system as check-in
employees can carry out the use cases
check-in and express check-in.
8
14. System Boundaries
A box that sets a system scope to use
cases. All use cases outside the box would
be considered outside the scope of that
system
14
17. RelationShips
Use cases share different kinds of
relationships. A relationship between two
use cases is basically a dependency
between the two use cases.
Use case relationships can be one of the
following:
○ Association
○ Include
○ Extend
○ Generalizations
17
19. Include Relationship
○ When a use case is depicted as using
the functionality of another use case in
a diagram, this relationship between the
use cases is named as
an include relationship.
○ Literally speaking, in
an include relationship, a use case
includes the functionality described in
another use case as a part of its
process
19
20. Include Relationship
For example,:
you can see that the functionality defined
by the "Validate patient records" use case is
contained within the "Make appointment"
use case. Hence, whenever the "Make
appointment" use case executes, the
business steps defined in the "Validate
patient records" use case are also
executed.
20
21. Extend Relationship
○ In an extend relationship between two
use cases, the child use case adds to
the existing functionality and
characteristics of the parent use case.
○ An extend relationship is depicted with a
directed arrow having a dotted shaft,
similar to the include relationship.
○ The tip of the arrowhead points to the
parent use case and the child use case
is connected at the base of the arrow
21
22. Extend Relationship
An extend relationship between the
"Perform medical tests" (parent) and
"Perform Pathological Tests" (child) use
cases. The "Perform Pathological Tests" use
case enhances the functionality of the
"Perform medical tests" use case. Essentially,
the "Perform Pathological Tests" use case is
a specialized version of the generic
"Perform medical tests" use case.
22
25. Creating Use Case
○ List main system functions (use cases) in a
column: – think of business events demanding
system’s response – users’ goals/needs to be
accomplished via the system – Create, Read,
Update, Delete (CRUD) data tasks – Naming use
cases – user’s needs usually can be translated
in data tasks
○ Draw ovals around the function labels
○ Draw system boundary
○ Draw actors and connect them with use cases
(if more intuitive, this can be done as step 2)
○ Specify include and extend relationships
between use cases (yes, at the end - not
before, as this may pull you into process
thinking, which does not apply in UC
diagramming).
25
27. Advantages
○ Very simple to draw and understand
which makes it good choice for analyst
to use it during requirements gathering.
○ A system can be viewed as whole with
all of its use cases and actors/users how
are initiating and having involvement in
a particular use case.
○ As there is no technicality involved in
drawing or reading Use case diagram it
benefits all stakeholder to understand
the system.
27
28. Disadvantages
○ They do not capture the non-functional
requirements easily.
○ There might be a learning curve for the
developer and/or specially, the client in
using these use cases.
28
30. Summary
○ Uses case describe example system
behaviors (contracts) from the user’s
point of view.
○ Easy To Implement
○ Easy To Read the systems
○ 4 steps to create use cases.
30