CHAPTER SIX

SYSTEM ANALYSIS: STRUCTURING SYSTEM REQUIREMENT

1
 Outline
 Introduction
 Process modeling
 Data flow diagramming
 Logic modeling
 Modeling logic with decision tables, structured English
 Conceptual data modeling
 E-R modeling
 Selecting the best design strategy

2
 Introduction
 Information gathered during requirement gathering
needs to be organized into a form which
represent existing and new system
requirement
 There are three stages in the structuring process
 Process modeling
 Logical Modeling
 Conceptual data modeling

3
 Process Modeling
 converting gathered requirements into diagrams using a systematic
method
 Graphically represent the processes that capture, manipulate, store, and
distribute data between a system and its environment and among system
components
 Utilize information gathered during requirements determination
 Processes and data structures are modeled
 A common form of a process model is a data flow diagram (DFD).

4
 Data Flow Diagram (DFD)
 A picture of the movement of data between external entities and the
processes and data stores within a system
 Excellent tool to model processes and functional requirements

5
 DFD Symbols
 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
 Examples:
DFD Diagramming Rules
Process

No process can have

only outputs or only
inputs…processes
must have both
outputs and inputs.

Process labels should be verb phrases.

DFD Diagramming Rules
Data Store

All flows to or from a data store must

move through a process.

Data store labels should be noun phrases.

DFD Diagramming Rules
Source/Sink

No data moves directly between external entities

without going through a process.

Interactions between external entities without

intervening processes are outside the system and
therefore not represented in the DFD.

Source and sink labels should be noun phrases.

DFD Diagramming Rules
Data Flow
Bidirectional flow
between process
and data store is
represented by two
separate arrows.

Forked data flow

must refer to exact
same data item (not
different data items)
from a common
location to multiple
destinations.
DFD Diagramming Rules
Data Flow (cont.)
Joined data flow
must refer to exact
same data item (not
different data items)
from multiple
sources to a
common location.

Data flow cannot

go directly from a
process to itself,
must go through
intervening
processes.
 DFD Diagramming Rules
Data Flow (cont.)
 Data flow from a process to a data store means update (insert, delete or change).
 Data flow from a data store to a process means retrieve or use.
 Data flow labels should be noun phrases.
 Decomposition of DFDs
 The act of going from a single system to more component processes is called decomposition
 Functional decomposition
 repetitive process of breaking the system into finer and finer detail
 Each process may consist of several sub processes. Each sub process may also be broken down
into smaller units.
 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

13
 Process Modeling Steps and Levels

Step 1. Draw the Context

DFD Context diagram
shows the system
• Overview of the organizational boundaries,
system external entities
that interact with
the system, and
major information
flows between
entities and the
system.

NOTE: only one process symbol, and no

data stores shown.
 Process Modeling Steps and Levels
 Step 2: Identifying process(es)
embedded in the single process of the
context diagram
 You may also identify some data stores along
the processes
 Step 3: Draw Level-0 Diagram
 Use identified processes to draw Level-0
DFD that represents a system’s major
processes, data flows, and data stores at a
higher level. Level-0 DFD.
Processes are labeled 1.0, 2.0, etc. These will be
decomposed into more primitive (lower-level) DFDs.
 Process Modeling Steps and Levels
 Step 4: Decompose Level-0 DFD processes
 For each Level-0 process:
 Identify the subprocesses that need to be performed
to complete the process
 Identify key data stores along the identified
subprocesses
 Draw the process’ Level-1 diagram

This is a Level-1 DFD for Process 4.0.

Processes are labeled 4.1, 4.2, etc. These can be

further decomposed in more primitive (lower-level)
DFDs if necessary.
 Process Modeling Steps and Levels
Step 5: Decompose Level-1 DFD processes
 For each Level-1 process:
 Identify the subprocesses that need to be performed to complete the process
 Identify key data stores along the identified subprocesses
 Draw the process’ Level-2 diagram
 Process Modeling Steps and Levels
 Step 6: Level-n DFD
 Results from decomposition of Level n-1 diagram
 As a rule of thumb, no DFD should have more
than about seven processes in it

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.
 DFD Balancing
 The conservation of inputs and outputs to a data flow process when that
process is decomposed to a lower level
 Balanced means:
 Number of inputs to lower level DFD equals number of inputs to associated process of
higher-level DFD
 Number of outputs to lower level DFD equals number of outputs to associated process
of higher-level DFD
 For Ex. Process 1, which appears in a level-0 diagram, must have the same inputs and
outputs when decomposed into a level-1 diagram is called balancing.
Unbalanced DFD

This is unbalanced because

1 input the process of the context
1 output diagram has only one input
but the Level-0 diagram has
two inputs.

2 inputs
1 output
Balanced DFD
1 input
2 outputs

These are balanced because the

numbers of inputs and outputs of
context diagram process equal the
number of inputs and outputs of
Level-0 diagram.
Balanced DFD (cont.)
These are balanced because the
numbers of inputs and outputs to
Process 1.0 of the Level-0 diagram
equals the number of inputs and
outputs to the Level-1 diagram.

1 input
4 outputs
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.
Guidelines for Drawing DFDs (cont.)
 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.
Guidelines for Drawing DFDs (cont.)
 Primitive DFDs
 Lowest logical level of decomposition
 Decision has to be made when to stop decomposition
Guidelines for Drawing DFDs (cont.)
 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
Guidelines for Drawing DFDs (cont.)
 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, online 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
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.
 Summary
 Data flow diagrams (DFD)
 Symbols
 Rules for creating
 Decomposition
 Balancing
 Four different kinds of DFDs
 Current Physical
 Current Logical
 New Logical
 New Physical
 DFDs for Analysis
34
 Logic Modeling
 DFDs do not show the logic inside the processes
 Logic modeling involves representing internal structure and functionality of processes
depicted on a DFD
 Two methods:
 Data Dictionary
 Decision Tree

35
 Data Dictionary
 A data dictionary is a structured repository of data elements in the system.
 It stores the descriptions of all DFD data elements that is, details and definitions of data
flows, data stores, data stored in data stores, and the processes.
 A data dictionary improves the communication between the analyst and the user.
 It plays an important role in building a database.
 Most DBMSs have a data dictionary as a standard feature. For example, refer the following
table:
 Decision Tree
 method for defining complex relationships by
describing decisions and avoiding the problems in
communication
 shows alternative actions and conditions within
horizontal tree framework
 depicts which conditions to consider first, second,
and so on
 A square node indicates an action and a circle
indicates a condition.
 It forces analysts to consider the sequence of
decisions and identifies the actual decision that must
be made
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

Condition Entry

Figure 6-16

Action Entry

38
 Structured English
 Modified form of English used to specify the logic of information processes
 Uses a subset of English
 Action verbs (Read, update, sort, generate..)
 Noun phrases
 No adjectives or adverbs
 No specific standards

39
Structured English (continued)
 Similar to programming language
 If conditions
BEGIN IF
IF Quantity is less than Minimum-order-
quantity
THEN GENERATE new order
ELSE DO nothing
END IF
 Case statements

Figure 5-15 shows structured English representation for

Hoosier Burger
 Conceptual Data Modeling (E-R Diagram)

41