Scribd
Upload
23 views

Slide 4 - Requirements Using Use Case Diagrams

Uploaded by

Nathanel Rupondo
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
23 views

Slide 4 - Requirements Using Use Case Diagrams

Uploaded by

Nathanel Rupondo
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 21

USE CASE DIAGRAMS

Ever had a brilliant project


idea? The idea making a lot
of sense to you but you are
failing to put it across to
another person?
Or that person is simply
failing to understand it?

A Use case diagram can assist in


clarifying the high level operations
of a system without finer details of
how the system will be
implemented.
WHAT IS A USE CASE DIAGRAM?

It is the primary form of


system requirements for
a new software program to
be developed.
It specifies the expected
behaviour (what), and not
the exact method of making
it happen (how).
It helps us design a system
from an end user's
perspective.
• A use case diagram is usually simple.
• It summarizes some of the
relationships between use cases,
actors, and systems.
• It does not show the order in
which steps are performed to
achieve the goals of each use case.
PURPOSE OF USE CASE DIAGRAM

• Use case diagrams are typically


developed in early stage of
development.
• Often applied for the following
purposes:
• To specify the context of a
system
• To capture the requirements of
a system
NOTATION AND VISUAL REPRESENTATION

• Actor
• Anything that interacts with the system.
• Can be a user (different types of users), or
another system.
• A system can have two types of actors,
primary and secondary actors.
• Primary actor can initiate use cases. E.g.
user requests for authentication.
• Secondary actors are more of reactionary
actors. E.g. user receives notification.
• Each actor must be linked to at least one
NOTATION AND VISUAL REPRESENTATION

Use Case

• This is the functionality provided by the


system.
• Some use cases may be linked to an
actor,
• While some may not be linked to
NOTATION AND VISUAL REPRESENTATION

Communication link

• The participation of an actor in a use


case is shown by connecting an actor
to a use case by a solid link.
NOTATION AND VISUAL REPRESENTATION
Boundary of • The system boundary is the
system entire system as defined in
the requirements document.
• For large and complex systems,
each module may be the
system boundary.
• E.g, in an ERP system for an
organization, each of the
modules such as personnel,
payroll, accounting, etc. can
form a system boundary for use
STRUCTURING USE CASE DIAGRAM WITH
RELATIONSHIPS

• A relationship between two use cases is


basically modeling the dependency
between the two use cases.
• Reduces the overall effort required in
developing a system. (by reuse of
existing use cases)
• One use case can be connected to
another use case by an include or
extend relationship
RELATIONSHIPS

Extend
• Represents an optional behaviour / use
case
• Base use case is complete on its own
• Extended use case is optional
• Arrow points to the base use case.
Examples of extend relationship

It is optional for a user It is also not mandatory


to get help while filling for a user to give
a form feedback while booking
a ticket.
The two child use cases (Get Help and
Feedback) are functionalities that the
system can provide to the user during
filling form and Ticket booking if the user
RELATIONSHIPS

Include
• Represents a mandatory behaviour / or
functionality that should be present in the
base use case
• Base use case is incomplete on its own,
so it has to include the functionality of
another use case which is usually
common to a number of other base use
cases.
Examples of include relationship

To place an order, the


system has to provide a
login functionality also
To transfer
funds, the
system will
have to
verify
sufficient
funds firstto
Similarly,
make a
payment, the
system will
have to verify
sufficient
RELATIONSHIPS.
Generalization
• a child use case inherits the behaviour of
the parent use case.
• The child may add or override the
behaviour of the parent.
Generalization is represented by a directed
arrow with a triangle arrowhead.

The tip of the arrow is connected to the


parent use case.
Example - Generalization Relationship

• The search use case is a parent/base use


case
• When a user wants to search, the system
will have to provide the option to either
Search by Call number or Search by
EXAMPLE: ATM USE CASE DIAGRAM

SOMEONE CAN
• MAKE A
WITHDRAWAL
• CHECK BALANCE
• RESET PIN
• CONDUCT
MAINTENANCE
WORK
EXAMPL Add/Modify/update
students details like
E2 name, address.

Add/Modify/Update
Subject information
semester wise

Include entry of marks and


assignment of credit points
for each paper
Provide way to enter
through user id &
password.

Print various reports

(i) According to course code


(ii) According to Enrollment
number/registration number
HOW TO IDENTIFY ACTOR
• Who uses the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Does anything happen automatically?
HOW TO IDENTIFY USE CASES?
• The following questions can be asked to identify use cases, once
your actors have been identified

• What functions will the actor want from the system?

• What actors will create, read, update or delete this information?

• Does the system need to notify an actor about changes in the


internal state?

• Are there any external events the system must know about?

• What actor inform the system of those events?


USE CASE DIAGRAM TIPS
• Always structure and organize the use case diagram from
the perspective of actors.
• Use case diagrams are based upon functionality and thus
should focus on the "what" and not the "how".

You might also like