STRUCTURING

SYSTEM PROCESS
REQUIREMENTS

Use Case
Modeling
COMSCI 2201
Functional vs. Non-functional
Functional

Requirements
Non-Functional

 Functional requirement are user ‘visible’ features and are

typically initiated by stakeholders of the system – generate
report, login, etc.
 Non-functional requirements are ‘non-visible’ features, but
required for effective running of an application – security,
backup, etc.
CLSU_ITDept_MIAMilagroso
What is a Use Case?

 A requirements analysis concept.

 A case of a use of the system/product.
 Tells a story:
– A sequence of events involving interactions of
user with the system
 Specifies one aspect of the behavior of a system,
without specifying the structure of the system.

CLSU_ITDept_MIAMilagroso
 Ways of Describing Use Cases
1. Text Description 2. Diagram Description
Use Case Diagram
 It is a simple way of presenting an overview of a system’s
requirements.
 A diagram that shows the relationships among actors and
use cases within a system.
 It is often used to:
– Provide an overview of all part of the usage requirements for
a system or organization in the form of an essential model or a
business model.
– Communicate the scope of a development project.
– Model your analysis of your usage requirements in the form of
a system use case model. CLSU_ITDept_MIAMilagroso
Use Case Model
 It is comprised of one or more use case diagrams
and any supporting documentation such as use case
specifications and actor definitions.
 It should be developed from the point of view of your
project stakeholders and not from the (often
technical) point of view of developers.

CLSU_ITDept_MIAMilagroso
 NOTATIONS
A description of a set of sequences of actions,
use case
including variants, that system performs that
yields an observable value to an actor.

The people or systems that provide or receive

actor
information from the system; they are among
the stakeholders of a system.

connection Connection between actor and use case

Specifies that the source use case explicitly

include <<include>>
incorporates the behavior of another use case
at a location specified by the source

extend Specifies that the target use case extends the <<extend>>
behavior of the source.
Actors

A person, organization, or external system that plays a

role in one or more interactions with your system.
 Actor must be a beneficiary of the use case.
 Typically drawn as stick figures.
 In naming actors, choose names that describe the
role, not generic names, such as "user" or "client".
CLSU_ITDept_MIAMilagroso
Actors (cont…)
Divided into two groups:

 Primary actors:
– Supply data or receive information from the system.
– Provide details on what the use case should do.
 Supporting actors:
– Help to keep the system running or provide help.
– The people who run the help desk, the analysts,
programmers, and so on.
CLSU_ITDept_MIAMilagroso
Actors (cont…)

• Could be human beings, other systems,

timers and clocks or hardware devices.

• Actors that stimulate the system and are the

initiators of events are called primary actors
(active)
• Actors that only receive stimuli from the system
are called secondary/supporting actors (passive)
CLSU_ITDept_MIAMilagroso
Actors (cont…)

Who/what will be interested in the

system?
Who/what will want to change the
Actors data in the system?
Who/what will want to interface with
the system?
Who/what will want the information
from the system?
CLSU_ITDept_MIAMilagroso
Rules for Actors
1. Place your Primary Actor(s) in the top-left corner of the
diagram
2. Draw Actors to the outside of a use case diagram
3. Name Actors with singular, business-relevant nouns
4. Associate each Actor with one or more use cases
5. Actors model roles, not positions
6. Use <<system>> to indicate System Actors
7. Actors don’t interact with one another.
CLSU_ITDept_MIAMilagroso
Use Case
Do
something

 It describes a sequence of actions that provide a

measureable value to an actor.
 System function (process – automated or manual).
 Each actor must be linked to a use case, while some
use cases may not be linked to actors.
 It is drawn as a horizontal ellipse.

CLSU_ITDept_MIAMilagroso
For identifying use cases, Jacobson et al.
(1992) recommend that you ask the
following questions:
 What are the main tasks performed by each actor?
 Will the actor read or update any information in the
system?
 Will the actor have to inform the system about
changes outside the system?
 Does the actor have to be informed of unexpected
changes?

CLSU_ITDept_MIAMilagroso
Use Case (Examples)
USER/ACTOR USER GOAL = USE CASE

• Look up item availability

Order Clerk • Create new order
• Update order
• Record order fulfillment
Shipping Clerk • Record back order

Merchandising • Create special promotion

Manager • Produce catalog activity report

CLSU_ITDept_MIAMilagroso
Rules for Use Cases
1. Use Case names begin with a strong Verb
2. Name Use Cases using domain terminology
3. Place your Primary Use Cases in the top-left corner
of the diagram
4. Imply timing considerations by stacking Use Cases.

CLSU_ITDept_MIAMilagroso
Use Case (Examples)

CLSU_ITDept_MIAMilagroso
Relationships
 There are several types of relationships that may appear on a use
case diagram:
– An association between an actor and a use case
– An association between two use cases
– A generalization between two actors
– A generalization between two use cases
 Associations are depicted as lines connecting two modeling
elements with an optional open-headed arrowhead on one end
of the line indicating the direction of the initial invocation of the
relationship.
 Generalizations are depicted as a close-headed arrowhead with
the arrow pointing towards the more general modeling element.
Relationships (Example)

CLSU_ITDept_MIAMilagroso
<<extend>> vs. <<include>>
 Extend relationship
– An association between two use cases where one adds new behaviors
or actions to the other.
– It is shown as a dotted-line arrow pointing toward the use case that has
been extended and labeled with the <<extend>> symbol.
<<extend>> vs. <<include>>
 Include relationship
– An association between two use cases where one use case
uses the functionality contained in the other.
– The included use case cannot stand alone and the original
use case is not complete without the included one.
– An include relationship is shown diagrammatically as a
dotted-line arrow pointed toward the use case that is being
used.
– The line is labeled with the <<include>> symbol.
<<include>> Example
Rules for Relationships
1. Indicate an association between an actor and a use case if
the actor appears within the use case logic
2. Avoid arrowheads on actor-use case relationships (if
necessary)
3. Apply <<include>> when you know exactly when to invoke
the use case
4. Apply <<extend>> when a use case may be invoked across
several use case steps
5. Generalize use cases when a single condition results in
significantly new business logic
6. Avoid more than two levels of use case associations.
CLSU_ITDept_MIAMilagroso
System Boundaries Boxes
 The rectangle around the use cases is called the system
boundary box.
 It indicates the scope of your system – the use cases inside
the rectangle represent the functionality that you intend to
implement.
Rules for System Boundaries

1. Indicate Release Scope with a System Boundary Box.

– Each of which has label indicating which release the
various use cases have been assigned to.
2. Avoid meaningless system boundary boxes.

CLSU_ITDept_MIAMilagroso
Use Case Diagram
– Guidelines & Caution
1. Use cases should ideally begin with a verb – i.e Generate
report.
2. Use cases should NOT be open ended – i.e Register (instead
should be named as Register New User)
3. Avoid showing communication between actors.
4. Actors should be named as singular. i.e Student and NOT
Students. NO names should be used – i.e John, Sam, etc.
5. Do NOT show behavior in a use case diagram; instead,
depict only system functionality.
6. Use case diagram does not show sequence – unlike DFDs.
CLSU_ITDept_MIAMilagroso
More example…

Suppose we want to develop software for an alarm clock.

The clock shows the time of day. Using buttons, the user can set the
hours and minutes fields individually, and choose between 12 and 24-
hour display. It is possible to set one or two alarms. When an alarm fires,
it will sound some noise. The user can turn it off, or choose to ’snooze’. If
the user does not respond at all, the alarm will turn off itself after 2
minutes. ’Snoozing’ means to turn off the sound, but the alarm will fire
again after some minutes of delay. This ’snoozing time’ is pre-adjustable.

Identify the top-level functional requirement for the clock, and model it
with a use case diagram.
Solution
Use Case Quiz will be conducted on our
face-to-face class meeting…

CLSU_ITDept_MIAMilagroso