ANALYSIS AND SYSTEM DESIGN

Using data flow

diagram
GROUP 4:
GIFFARI IBNU TORIQ ( 2110531014)
ZAKYA (2110531034)
 The Data Flow Approach to Human
Requirements Determination

When systems analysts attempt to Advantages of Data Flow Approach

understand the information 1.Freedom from committing to the
requirements of users, they must be technical implementation of the system
able to conceptualize how data move too early.
through the organization, the processes 2.Further understanding of the
or transformation that the data interrelatedness of systems and
undergo, and what the outputs are subsystems.
3.Communicating current system
knowledge to users through data flow
diagrams.
4.Analysis of a proposed system to
determine if the necessary data and
processes have been defined
Conventions Used in Data Developing Data Flow
Flow Diagrams Diagram
Here are a few basic rules to follow:
1.The data flow diagram must have at least
one process, and must not have any
freestanding objects or objects connected to
themselves.
2.A process must receive at least one data
flow coming into the process and create at
least one data flow leaving from the process.
3.A data store should be connected to at least
one process.
4.External entities should not be connected
to each other. Although they communicate
independently, that communication is not
part of the system we design using DFDs
 Developing Data Flow Diagram

Here are a few basic rules to follow:

1.The data flow diagram must have at least one process, and must
not have any freestanding objects or objects connected to
themselves.
2.A process must receive at least one data flow coming into the
process and create at least one data flow leaving from the process.
3.A data store should be connected to at least one process.
4.External entities should not be connected to each other. Although
they communicate independently, that communication is not part of
the system we design using DFDs
Creating the context of
diagram
 Using data flow diagram
1.Start with the data flow from an entity on the input side. Ask questions such as:
“What happens to the data entering the system?” “Is it stored?” “Is it input for
several processes?”
2.Work backward from an output data flow. Examine the output fields on a
document or screen. (This approach is easier if prototypes have been created.) For
each field on the output, ask: “Where does it come from?” or “Is it calculated or
stored on a file?” For example, when the output is a PAYCHECK, the EMPLOYEE
NAME and ADDRESS would be located on an EMPLOYEE file, the HOURS WORKED
would be on a TIME RECORD, and the GROSS PAY and DEDUCTIONS would be
calculated. Each file and record would be connected to the process that produces
the paycheck.
3.Examine the data flow to or from a data store. Ask: “What processes put data into
the store?” or “What processes use the data?” Note that a data store used in the
system you are working on may be produced by a different system. Thus, from your
vantage point, there may not be any data flow into the data store.
4. Analyze a well-defined process. Look at what input data the process needs and
what output it produces. Then connect the input and output to the appropriate
data stores and entities.
5. Take note of any fuzzy areas where you are unsure of what should be included
or what input or output is required. Awareness of problem areas will help you
formulate a list of questions for follow-up interviews with key users
 Checking the Diagrams for Errors
1. Forgetting to include a data flow or pointing an arrow in the wrong direction. An
example is a drawn process showing all its data flow as either input or output. Each
process transforms data and must receive input and produce output. This type of
error usually occurs when the analyst has forgotten to include a data flow or has
placed an arrow pointing in the wrong direction.
2. Connecting data stores and external entities directly to each other. Data stores
and entities may not be connected to each other; data stores and external entities
must connect only with a process. A file does not interface with another file without
the help of a program or a person moving the data, so EMPLOYEE MASTER cannot
directly produce the CHECK RECONCILIATION file. External entities do not directly
work with files.
3. Incorrectly labeling processes or data flow. Inspect the data flow diagram to
ensure that each object or data flow is properly labeled. A process should indicate
the system name or use the verb-adjective-noun format. Each data flow should be
described with a noun.
4. Including more than nine processes on a data flow diagram. Having too many
processes creates a cluttered diagram that is confusing to read and hinders rather
than enhances communication. If more than nine processes are involved in a system,
group some of the processes that work together into a subsystem and place them in a
child diagram.
5. Omitting data flow. Examine your diagram for linear flow, that is, data flow in which
each process has only one input and one output. Except in the case of very detailed
child data flow diagrams, linear data flow is somewhat rare. Its presence usually
indicates that the diagram has missing data flow. For instance, the process CALCULATE
WITHHOLDING AMOUNT needs the number of dependents that an employee has and
the WITHHOLDING RATES as input. In addition, NET PAY cannot be calculated solely
from the WITHHOLDING, and the EMPLOYEE PAYCHECK cannot be created from the
NET PAY alone; it also needs to include an EMPLOYEE NAME, as well as the current and
year-to-date payroll and WITHHOLDING AMOUNT figures.
6. Creating unbalanced decomposition (or explosion) in child diagrams. Each child
diagram should have the same input and output data flow as the parent process. An
exception to this rule is minor output, such as error lines, which are included only on
the child diagram.
LOGICAL AND PHYSICAL DATA FLOW DIAGRAMS
A logical data flow diagram focuses on the business and how the
business operates. It is not concerned with how the system will be
constructed. Instead, it describes the business events that take
place and the data required and produced by each event.
Conversely, a physical data flow diagram shows how the system
will be implemented, including the hardware, software, files, and
people involved in the system
Features common to both logical and physical
data flow diagrams
 Developing Logical Data Flow Diagrams
To develop such a diagram, first construct a logical data flow
diagram for the current system. There are a number of advantages
to using a logical model, including:
Better communication with users.
More stable systems.
Better understanding of the business by analysts.
Flexibility and maintenance.
Elimination of redundancies and easier creation of the physical
model.
 Developing Physical Data Flow Diagrams

Advantages physical data flow diagrams have others, including:

1. Clarifying which processes are performed by humans (manual)
and which are automated.
2. Describing processes in more detail than logical DFDs.
3. Sequencing processes that have to be done in a particular order.
4. Identifying temporary data stores.
5. Specifying actual names of files, database tables, and printouts.
6. Adding controls to ensure the processes are done properly
 Partitioning Data Flow Diagrams
There are six reasons for partitioning data flow diagrams:
Different user groups
Timing
Similar Task
Efficiency
Consistency of Data
Security
DFD example
1. Developing
the list of
business
activities
Develop this list
using information
obtained through:
interview　
investigation
observation
2. Creating a context -level Data flow diagram
3. Drawing diagram 0
 4. Creating child diagram

Child diagram processes are

more detailed, illustrating the
logic required to produce the
output
5. Creating a Physical Data Flow
Diagram from the Logical DFD

Physical DFDs provide processes for

scanning bar codes, displaying
screens, locating records, and
creating and updating files.
Partitioning the physical
DFD
Reason for partitioning:
identifying dis- tinct processes
for different user groups
separating processes that
need to be performed at
different times
grouping similar tasks
grouping processes for
efficiency
combining processes for
consistency,
separating them for security.
Partitioning the Web site

Web site designers who use forms

to collect data may find it more
appropriate to divide a Web site
into a series of Web pages, which
will improve the way humans use
the site, the speed of processing,
and the ease of main- taining the
site.
COMMUNICATING USING DATA FLOW DIAGRAMS

To make the diagrams truly communicative

to users and other mem- bers of the project
team, meaningful labels for all data
components are also required. Labels
should not be generic, because then they do
not tell enough about the situation at hand.
All general systems models bear the
configuration of input, process, and output,
so labels for a data flow diagram need to be
more specific than that.
Data flow diagrams can be used for docu-
menting high or low levels of analysis and
helping to substantiate the logic underlying
the data flows of the organizations.
Thank You!
Liceria & Co.