A data flow diagram is a graphic representation of
a system or portion of system. It consists of data
flows, processes, sources, destinations, and stores
– all described through the use of easily understood
symbols. An entire system can be described from the
viewpoint of the data it processes with only four
symbol. At the same time, data flow diagrams are powerful
enough to show parallel activities. When standard
symbols limit communication, a presentation graph,
which uses symbols of people, files, terminals, and
documents, can be used to discuss a system with users.

A data flow diagram are of two types :

· Physical Data flow diagrams
· Logical data flow diagrams.

Physical data flow diagrams are implementation-dependent.
They show the actual devices, department, people,
etc., involved in the current system.
Logical data flow diagrams, in contrast, describe
the system independently of how it is actually implemented;
that is, they show what takes place, rather than how
an activity is accomplished.
Both types of data flow diagrams support a top-down
approach to systems analysis, whereby analysts begin
by developing a general understanding of the system
and gradually explode components in greater detail.
As details are added, information about control can
also be included, although upper-level general diagrams
are drawn without showing specific control issues
to ensure focuses on data and processes.

Rules for drawing Logical Data Flow Diagrams
:

Any data flow leaving a process must be based on
data that are input to the process.

All data flows are named; the name reflects the
data flowing between processes, data stores, sources,
or sinks.

Only data needed to perform the process should
be an input to the process.

A process should know nothing about, that is, be
independent of, any other process in the system, it
should depend only on its own input and output.

Processes are always running, they do now start
or stop. Analysts should assume that a process is
always ready to function or perform necessary work.

Output from processes can take one of the following
forms :

a. An input data flow with information added by
the process (for example, an annoted invoice)
b. A response or change of data form (such as change
of profit dollars into profit percentage)
c. Change of status (from unapproved to approved
status)
d. Change of content (assembly or separation of
information contained in one or more incoming
data flows)
e. Change in organization (for example, the physical
separation or rearrangement of data)

When
beginning a systems study in an unfamiliar area, you
need to get the lay of the land. Physical elements
stand out first: the people, reports and documents,
file cabinets and in-baskets, and events. It’s
not unusual to remember certain key people or places.
Physical data flow diagrams depict these physical
elements.

Once you have the lay of the land, the essentials
of a task can be studied more carefully. You need
to get below the surface, so to speak. That’s
what logical data flow diagrams are all about.

Logical data flow diagrams describe data, processes,
and events differently. They are more abstract than
physical data flow diagrams, but that difference is
important. As an analyst, you have to know more about
the job that must be done than the people who are
actually doing the work. This doesn’t mean that
people are not important, for they surely are. But
if a key worker becomes ill or chooses to leave the
company, the work will remain. Desks, files and computers
will change, too. By focusing on the understanding
elements – the logical, nonphysical aspects
– you gain an understanding of the fundamental
structure of the system. Only then can you develop
a complete understanding and form a basis for designing
the right system.

Use
Case Report :

A user case diagram shows you some of the use cases
in your system, some of the actors in your system,
and the relationships between them. A use case is
a high- level piece of functionality that the system
will provide. An actor is anyone or anything that
interacts with the system being built.

In
the above diagram, there are three actors: the customer,
the bank officer, and the credit system. There are
six major pieces of functionality the system will
provide: depositing funds, transferring funds, withdrawing
money, changing a PIN, viewing a balance, and making
a payment.

One of the major benefits of a Use Case diagrams is
communication. Your customers can look at this diagram
and receive a great deal of information. By looking
at the use cases, they will know what functionality
will be included in the system. By looking at the
actors, they will know exactly who will be interfacing
with the system. By looking at the set of use cases
and actors, they will know exactly what the scope
of the project will be. This can help them identify
up front any missing functionality.