1. BAB III
DATA MODELING dan
ANALYSIS
kipram 1

2. A. Determining System Requirements
Performing Requirements Determination
Gather information on what system
should do from many sources
Users
Reports
Forms
Procedures
kipram 2

3. Performing Requirements Determination
Characteristics for gathering
requirements
Impertinence
Question everything
Impartiality
Find the best organizational solution
Relaxation of constraints
Attention to detail
Reframing
View the organization in new ways
kipram 3

4. Deliverables and Outcomes
Types of deliverables:
Information collected from users
Existing documents and files
Computer-based information
Understanding of organizational components
Business objective
Information needs
Rules of data processing
Key events
kipram 4

5. Traditional Methods for Determining
Requirements
Interviewing and Listening
Gather facts, opinions and speculations
Observe body language and emotions
Guidelines
Plan
Checklist
Appointment
Be neutral
Listen
Seek a diverse view
kipram 5

6. Traditional Methods for Determining
Requirements
Interviewing (Continued)
Interview Questions
Open-Ended
No pre-specified answers
Close-Ended
Respondent is asked to choose from a set of specified
responses
Additional Guidelines
Do not phrase questions in ways that imply a wrong or
right answer
Listen very carefully to what is being said
Type up notes within 48 hours
Do not set expectations about the new system
kipram 6

7. Traditional Methods for Determining
Requirements
Administering Questionnaires
More cost-effective than interviews
Choosing respondents
Should be representative of all users
Types of samples
Convenient
Random sample
Purposeful sample
Stratified sample
kipram 7

8. Traditional Methods for Determining
Requirements
Questionnaires
Design
Mostly closed-ended questions
Can be administered over the phone or in
person
Vs. Interviews
Interviews cost more but yield more information
Questionnaires are more cost-effective
See table 7-4 for a complete comparison
kipram 8

9. Traditional Methods for Determining
Requirements
Interviewing Groups
Advantages
More effective use of time
Enables people to hear opinions of others and to agree
or disagree
Disadvantages
Difficulty in scheduling
Nominal Group Technique
Facilitated process to support idea generation by groups
Individuals work alone to generate ideas which are
pooled under guidance of a trained facilitator
kipram 9

10. Traditional Methods for Determining
Requirements
Directly Observing Users
Serves as a good method to supplement
interviews
Often difficult to obtain unbiased data
People often work differently when being
observed
kipram 10

11. Analyzing Procedures and Other
Documents
Types of information to be discovered:
Problems with existing system
Opportunity to meet new need
Organizational direction
Names of key individuals
Values of organization
Special information processing circumstances
Reasons for current system design
Rules for processing data
kipram 11

12. Analyzing Procedures and Other
Documents
Four types of useful documents
Written work procedures
Describes how a job is performed
Includes data and information used and created in the
process of performing the job or task
Business form
Explicitly indicate data flow in or out of a system
Report
Enables the analyst to work backwards from the report to
the data that generated it
Description of current information system
kipram 12

13. Modern Methods for Determining
Requirements
Joint Application Design (JAD)
Brings together key users, managers and systems
analysts
Purpose: collect system requirements
simultaneously from key people
Conducted off-site
Prototyping
Repetitive process
Rudimentary version of system is built
Replaces or augments SDLC
Goal: to develop concrete specifications for
ultimate system
kipram 13

14. Joint Application Design (JAD)
Participants
Session Leader
Users
Managers
Sponsor
Systems Analysts
Scribe
IS Staff
kipram 14

15. Joint Application Design (JAD)
End Result
Documentation detailing existing system
Features of proposed system
CASE Tools During JAD
Upper CASE tools are used
Enables analysts to enter system models directly into CASE
during the JAD session
Screen designs and prototyping can be done during JAD
and shown to users
Supporting JAD with GSS
Group support systems (GSS) can be used to enable more
participation by group members in JAD
Members type their answers into the computer
All members of the group see what other members have
been typing
kipram 15

16. Prototyping
Quickly converts requirements to working
version of system
Once the user sees requirements converted
to system, will ask for modifications or will
generate additional requests
Most useful when:
User requests are not clear
Few users are involved in the system
Designs are complex and require concrete form
History of communication problems between
analysts and users
Tools are readily available to build prototype
kipram 16

17. Prototyping
Drawbacks
Tendency to avoid formal documentation
Difficult to adapt to more general user
audience
Sharing data with other systems is often
not considered
Systems Development Life Cycle (SDLC)
checks are often bypassed
kipram 17

18. Business Process Reengineering (BPR)
Search for and implementation of radical change in business
processes to achieve breakthrough improvements in products
and services
Goals
Reorganize complete flow of data in major sections of an
organization
Eliminate unnecessary steps
Combine steps
Become more responsive to future change
Identification of processes to reengineer
Key business processes
Set of activities designed to produce specific output for a
particular customer or market
Focused on customers and outcome
Same techniques are used as were used for requirements
7.18
7.18 determination
kipram 18

19. Business Process Reengineering (BPR)
Identify specific activities that can be
improved through BPR
Disruptive technologies
Technologies that enable the breaking of
long-held business rules that inhibit
organizations from making radical business
changes
kipram 19

20. B. Structuring System Requirements:
1. Process Modeling
kipram 20

21. Process Modeling
Graphically represent the processes that capture,
manipulate, store and distribute data between a system
and its environment and among system components
Data flow diagrams (DFD)
Graphically illustrate movement of data between
external entities and the processes and data stores
within a system
Modeling a system’s process
Utilize information gathered during requirements
determination
Structure of the data is also modeled in addition to the
processes
Deliverables and Outcomes
Set of coherent, interrelated data flow diagrams
kipram 21

22. Process Modeling
Deliverables and outcomes (continued)
Context data flow diagram (DFD)
Scope of system
DFDs of current system
Enables analysts to understand current system
DFDs of new logical system
Technology independent
Show data flows, structure and functional requirements of
new system
Project dictionary and CASE repository
kipram 22

23. Data Flow Diagramming Mechanics
Four symbols are used
See Figure 8-2
Two different standard sets can be used
DeMarco and Yourdan
Gane and Sarson
kipram 23

24. Figure 8-2
Comparison of DeMarco & Yourdan and Gane &
Sarson DFD symbol sets
kipram 24

25. Data Flow Diagramming Mechanics
Data Flow
Depicts data that are in motion and moving as a unit from
one place to another in the system.
Drawn as an arrow
Select a meaningful name to represent the data
Data Store
Depicts data at rest
May represent data in
File folder
Computer-based file
Notebook
The name of the store as well as the number are recorded in
between lines
kipram 25

26. Data Flow Diagramming Mechanics
Process
Depicts work or action performed on data so that they are
transformed, stored or distributed
Number of process as well as name are recorded
Source/Sink
Depicts the origin and/or destination of the data
Sometimes referred to as an external entity
Drawn as a square symbol
Name states what the external agent is
Because they are external, many characteristics are not of
interest to us
8.26
8.26
kipram 26

27. Data Flow Diagramming Definitions
Context Diagram
A data flow diagram (DFD) of the scope of an
organizational system that shows the system
boundaries, external entities that interact with the
system and the major information flows between
the entities and the system
Level-O Diagram
A data flow diagram (DFD) that represents a
system’s major processes, data flows and data
stores at a high level of detail
kipram 27

28. Developing DFDs: An Example
Hoosier Burger’s automated food
ordering system
Context Diagram (Figure 8-4) contains
no data stores
Next step is to expand the context
diagram to show the breakdown of
processes (Figure 8-5)
kipram 28

29. Figure 8-4
Context diagram of Hoosier Burger’s
food ordering system
kipram 29

30. Figure 8-5
Level-0 DFD of Hoosier Burger’s food ordering system
kipram 30

31. Data Flow Diagramming Rules
Basic rules that apply to all DFDs
Inputs to a process are always different
than outputs
Objects always have a unique name
In order to keep the diagram uncluttered, you
can repeat data stores and sources/sinks on a
diagram
kipram 31

32. Data Flow Diagramming Rules
Process Data Store
No process can have Data cannot be moved
directly from one store to
only outputs (a another
miracle) Data cannot move
No process can have directly from an outside
only inputs (black source to a data store
hole) Data cannot move
directly from a data store
A process has a verb to a data sink
phrase label Data store has a noun
phrase label
kipram 32

33. Data Flow Diagramming Rules
Source/Sink Data Flow
Data cannot move A data flow has only one
direction of flow between
directly from a symbols
source to a sink A fork means that exactly
A source/sink has a the same data goes from
noun phrase label a common location to two
or more processes, data
stores or sources/sinks
kipram 33

34. Data Flow Diagramming Rules
Data Flow (Continued)
L. A join means that exactly the same data comes
from any two or more different processes, data
stores or sources/sinks to a common location
M. A data flow cannot go directly back to the same
process it leaves
N. A data flow to a data store means update
O. A data flow from a data store means retrieve or
use
P. A data flow has a noun phrase label
kipram 34

35. Decomposition of DFDs
Functional decomposition
Act of going from one single system to many
component processes
Repetitive procedure
Lowest level is called a primitive DFD
Level-N Diagrams
A DFD that is the result of n nested
decompositions of a series of subprocesses from
a process on a level-0 diagram
kipram 35

36. Balancing DFDs
When decomposing a DFD, you must
conserve inputs to and outputs from a
process at the next level of decomposition
This is called balancing
Example: Hoosier Burgers
In Figure 8-4, notice that there is one input to the
system, the customer order
Three outputs:
Customer receipt
Food order
Management reports
kipram 36

37. Balancing DFDs
Example (Continued)
Notice Figure 8-5. We have the same
inputs and outputs
No new inputs or outputs have been
introduced
We can say that the context diagram and
level-0 DFD are balanced
kipram 37

38. Balancing DFDs
An unbalanced example
Figure 8-10
In context diagram, we have one input to
the system, A and one output, B
Level-0 diagram has one additional data
flow, C
These DFDs are not balanced
kipram 38

39. Figure 8-10
An unbalanced set of data flow diagrams
(a) Context diagram
(b) Level-0 diagram
kipram 39

40. Balancing DFDs
We can split a data flow into separate
data flows on a lower level diagram (see
Figure 8-11)
Balancing leads to four additional
advanced rules (See Table 8-3)
kipram 40

41. Four Different Types of DFDS
Current Physical
Process label includes an identification of
the technology (people or systems) used to
process the data
Data flows and data stores are labeled with
the actual name of the physical media on
which data flow or in which data are stored
kipram 41

42. Four Different Types of DFDS
Current Logical
Physical aspects of system are removed as much
as possible
Current system is reduced to data and processes
that transform them
New Logical
Includes additional functions
Obsolete functions are removed
Inefficient data flows are reorganized
New Physical
Represents the physical implementation of the
new system
kipram 42

43. Guidelines for Drawing DFDs
Completeness
DFD must include all components
necessary for system
Each component must be fully described in
the project dictionary or CASE repository
Consistency
The extent to which information contained
on one level of a set of nested DFDs is
also included on other levels
kipram 43

44. Guidelines for Drawing DFDs
Timing
Time is not represented well on DFDs
Best to draw DFDs as if the system has never
started and will never stop.
Iterative Development
Analyst should expect to redraw diagram several
times before reaching the closest approximation to
the system being modeled
Primitive DFDs
Lowest logical level of decomposition
Decision has to be made when to stop
decomposition
kipram 44

45. Guidelines for Drawing DFDs
Rules for stopping decomposition
When each process has been reduced to a
single decision, calculation or database
operation
When each data store represents data
about a single entity
When the system user does not care to
see any more detail
kipram 45

46. Guidelines for Drawing DFDs
Rules for stopping decomposition (continued)
When every data flow does not need to be split
further to show that data are handled in various
ways
When you believe that you have shown each
business form or transaction, on-line display and
report as a single data flow
When you believe that there is a separate process
for each choice on all lowest-level menu options
kipram 46

47. Using DFDs as Analysis Tools
Gap Analysis
The process of discovering discrepancies
between two or more sets of data flow
diagrams or discrepancies within a single
DFD
Inefficiencies in a system can often be
identified through DFDs
kipram 47

48. Using DFDs in Business Process
Reengineering
Example: IBM Credit
See Figure 8-20 – before reengineering
Credit approval process required six days
before BPR
Figure 8-21 depicts DFD after
reengineering
IBM was able to process 100 times the
number of transactions in the same
amount of time
kipram 48

49. Oracle’s Process Modeler and Functional
Hierarchy Diagrams
Process Modeler
Unique to Oracle
Similar to DFDS but outputs and methods differ in
several ways.
Table 8-4 illustrates differences
Functional Hierarchy Diagrams
Picture of various tasks performed in a business
and how they are related
Tasks are broken down into their various parts
Does not include data flows
kipram 49

50. Simple Data Flow Diagram
Data flow
Process Data store
(internal
entity)
External
agent
(entity)
kipram 50

51. Process Decomposition
kipram 51

52. Decomposition Diagrams
kipram 52

53. Illegal Data Flows
Practice data flow conservation –
only data needed should move
kipram 53

54. Summary
Data flow diagrams (DFD)
Symbols
Rules for creating
Decomposition
Balancing
Four different kinds of DFDs
Current Physical
Current Logical
New Logical
New Physical
kipram 54

55. Summary
DFDs for Analysis
DFDs for Business Process
Reengineering (BPR)
Oracle’s Process Modeler
Functional Hierarchy Diagrams
8.55
8.55
kipram 55

56. 2. Logic Modeling
kipram 56

57. Logic Modeling
Data flow diagrams do not show the
logic inside the processes
Logic modeling involves representing
internal structure and functionality of
processes depicted on a DFD
Logic modeling can also be used to
show when processes on a DFD occur
kipram 57

58. Logic Modeling
Deliverables and Outcomes
Structured English
Decision Tables
Decision Trees
State-transition diagrams
Sequence diagrams
Activity diagrams
kipram 58

59. Modeling Logic with Structured
English
Modified form of English used to specify
the logic of information processes
Uses a subset of English
Action verbs
Noun phrases
No adjectives or adverbs
No specific standards
kipram 59

60. Modeling Logic with Structured
English
Similar to programming language
If conditions
Case statements
Figure 9-3 shows Structured English
representation for Hoosier Burger
kipram 60

61. Modeling Logic with
Decision Tables
A matrix representation of the logic of a decision
Specifies the possible conditions and the resulting
actions
Best used for complicated decision logic
Consists of three parts
Condition stubs
Lists condition relevant to decision
Action stubs
Actions that result from a given set of conditions
Rules
Specify which actions are to be followed for a given set of
conditions
kipram 61

62. Modeling Logic with
Decision Tables
Indifferent Condition
Condition whose value does not affect which
action is taken for two or more rules
Standard procedure for creating decision
tables
Name the condition and values each condition can
assume
Name all possible actions that can occur
List all rules
Define the actions for each rule
Simplify the table
kipram 62

63. Figure 9-4
Complete decision table for payroll system example
kipram 63

64. Modeling Logic with Decision Trees
A graphical representation of a decision
situation
Decision situation points are connected
together by arcs and terminate in ovals
Two main components
Decision points represented by nodes
Actions represented by ovals
kipram 64

65. Modeling Logic with Decision Trees
Read from left to right
Each node corresponds to a numbered
choice on a legend
All possible actions are listed on the far
right
kipram 65

66. Figure 9-9
Decision tree representation of the decision logic in the decision
tables in Figures 9-4 and 9-5, with only two choices per decision
point
kipram 66

67. Deciding Among Structured English,
Decision Tables and Decision Trees
Criteria Structured Decision Decision
English Tables Trees
Determining Second Best Third Best Best
Conditions and
Actions
Transforming Best Third Best Best
Conditions and
Actions into
Sequence
Checking Third Best Best Best
Consistency
and
Completeness
kipram 67

68. Summary
Several methods of logic modeling
Structured English
Primarily communication technique for analysts
and users
Decision Tables
Conditions are listed in condition stubs
Possible actions are listed in action stubs
Rules link conditions with actions
kipram 68

69. Summary
Decision Tables
Lists all possible rules
Decision Trees
Conditions are portrayed by decision points
Values are represented by paths between
decision points and ovals that contain
actions
kipram 69

70. Summary
Comparison of Structured English,
Decision Tables and Decision Trees
Most studies show that decision trees are
best for many criteria
There is no best technique
Analyst must be proficient in all three
kipram 70

71. C. Conceptual Data Modeling
kipram 71

72. Learning Objectives
Define key data modeling terms
Entity type
Attribute
Multivalued attribute
Relationship
Degree
Cardinality
Business Rule
Associative entity
Trigger
Supertype
Subtype
kipram 72

73. Conceptual Data Modeling
Representation of organizational data
Purpose is to show rules about the meaning and
interrelationships among data
Entity-Relationship (E-R) diagrams are commonly
used to show how data are organized
Main goal of conceptual data modeling is to create
accurate E-R diagrams
Methods such as interviewing, questionnaires and
JAD are used to collect information
Consistency must be maintained between process
flow, decision logic and data modeling descriptions
kipram 73

74. Process of Conceptual Data
Modeling
First step is to develop a data model for the
system being replaced
Next, a new conceptual data model is built
that includes all the requirements of the new
system
In the design stage, the conceptual data
model is translated into a physical design
Project repository links all design and data
modeling steps performed during SDLC
kipram 74

75. Deliverables and Outcome
Primary deliverable is the entity-relationship
diagram
There may be as many as 4 E-R diagrams
produced and analyzed during conceptual
data modeling
Covers just data needed in the project’s
application
E-R diagram for system being replaced
An E-R diagram for the whole database from
which the new application’s data are extracted
An E-R diagram for the whole database from
which data for the application system being
replaced is drawn
kipram 75

76. Figure 10-3
Sample conceptual data model diagram
kipram 76

77. Deliverables and Outcome
Second deliverable is a set of entries about
data objects to be stored in repository or
project dictionary
Repository links data, process and logic models of
an information system
Data elements that are included in the DFD must
appear in the data model and visa versa
Each data store in a process model must relate to
business objects represented in the data model
kipram 77

78. Gathering Information for Conceptual
Data Modeling
Two perspectives
Top-down
Data model is derived from an intimate
understanding of the business
Bottom-up
Data model is derived by reviewing
specifications and business documents
kipram 78

79. Introduction to Entity-Relationship (E-R)
Modeling
Notation uses three main constructs
Data entities
Relationships
Attributes
Entity-Relationship (E-R) Diagram
A detailed, logical representation of the
entities, associations and data elements for
an organization or business
kipram 79

80. Entity-Relationship (E-R)
Modeling
Entity Key Terms
A person, place, object, event or concept in the
user environment about which the organization
wishes to maintain data
Represented by a rectangle in E-R diagrams
Entity Type
A collection of entities that share common
properties or characteristics
Attribute
A named property or characteristic of an entity that
is of interest to an organization
kipram 80

81. Entity-Relationship (E-R) Modeling
Key Terms
Candidate keys and identifiers
Each entity type must have an attribute or
set of attributes that distinguishes one
instance from other instances of the same
type
Candidate key
Attribute (or combination of attributes) that
uniquely identifies each instance of an entity
type
kipram 81

82. Entity-Relationship (E-R) Modeling
Key Terms
Identifier
A candidate key that has been selected as the
unique identifying characteristic for an entity type
Selection rules for an identifier
1. Choose a candidate key that will not change its value
2. Choose a candidate key that will never be null
3. Avoid using intelligent keys
4. Consider substituting single value surrogate keys for
large composite keys
kipram 82

83. Entity-Relationship (E-R) Modeling
Key Terms
Multivalued Attribute
An attribute that may take on more than
one value for each entity instance
Represented on E-R Diagram in two ways:
double-lined ellipse
weak entity
kipram 83

84. Entity-Relationship (E-R) Modeling
Relationship Key Terms
An association between the instances of
one or more entity types that is of interest
to the organization
Association indicates that an event has
occurred or that there is a natural link
between entity types
Relationships are always labeled with verb
phrases
kipram 84

85. Conceptual Data Modeling and the
E-R Diagram
Goal
Capture as much of the meaning of the data as
possible
Result
A better design that is easier to maintain
kipram 85

86. Degree of Relationship
Degree
Number of entity types that participate in a
relationship
Three cases
Unary
A relationship between two instances of one entity type
Binary
A relationship between the instances of two entity types
Ternary
A simultaneous relationship among the instances of
three entity types
Not the same as three binary relationships
10.86
10.86
kipram 86

87. Figure 10-6
Example relationships of different degrees
kipram 87

88. Cardinality
The number of instances of entity B that can
be associated with each instance of entity A
Minimum Cardinality
The minimum number of instances of entity B that
may be associated with each instance of entity A
Maximum Cardinality
The maximum number of instances of entity B that
may be associated with each instance of entity A
kipram 88

89. Naming and Defining Relationships
Relationship name is a verb phrase
Avoid vague names
Guidelines for defining relationships
Definition explains what action is being taken and
why it is important
Give examples to clarify the action
Optional participation should be explained
Explain reasons for any explicit maximum
cardinality
10.89
10.89
kipram 89

90. Naming and Defining Relationships
Guidelines for defining relationships
Explain any restrictions on participation in
the relationship
Explain extent of the history that is kept in
the relationship
Explain whether an entity instance involved
in a relationship instance can transfer
participation to another relationship
instance
kipram 90

91. Associative Entity
An entity type that associates the
instances of one or more entity types
and contains attributes that are peculiar
to the relationship between those entity
instances
10.91
10.91
kipram 91

92. Domains
The set of all data types and ranges of
values that an attribute can assume
Several advantages
1. Verify that the values for an attribute are
valid
2. Ensure that various data manipulation
operations are logical
3. Help conserve effort in describing
attribute characteristics
kipram 92

93. Triggering Operations
An assertion or rule that governs the validity of data
manipulation operations such as insert, update and delete
Includes the following components:
User rule
Statement of the business rule to be enforced by the
trigger
Event
Data manipulation operation that initiates the operation
Entity Name
Name of entity being accessed or modified
Condition
Condition that causes the operation to be triggered
Action
Action taken when the operation is triggered
kipram 93

94. Triggering Operations
Responsibility for data integrity lies
within scope of database management
system, not individual applications
kipram 94

95. The Role of CASE in Conceptual Data
CASE tools provide two important
functions:
Maintain E-R diagrams as a visual
depiction of structured data requirements
Link objects on E-R diagrams to
corresponding descriptions in a repository
kipram 95

96. Summary
Process of conceptual data modeling
Deliverables
Gathering information
Entity-Relationship Modeling
Entities
Attributes
Candidate keys and identifiers
Multivalued attributes
Degree of relationship
kipram 96

97. Summary
Cardinality
Naming and defining relationships
Associative entities
Domains
Triggering Operations
Role of CASE
kipram 97