Object-Oriented Analysis

and Design

Use Case

Use Cases
Use case an activity that the system
performs, usually in response to a request
by a user
Use cases define functional requirements
Analysts decompose the system into a set
of use cases (functional decomposition)
Two techniques for Identifying use cases

User goal technique

Event decomposition technique

Name each use case using Verb-Noun

Types of Diagrams
Structural

Diagrams focus on static

aspects of the software system

Class, Object

Behavioral

Diagrams focus on
dynamic aspects of the software
system

Use-case, Sequence, Interaction,

State Chart, Activity

Implementation

Diagrams focus on

Component, Deployment
3

User Goal Technique

Some RMO CSMS Users and Goals

User Goal Technique:

Specific Steps
1.
2.

3.

4.

Identify all the potential users for the new

system
Classify the potential users in terms of their
functional role (e.g., shipping, marketing,
sales)
Further classify potential users by
organizational level (e.g., operational,
management, executive)
For each type of user, interview them to
find a list of specific goals they will have
when using the new system (current goals
5
and innovative functions to add value)

User Goal Technique

Specific Steps (continued)
5.
6.
7.
8.

Create a list of preliminary use cases

organized by type of user
Look for duplicates with similar use case
names and resolve inconsistencies
Identify where different types of users
need the same use cases
Review the completed list with each type
of user and then with interested
stakeholders

Event Decomposition Technique

More Comprehensive and Complete
Technique

Identify the events that occur to which the

system must respond.
For each event, name a use case (verb-noun)
that describes what the system does when the
event occurs

Event something that occurs at a specific

time and place, can be described, and
should be remembered by the system
7

Events and Use Cases

Types of Events
External Event

an event that occurs outside the

system, usually initiated by an external
agent or actor

Temporal Event

an event that occurs as a result of

reaching a point in time

State Event

an event that occurs when something

happens inside the system that triggers
some process
reorder point is reached for inventory

External Event Checklist

External agent or actor wants something
resulting in a transaction

Customer buys a product

External agent or actor wants some

information

Customer wants to know product details

External data changed and needs to be

updated

Customer has new address and phone

Management wants some information

Sales manager wants update on production plans

10

Temporal Event Checklist

Internal outputs needed at points in
time

Management reports (summary or

exception)
Operational reports (detailed
transactions)
Internal statements and documents
(including payroll)

External outputs needed at points of

time

Statements, status reports, bills,

11

Finding the actual event that

affects the system

12

Tracing a sequence of transactions

resulting in many events

13

Perfect Technology Assumption

Dont worry about functions built into system because

of limits in technology and people. Wait until design.

14

Event Decomposition Technique:

Specific Steps
Consider the external events in the system
environment that require a response from the
system by using the checklist shown in Figure
3-3
2. For each external event, identify and name
the use case that the system requires
3. Consider the temporal events that require a
response from the system by using the
checklist shown in Figure 3-4
4. For each temporal event, identify and name
the use case that the system requires and
then establish the point of time that will
trigger the use case
1.

15

Event Decomposition Technique:

Specific Steps (continued)
Consider the state events that the system
might respond to, particularly if it is a realtime system in which devices or internal state
changes trigger use cases.
6. For each state event, identify and name the
use case that the system requires and then
define the state change.
7. When events and use cases are defined,
check to see if they are required by using the
perfect technology assumption. Do not
include events that involve such system
controls as login, logout, change password,
and backup or restore the database, as these
are put in later.
5.

16

Use Cases and

Brief Use Case Descriptions

Brief use case description is often a one

sentence description showing the main steps in a
use case

17

Use Case Diagrams

Use case diagram a UML model used to graphically

show uses cases and their relationships to actors
Recall UML is Unified Modeling Language, the
standard for diagrams and terminology for developing
information systems
Actor is the UML name for a end user
Automation boundary the boundary between the
computerized portion of the application and the users
who operate the application

18

Use Case Diagrams

Symbols

19

Use Case
Diagrams
Draw for
each
subsystem

20

Use Case
Diagrams
Draw for
actor, such
as customer

21

Use Case Diagrams

The <<Includes>> relationship

A relationship between use cases where one use case is
stereotypically included within the other use case like a
called subroutine. Arrow points to subroutine

22

Use case specification

A use case specification is a document used to capture the specific details
of a use case. Use case specifications provide a way to capture the
functional requirements of a system.
Use case specifications provide a means of organizing all of the different
scenarios that exist. They add detail beyond what is shown in a use case
diagram. They are a useful tool in communicating with project
stakeholders, system users, business analysts, and developers. These
specifications define requirements in a way that all consumers of the
project can understand, creating a common vocabulary for the impacted
parties.
While the structure of a use case model helps drive architectural
decisions, the specific scenarios outlined in a use case specification serve
to verify whether early architectural assumptions are correct. Properly
written use case specifications help identify and design objects, system
components, and their responsibilities. Use cases also drive the creation
of an efficient user interface design. They also help organize the
development process. Quality assurance teams test functional
requirements based on the content of a use case specification, and this
document also assists with defining benchmarks for performance testing.
Finally, use case specifications help with the creation of user guides,

Use case specification

Use Case Identification and History
Use Case ID:PROJ.UC.1.1.1 <Assign a unique name to each use case>
Use Case Name:<Name concise results oriented-name Version No:
with an action verb and a noun. >
Created by:

On (date):

Last Update by:

On (date):

User/Actor:<Description of the person who uses the system to accomplish

tasks>
Business Owner Name:

Contact
Details:

Trigger:<Who (system or user) triggers this use case>

Precondition<What is true of the system state before this flow of actions
begins>
Basic Flow <The optimal or normal ("good day") flow of events. The basic flow of events should describe
the events that walk through a successful scenario. The basic flow should not include and/if scenarios>
Step

User Actions
1<Phrase saying what user does>

System Actions
<Description of system response>

2<Repeated as needed>

<Repeat>

Use case specification

Alternate Flow <may be more than one>
Step
User Actions
1
<Phrase saying what user does, identify prior basic step # where
alternative flow begins and subsequent basic step # where basic
flow continues (if it does) after performing alternate flow>

System Actions
<Description of alternative flow
step(s) (number each distinct
step)>

Exception Flow <identify system and data error conditions that could occur for each step in the normal and alternate flow>
1

<Phrase saying what data or system error condition occurred.

Identify prior basic or alternative step # where basic/alternative
flow begins and subsequent basic/ alternative step # where basic/
alternative flow continues (if it does) after performing exception
flow >

<Description of system response

to return back to the next step in
the flow or state if the condition
results in termination of the flow
and what the final state of the
system is at this point (i.e.
redisplay first screen before error
condition or something else.)
(Number each distinct step). >

<Example: The VIN is invalid.

(Basic Flow, Step 2)>

Post conditions
1.
<What is true of the system when the flow of activities finishes>
Includes or Extension Points
1.
<Common functionality that appears in multiple use cases can be split out into separate use cases. Provide reference to
such of the use cases that are called by the subject use case. >

Use case specification

Terimakasih

Introduction to Systems Analysis and Design:

An Agile, Iteractive Approach
6th Ed
Satzinger, Jackson & Burd