Systems Analysis

and Design

Jeffrey A. Hoffer
Joey F. George
Joseph S. Valacich

Chapter 3.2
Structuring System Process
Requirements
Learning Objectives
 Understand
 the logical modeling of processes by studying
examples of data flow diagrams (DFDs).
 Draw
 data flow diagrams following specific rules and
guidelines that lead to accurate and well-structured
process models.
 Decompose
 data flow diagrams into lower-level diagrams.
 Balance
 higher-level and lower-level data flow diagrams.

2
Learning Objectives (Cont.)
 Use
 dataflow diagrams as a tool to support the
analysis of information systems.
 Use
 decisiontables to represent the logic of
choice in conditional statements.

3
Process Modeling

FIGURE 7-1
Systems development life cycle with the analysis phase highlighted

4
Process Modeling (Cont.)
 Graphically represent the processes that
 capture,
 manipulate,
 store,
 distribute
data between a system and its environment
and among system components.
 Utilize information gathered during requirements
determination.
 Processes and data structures are modeled.

5
Data Flow Diagramming
Mechanics
 Context data flow diagram (DFD)
 Scope of system
 Represent both physical and logical information
systems
 Only four symbols are used
 Useful for depicting purely logical information
flows
 DFDs that detail physical systems differ from
system flowcharts which depict details of
physical computing equipment

6
Definitions and Symbols

FIGURE 7-2
Comparison of DeMarco
and Yourdon
and Gane and Sarson
DFD symbol sets

7
Definitions and Symbols (Cont.)
 Process:
 work or actions performed on data (inside the system)
 Data store:
 data at rest (inside the system)
 Source/sink:
 external entity that is origin or destination of data
(outside the system)
 Data flow:
 arrows depicting movement of data

8
Developing DFDs
 Context diagram is an overview of an
organizational system that shows:
 the system boundaries.
 external entities that interact with the system.
 major information flows between the entities
and the system.

9
Context Diagram

FIGURE 7-4
Context diagram of Hoosier Burger’s food-ordering system

10
Developing DFDs (Cont.)
 Level-0 diagram
a data flow diagram that represents a
system’s major processes, data flows, and
data stores at a high level of detail.
 Processes are labeled 1.0, 2.0, etc. These will
be decomposed into more primitive (lower-
level) DFDs.

11
 Level-0 Diagram

FIGURE 7-5
Level-0 DFD of Hoosier Burger’s
food-ordering system

12
Data Flow Diagramming Rules

 There are two DFD guidelines that apply:

 The inputs to a process are different from the
outputs of that process.
 Processes purpose is to transform inputs into
outputs.
 Objects on a DFD have unique names.
 Every process has a unique name.

13
Data Flow Diagramming Rules (Cont.)
TABLE 7-2 Rules Governing Data Flow Diagramming

14
Data Flow Diagramming Rules (Cont.)
TABLE 7-2 Rules Governing Data Flow Diagramming (cont.)

15
Decomposition of DFDs
 Functional decomposition
 an iterative process of breaking a system
description down into finer and finer detail.
 Creates a set of charts in which one process
on a given chart is explained in greater detail
on another chart.
 Continues until no subprocess can logically
be broken down any further.

16
Decomposition of DFDs (Cont.)
 Primitive DFD is the lowest level of a DFD.
 Level-1 diagram
 results
from decomposition of Level-0
diagram.
 Level-n diagram
a DFD diagram that is the result of n nested
decompositions from a process on a level-0
diagram.

17
 Level-1 DFD FIGURE 7-8
Level-1 diagram showing the decomposition
of Process 4.0 from the level-0 diagram for
Hoosier Burger’s food-ordering system

Level-1 DFD shows

the sub-processes
of one of the
processes in the
Level-0 DFD.
Processes are labeled 4.1, 4.2, etc.
These can be further decomposed This is a Level-1
in more primitive (lower-level) DFD for Process
DFDs if necessary. 4.0.

18
Level-n DFD
FIGURE 7-9
Level-2 diagram showing the decomposition of
Level-n DFD shows
Process 4.3 from the level-1 diagram for Process
the sub-processes
4.0 for Hoosier Burger’s food-ordering system
of one of the
processes in the
Level n-1 DFD.

This is a Level-2
DFD for Process
4.3.

Processes are labeled 4.3.1, 4.3.2, etc. If this is the

lowest level of the hierarchy, it is called a primitive DFD.

19
Balancing DFDs
 Conservation Principle:
 conserve inputs and outputs to a process at
the next level of decomposition
 Balancing:
 conservation of inputs and outputs to a data
flow diagram process when that process is
decomposed to a lower level

20
Balancing DFDs (Cont.)
 Balanced means:
Number of inputs
 tolower level DFD equals number of inputs
to associated process of higher-level DFD
Number of outputs
 tolower level DFD equals number of
outputs to associated process of higher-
level DFD

21
Balancing DFDs (Cont.)
FIGURE 7-10 An unbalanced set of data flow diagrams

(a) Context diagram

1 input
This is
1 output unbalanced
because the
(b) Level-0 diagram process of the
context diagram
has only one
input but the
2 inputs Level-0 diagram
1 output has two inputs.

22
Balancing DFDs (Cont.)
 Data flow splitting
when a composite data flow at a higher level
is split and different parts go to different
processes in the lower level DFD.
 The DFD remains balanced because the
same data is involved, but split into two
parts.

23
Balancing DFDs (Cont.)
FIGURE 7-11
Example of data flow splitting

(a) Composite data flow

(b) Disaggregated data flows

24
Modeling Logic with Decision
Tables
 Decision table:
a matrix representation of the logic of a
decision which specifies the possible
conditions for the decision and the resulting
actions.
 Best used for complicated decision logic.

25
Modeling Logic with Decision
Tables (Cont.)

FIGURE 7-18
Complete decision table for payroll system example

26
Modeling Logic with Decision
Tables (Cont.)
 Condition stubs:
 thatpart of a decision table that lists the
conditions relevant to the decision
 Action stubs:
 that part of a decision table that lists the
actions that result for a given set of conditions

27
Modeling Logic with Decision
Tables (Cont.)
 Rules:
 that part of a decision table that specifies
which actions are to be followed for a given
set of conditions
 Indifferent condition:
 ina decision table, a condition whose value
does not affect which actions are taken for
two or more rules

28
Modeling Logic with Decision
Tables (Cont.)
 Procedure for Creating Decision Tables
 Name the condition and the values that each
condition can assume.
 Name all possible actions that can occur.
 List all possible rules.
 Define the actions for each rule.
 Simplify the table.

Chapter 7 © 2011 Pearson Education, Inc. 29

Publishing as Prentice Hall
Electronic Commerce Application: Process
Modeling using Data Flow Diagrams (Cont.)

Chapter 7 © 2011 Pearson Education, Inc. 30

Publishing as Prentice Hall
Electronic Commerce Application: Process
Modeling using Data Flow Diagrams

FIGURE 7-22
Level-0 data flow
diagram for the
WebStore

31
Introduction to Entity-Relationship (E-
R) Modeling
 Entity-Relationship data model (E-R
model):
a detailed, logical representation of the
entities, associations and data elements for
an organization or business area
 Entity-relationship diagram (E-R
diagram):
a graphical representation of an E-R model

32
Introduction to Entity-Relationship (E-
R) Modeling
 The E-R model is expressed in terms of:
 Data entities in the business environment.
 Relationships or associations among those
entities.
 Attributes or properties of both the entities
and their relationships.

33
Naming and Defining Entity Types

 An entity type name should be:

A singular noun.
 Descriptive and specific to the organization.
 Concise.

 Event entity type should be named for the

result of the event, not the activity or
process of the event.

34
Naming and Defining Entity Types
(Cont.)
 An entity type definition should:
 Include a statement of what the unique
characteristic(s) is (are) for each instance.
 Make clear what entity instances are included
and not included in the entity type.
 Often include a description of when an
instance of the entity type is created or
deleted.

35
Naming and Defining Entity Types
(Cont.)
 For some entity types the definition must
specify:
 When an instance might change into an
instance of another entity type.
 What history is to be kept about entity
instances.

36
Attributes

 Attribute: a named property or

characteristic of an entity that is of interest
to the organization
 Naming an attribute: i.e. Vehicle_ID
 Place its name inside the rectangle for the
associated entity in the E-R diagram.

37
Naming and Defining Attributes

 An attribute name is a noun and should be

unique.
 To make an attribute name unique and for
clarity, each attribute name should follow a
standard format.
 Similar
attributes of different entity types
should use similar but distinguishing names.

38
Naming and Defining Attributes
(Cont.)
 An attribute definition:
 States what the attribute is and possibly why it
is important.
 Should make it clear what is included and
what is not included.
 Contain any aliases or alternative names.
 States the source of values for the attribute.

39
Naming and Defining Attributes
(Cont.)
 An attribute definition should indicate:
 If a value for the attribute is required or
optional.
 If a value for the attribute may change.
 Any relationships that attribute has with other
attributes.

40
Candidate Keys and Identifiers.
 Candidate key:
 an attribute (or combination of attributes) that
uniquely identifies each instance of an entity
type
 Identifier:
a candidate key that has been selected as the
unique, identifying characteristic for an entity
type

41
Candidate Keys and Identifiers
(Cont.)
 Selection rules for an identifier
 Choose a candidate key that will not change
its value.
 Choose a candidate key that will never be
null.
 Avoid using intelligent keys.
 Consider substituting single value surrogate
keys for large composite keys.

42
 Relationships
 Relationship:
 an association between the instances of one or
more entity types that is of interest to the
organization
 Degree:
 the number of entity types that participate in a
relationship

43
Conceptual Data Modeling and the
E-R Model
 Unary relationship:
 a relationship between the instances of one entity type
 Also called a recursive relationship
 Binary relationship:
 a relationship between instances of two entity types
 Most common type of relationship encountered in
data modeling
 Ternary relationship:
 a simultaneous relationship among instances of three
entity types
44
Unary relationships

FIGURE 8-11
Binary relationships
Examples of relationships
of different degrees

Ternary relationships

45
 FIGURE 8-14 Examples of cardinality constraints

(a) Mandatory cardinalities

(b) One optional, one mandatory cardinality

(c) Optional cardinalities

46
Naming and Defining Relationships

 A relationship name is a verb phrase;

avoid vague names.
 A relationship definition:
 Explains what action is to be taken and
possibly why it is important.
 Gives examples to clarify the action.

47