Striker

The model generally starts with a context diagram showing the system as a single process flowchart connected to external entities outside of the system boundary. This process explodes to a lower level DFD that divides the system into smaller parts and balances the flow of information between parent and child diagrams. Many diagram levels may be needed to express a complex system.

The Data Flow Diagram is an excellent communication tool for analysts to model processes and functional requirements. The analyst should be a critical thinker to use it effectively, it is a useful and easy to understand modeling tool. It has broad application and usability across most software development projects. It is easily integrated with data modeling, workflow modeling tools, and textual specs. Together with these, it provides analysts and developers with solid models and specs. Alone, however, it has limited usability. It is simple and easy to understand by users and can be easily extended and refined with further specification into a physical version for the design and development teams.

Purpose/Objective:

The purpose of data flow diagrams is to provide a semantic bridge between users and systems developers. The diagrams are:

•graphical, eliminating thousands of words;

•logical representations, modeling WHAT a system does, rather than physical models showing HOW it does it;

•hierarchical, showing systems at any level of detail; and

•jargonless, allowing user understanding and reviewing.

The goal of data flow diagramming is to have a commonly understood model of a system. The diagrams are the basis of structured systems analysis. Data flow diagrams are supported by other techniques of structured systems analysis such as data structure d iagrams, data dictionaries, and procedure-representing techniques such as decision tables, decision trees, and structured English.

Data flow diagrams have the objective of avoiding the cost of:

•user/developer misunderstanding of a system, resulting in a need to redo systems or in not using the system.

•having to start documentation from scratch when the physical system changes since the logical system, WHAT gets done, often remains the same when technology changes.

•systems inefficiencies because a system gets "computerized" before it gets "systematized".

•being unable to evaluate system project boundaries or degree of automation, resulting in a project of inappropriate scope.

Analyzing the Current Processes

Data flow analysis work is often difficult due to the sheer complexity of the processes involved. It is easy for the analyst to become overwhelmed. To prevent this, we use a two-step process to understand the situation:

•A focus on the physical data flows. This means observing the process as a savage would, with no focus on the logic behind, or information on, a particular piece of paper (or contained in a conversation or email).

•A focus on the conceptual data flows. This process can only begin after the physical data flow documentation is complete, since it analyzes the conceptual essentials behind the physical data flow.

Procedure

The procedure for producing a data flow diagram is to:

1. identify and list external entities providing inputs/receiving outputs from system;

2. identify and list inputs from/outputs to external entities;

3. create a context diagram with system at center and external entities sending and receiving data flows;

4. identify the business functions included within the system boundary;

5. identify the data connections between business functions;

6. confirm through personal contact sent data is received and vice-versa;

7. trace and record what happens to each of the data flows entering the system (data movement, data storage, data transformation/processing)

8. attempt to connect any diagram segments into a roughdraft;

9. verify all data flows have a source and destination;

10. verify data coming out of a data store goes in;

11. redraw to simplify--ponder and question result;

12. review with "informed";

13. explode and repeat above steps as needed.

Context Diagram Guidelines

Firstly, draw and name a single process box that represents the entire system. Next, identify and add the external entities that communicate directly with the process box. Do this by considering origin and destination of the resource flows and data flows. Finally, add the resource flows and data flows to the diagram.

In drawing the context diagram you should only be concerned with the most important information flows. These will be concerned with issues such as: how orders are received and checked, with providing good customer service and with the paying of invoices. Remember that no business process diagram is the definitive solution - there is no absolute right or wrong.

Reference:

http://www.edrawsoft.com/Data-Flow-Diagrams.php
http://spot.colorado.edu/~kozar/DFDtechnique.html
http://danang.files.wordpress.com/2006/07/8dfd.pdf