TOPIC 5-

FUNCTIONAL
MODELING
Bachelor of Information Systems (Hons.) Information Systems
Engineering
(CS266)

Anis Afiqah Sharip

UiTM Cawangan Melaka Kampus Jasin
CONTENT

• Explain the user stories

• Explain why identifying use cases is the key to defining functional requirements
• Describe the two techniques for identifying use cases
• Apply the user goal technique to identify use cases
• Apply the event decomposition technique to identify use cases
• Apply the CRUD technique to validate and refine the list of use cases
• Describe the notation and purpose for the use case diagram
• Draw use case diagrams by actor and by subsystem

2
USER STORIES
USER STORIES

• A user story is usually one short sentence in the everyday language of the end
user that states what a user does as part of his or her work. In other words, a user
story describes a goal the user has when using the system.

• User stories are a basic concept in Agile development because they focus on
simplicity, value added, and user collaboration. They document the functional
requirements quickly and less formally than traditional requirements modelling by
focusing on who, what, and why for each function. The users and stakeholders are
responsible for identifying the user stories.

4
 As a <role played>, I want to
THE STANDARD TEMPLATE
<goal/desire> so that <reason or
benefit>

5
USER STORY – EXAMPLES
Some user stories for a bank teller might be:
• “As a teller, I want to make a deposit to quickly serve more
customers.”
• “As a teller, I want to balance the cash drawer to assure there were
no errors.”

As a customer of the bank using an ATM machine, some user stories

might be:
• “As a bank customer, I want to withdraw cash and feel confident the
stack of cash I get is the correct amount.”
• “As a bank customer, I want to deposit a check and feel confident the
deposit is recorded correctly.”

6
USER STORY – ACCEPTANCE CRITERIA
• Features that must be present for the user to be satisfied with the resulting
implementation
• Focus on functionality, not on features or user-interface design.
• The programmer analyst uses the acceptance criteria to clarify the expectations
of the user and to verify the user is looking at the user story at an appropriate
level of analysis.
• When the user story is implemented and refined, the acceptance criteria are used
for testing.

7
USER STORY – EXAMPLES OF
ACCEPTANCE CRITERIA

8
USER STORY – EXAMPLES OF
ACCEPTANCE CRITERIA

9
USER CASE & USE CASE
DIAGRAM
 Insert Image

USE CASE
USE CASE
• 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

12
USER GOAL TECHNIQUE
• This technique is the most common in industry
• Simple and effective
• Identify all of the potential categories of users of the system
• Interview and ask them to describe the tasks the computer can
help them with
• Probe further to refine the tasks into specific user goals, “I need
to search for item(s), Fill shopping cart, View product
comment(s) and rating(s)”

13
USER GOAL TECHNIQUE - EXAMPLES

14
USER GOAL TECHNIQUE - STEPS
1 Identify all the potential users for the new system

Classify the potential users in terms of their functional role (e.g.,

2 shipping, marketing, sales)

3 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
4 have when using the new system (current goals (tasks) and innovative
functions to add value)

15
USER GOAL TECHNIQUE - STEPS
Create a list of preliminary use cases organized by
5
type of user

6 Look for duplicates with similar use case names

and resolve inconsistencies

Identify where different types of users need the

7
same use cases

Review the completed list with each type of user

8
and then with interested stakeholders

16
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

17
EVENTS AND USE CASES

18
TYPES OF EVENTS

External Temporal State Event

Event
an event that occurs
outside the system,
Event
an event that occurs as
a result of reaching a
-an event that occurs
when something
usually initiated by an point in time happens inside the
external agent or actor system that triggers
some process
-reorder point is reached
for inventory item

19
EXTERNAL EVENT CHECKLIST
External agent or
actor wants
something • Customer buys a product
resulting in a
transaction
External agent or • Customer wants to know
actor wants some
information product details
External data
changed and • Customer has new address
needs to be and phone
updated
Management • Sales manager wants
wants some
information update on production plans
20
TEMPORAL EVENT CHECKLIST

Internal outputs External outputs

needed at points in needed at points of
time
Management reports (summary or time
Statements, status reports, bills,
exception) reminders
Operational reports (detailed
transactions)
Internal statements and
documents (including payroll)

21
FINDING THE ACTUAL EVENT THAT
AFFECTS THE SYSTEM

22
TRACING A SEQUENCE OF TRANSACTIONS RESULTING IN MANY EVENTS

23
PERFECT TECHNOLOGY ASSUMPTION
• Don’t worry about functions built into system because
of limits in technology and people. Wait until design.

24
 EVENT DECOMPOSITION TECHNIQUE:
BENEFITS

Uses perfect
EBP is a fundamental technology assumption
Events are broader Help decompose at the business process to make sure functions
than user goal: Capture right level of analysis: performed by one that support the users
temporal and state an elementary business person, in one place, in work are identified and
events process (EBP) response to a business not additional functions
event for security and system
controls

25
 Insert Image

USE CASE
DIAGRAM
USE CASE DIAGRAMS

• Use case diagram— a UML model used to graphically show uses cases and
their relationships to actors
• Recall UML is Unified Modelling 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

27
USE CASE DIAGRAMS SYMBOLS

28
USE CASE DIAGRAMS –
DRAW FOR EACH
SUBSYSTEM

29
USE CASE DIAGRAMS –
DRAW FOR ACTOR FOR
EXAMPLE CUSTOMER

30
USE CASE DIAGRAMS – DRAW FOR
INTERNAL RMO ACTORS

31
USE CASE DIAGRAMS – INCLUDE
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

32
USE CASE DIAGRAM - STEPS

1 2 3 4
For each
Identify all the Determine what
potential
Carefully
stakeholders each name each
stakeholder or communication
and users who need, select the use case
user needs to
would benefit review in a use use cases and diagram and
by seeing a case diagram: actors to show then note how
use case each and draw the and when the
diagram subsystem, for use case diagram
each type of diagram. There should be
user, for use are many
software used to
cases that are review use
of interest packages that
33
can be used to cases with
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

34
PRACTICES FOR REQUIREMENTS
ELABORATION

1. Identify 3.
2. 4.
the potential Requirement
Requirement Requirement
sources for s conflict and
s Elicitation s validation
requirements resolution

35
USE CASES AND CRUD TECHNIQUE
• CRUD is Create, Read/Report, Update, and Delete
(archive)
• Often introduced in database context
• Technique to validate, refine or cross-check use
cases
• NOT for primarily identifying use cases

36
USE CASES AND CRUD TECHNIQUE
• For Customer domain class, verify that there are use cases that create,
read/report, update, and delete (archive) the domain class

37
CRUD TECHNIQUE: STEPS
Identify all the data entities or domain classes involved in the
1 new system.

For each type of data (data entity or domain class), verify that a use case
2 has been identified that creates a new instance, updates existing instances,
reads or reports values of instances, and deletes (archives) an instance.

If a needed use case has been overlooked, add a new use

3 case and then identify the stakeholders.

With integrated applications, make sure it is clear which

4 application is responsible for adding and maintaining the data
and which application merely uses the data.
38
CRUD TECHNIQUE
USE CASE VS. DOMAIN CLASS TABLE

 To summarize CRUD analysis results, create a matrix of

use cases and domain classes indicating which use case
C, R, U, or D a domain class

39
SUMMARY
 This chapter is the first of three that focuses on
modelling functional requirements as a part of
systems analysis
 Use cases are the functions identified, the activities
the system carries out usually in response to a user
request
 Two techniques for identifying use cases are the
user goal technique and the event decomposition
technique
 The user goal technique begins by identifying end
users called actors and asking what specific goals
they have when interacting with the system
 The event decomposition technique begins by
identifying events that occur that require the
system to respond.
40
QUESTIONS?
REFERENCE:

Satzinger, Jackson, Burd,

System Analysis and Design In
a Changing World 7th Edition.