1) Understand the system. Develop this understanding by observing organization data flows, observing and interviewing those who use and process the data or having them complete a questionnaire; by reading a narrative description of the system; or by walking through system transactions
2) Ignore certain aspects of the system. A DFD is a diagram of the origins, flow, transformation, storage, and destinations of data. Only very important error paths are included; unimportant error paths are ignored. Determining how the system starts and stops is not shown
3) Determine system boundaries. Determine what to include and exclude. Include all relevant data elements, because excluded items will not be considered during system development
4) Develop a context diagram. A context diagram depicts system boundaries. In the diagram's center is a circle with the name of the system. Outside entities circle with the name of the system. Outside entities the system interacts with directly are in boxes on either side, connected by data flows depicting the data passed between them. DFDs in successively more detail depict data flows inside the system
5) Identify data flows. Identify all data flows (significant movement of data) entering or leaving the system, including where the data originate and its final destination. All data flows come from and go to a transformation process, a data store (file), or a source or destination. Data flows can move in two directions, shown as a line with arrows on both ends
6) Group data flows. A data flow can consist of one or more pieces of datum. Data elements that always flow together should be grouped together and shown as one data flow until they are separated. If the data do not always flow until they are separated. If the data do not always flow together, show them as separate data flows.
7) Identify transformation processes. Place a circle wherever work is required to transform one data flow into another. All transformation processes should have one or more incoming and outgoing data flows.
8) Group transformation processes. Transformation processes that are logically related or occur at the same time and place should be grouped together. Do not combine unrelated items into a single transformation process. If data are not processed together, or are sometimes processed differently, separate them.
9) Identify all files or data stores. Identify each temporary or permanent data repository, and identify each data flow into and out of it
10) Identify all data sources and destinations. Include them on the DFD
11) Name all DFD elements. Except for data flows into or out of data stores (the data store name is usually sufficient to identify the data flow), data elements should be given unique and descriptive names representing what is known about them. Naming data flows first forces you to concentrate on the all-important data flows, rather than on the processes or stores. Processes and data stores typically take their names from the data inflows or outflows. Choose active and descriptive names, such as "update inventory" and "validate transaction," rather than "input data" or "update process." Process names should include action verbs such as update, edit, prepare, reconcile, and record.
12) Subdivide the DFD. A cluttered DFD is hard to read and understand. If you have more than five to seven processes on a page, decompose the context diagram into high-level processes. Explode these high-level processes into successively lower-level processes.
13) Gives each process a sequential number. Giving each process a sequential number (lower to higher) helps readers navigate among the DFD levels.
14) Refine the DFD. Work through data flows several times. Each subsequent pass helps refine the diagram and identify the fine points. Organize the DFD to flow from top to bottom and from left to right
15) Prepare a final copy. Do not allow data flow lines to cross each other; if necessary, repeat a data store or destination. Place the name of the DFD, the date prepared, and the preparer's name on each page.
Basic Guidelines for creating a DFD
-Understand the system that you are trying to represent
-A DFD is a simple representation meaning that you need to consider what is relevant and what needs to be included
-Start with a high level (context diagram) to show how data flows between outside entitites and inside the system. Use additional DFD's at the detailed level to show how data flows within the system
-Identify and group all the basic elements of the DFD
-Name data elements with descriptive names, use action verbs for processes (e.g., update, edit, prepare, validate, etc.)
-Give each process a sequential number to help the reader navigate from the abstract to the detailed levels
-Edit/Review/Refine your DFD to make it easy to read and understand
DOCUMENT FLOWCHARTS were developed to illustrate the flow of documents and data among areas of responsibility within an organization. They trace a document from its cradle to its grave, showing where each document originates, its distribution, its purpose, its disposition, and everything that happens as it flows through the system.
An INTERNAL CONTROL FLOWCHART, a special type of flowchart, is used to describe, analyze, and evaluate internal controls. They are used to identify system strengths, weaknesses or inefficiencies, such as inadequate communication flows, insufficient segregation of duties, unnecessary complexity in document flows, or procedures responsible for causing wasteful delays
A SYSTEM FLOWCHART depicts the relationships among system input, processing, storage, and output. System flowcharts are used to describe data flows and procedures within an AIS
A PROGRAM FLOWCHART illustrates the sequence of logical operations performed by a computer in executing a program. A program flowcharts describes the specific logic used to perform a process shown on a system flowchart
1) Understand the system. Develop this understanding by interviewing users, developers, and management or having them complete a questionnaire; by reading a narrative description of the system; or by walking through system transactions
2) Identify the entities to be flowcharted. Identify departments, job functions, and external parties. Identify business processes, documents, data flows, and data processing procedures.
3) Organize flowchart. Design the flowchart so that data flows from top to bottom and from left to right. Where appropriate, ensure that all procedures and processes are in proper order. Show where documents or processes originate, where data is processed, and where data is stored and sent. Show the final disposition of all documents to prevent loose ends that leave the reader dangling. Show data entered into or retrieved from a database as passing through a processing operation (a computer program) first. In document flowcharts, divide the flowchart into columns with labels
4) Clearly label all symbols. Write a description of the source, input, process, output, or destination inside the symbol. Use arrowheads on all flow lines
5) Page connectors. If a flowchart cannot fit on a single page, clearly number the pages and use off-page connectors to move from one page to another. Where desired, on-page connectors can be used to avoid excess flow lines and to produce a neat-looking page. Clearly label all connectors to avoid confusion.
6) Draw a rough sketch of the flowchart. Be more concerned with capturing content than with making a perfect drawing. Few systems can be flowcharted in a single draft. Review it with the people familiar with the system. Make sure all uses of flowcharting conventions are consistent.
7) Draw a final copy of the flowchart. Place the flowchart name, date, and preparer's name on each page
Guidelines for Drawing Flowcharts
-Understand the system you are trying to represent
-Identify business processes, documents, data flows, and data processing procedures
-Organize the flowchart so as it reads from top to bottom and left to right
-Name elements descriptively
-Edit/Review/Refine to make it easy to read and understand