Data Flow Diagram Visio Template
Once the table is populated, Visio’s wizard helps you complete the remaining steps to transform your Excel data into a Visio process diagram. If you customize the premade template or create one of your own, the wizard helps you map certain flowchart parts, like swim lanes and connectors. This is a Visio template for a Context Level DFD (Data Flow Diagram). A Context Level DFD is often used in system analysis and IT projects to help determine scope. Typically, the name of the project or the system that is being worked on is put into the middle circle.
This article describes the Data Flow Diagram devised by Larry Constantine in the 1970s as part of the Structured Analysis movement. It follows logically from the article in which we used a much simplified Data Flow Diagram to show a proposed system in the context of its external interfaces and actors. Introduction The Data Flow Diagram (DFD) provides a graphical representation of the flow of data through a system.
It shows logically what information is exchanged by our system processes and external interfaces or data stores, but it does not explicitly show when or in what sequence the information is exchanged. Data Flow Diagrams are one of the three essential perspectives of the Structured Systems Analysis and Design Method (SSADM) that predates the more recent object oriented design methods and notations such as UML. This does not mean that the DFD has lost its usefulness even for new analysis endeavors, and any business analyst is bound to encounter them while reviewing the original design documentation for ‘legacy’ systems. Diagram Elements The diagram elements listed below and in the subsequent worked example are based on the Gane-Sarson symbol set (or notation) for Data Flow Diagrams. There are other symbol sets such as Yourdon-Coad, which comprise the same four element types albeit represented using different shapes. This lozenge shape represents a system Process which typically consumes data from an Interface or Data Store (see below), transforms it in some way, and then feeds out the end result.
To an Interface or Data Store. This rectangle shape represents an external Interface, which is any external system or human actor that interacts with our system processes.
In some alternative notations the Interface shape may be known as a Terminator, an Input/Output or an Entity. A Data Flow line shows data flowing from a Process to an external Interface or Data Store, or data flowing from an external Interface or Data Store to a Process. The data flows in the direction of the arrow. A Data Store may represent an entire database or a more specific entity within a database or other persistent data store. While this table of diagram elements is informative, the only way to truly appreciate the role of the Data Flow Diagram is via a concrete worked example. Worked Example The figure below shows a Data Flow Diagram that was drawn in Microsoft Visio using the Gane-Sarson symbol set. A good Data Flow Diagram should be easy to comprehend and intuitively obvious to the lay person; ideal for reviewing with non-technical project stakeholders.
So take time to interpret the diagram yourself, and then read the description that follows. This worked example DFD comprises five processes, four external interfaces / actors, and two data stores.
It is not meant to be an exhaustive representation of the data flows in a banking system, but sufficiently comprehensive to give a good feel for how a DFD might be constructed A Bank Manager actor provides New account details to the Open Account process which results in Customer details being persisted in the Customer Database data store and Account details being persisted in the Account Database data store. Although we have used the phrase ‘results in’ as part of this explanation, the DFD implies no such cause and effect; all it shows is that the Open Account process can read in data from the Bank Manager interface and write out data to the Customer Database and Account Database data stores in no particular order. A Customer actor using the Online Banking Login process must provide some data in the form of a set of Login credentials such as a user name and password. A Customer actor can receive a Money amount from the Withdraw process and can supply a Money amount to the Deposit process; in either case causing (although this causation cannot be explicitly modeled) an Account balance update to the Account Database data store.
A Customer actor can initiate the Transfer Funds process, to which he or she must provide an Account destination and money amount. The Transfer Funds process can send a Money amount to another bank via the Other Bank interface. Just like the Customer actor, a Third Party actor can make use of the Deposit process (but obviously not the Withdraw process) by supplying a Money amount. Tips and Tricks Although our focus is on computer systems and software implementations, the DFD has wider uses in modelling non-computerised company processes and exchanges of information. The abstract symbol set could be used to model manual processes and physical data stores such as a filing cabinet. But we’re computer analysts, right? Data flows between external interfaces and data stores should not be shown, for the simple reason that these are considered to be external and ‘out of scope’.
The analyst should have no knowledge of the interconnections between external entities. Notice how in the worked example, when modeling the data flow from the Customer to the Login process we chose to label the data flow with the phrase Login credentials rather than (for example) username and password. This gives us some flexibility in defining elsewhere what the required login credentials are without invalidating the diagram.
In the future we may require the customer to supply an email address and PIN in order to log in. Note, however, that this is a personal preference and some analysts may prefer to be absolutely explicit when labeling data flows.
Data Flow Diagram Visio Template Pdf
The external interfaces and actors in this DFD correspond with those shown on the Context Diagram in the previous article, so all we have really done here is to decompose the all-encompassing Bank System process from the Context Diagram into a set of internal processes for specific tasks. We have defined these processes with a view to making each one a discrete use case on a UML Use Case Diagram, with each data flow between an Interface and a Process in this diagram suggesting an association between an Actor and a Use Case. This is not obligatory and is merely a suggestion for aiding traceability between the various systems analysis diagrams and artifacts. The DFD might also drive the creation of another UML diagram: the UML Activity Diagram which would show the order in which the Processes - to be re-branded as Activities - would be performed. This would resolve the problem of the DFD show what data is exchanged but not when. Next Stop: the Entity-Relationship Diagram The Data Flow Diagram focuses on the data that flows between system processes and external interfaces, and alludes to the fact that some data are persisted in data stores.
The data store that has ‘persisted’ (pun intended) for longest, i.e. Has stood the test of time, is the relational database. So in the next article we’ll look at how to model a relational database structure using an Entity-Relationship Diagram. Author: Tony Loton - Author & Self-Publisher As a former IT consultant and consultancy practice manager, Tony has published many IT feature articles and books including the most recent 'UML Software Design with Visual Studio 2010'.
Tony: It is important that BA's understand the very unique powers of Data Flow Diagrams in deciding whether to use DFD's, BPMN, or any other process/functional modleing technique. Only DFD's have a built in mechanism to lead to a logical, natural partitioning (decomposition) of a system. This, basically, is provided via the BA following the DFD 'interview the data' approach in which he/she follows data flows as they naturally converge and diverge to discover essential processes/functions upon which a proper decompostion are based. Only DFD's have a buil- in 'litmus test of completedness': With DFD's, when the data flows do not 'hook together', or come from or go to no where, it is very obvious that something is amiss. Systems at high levels of abstraction are very non-sequential.
Sequentially based techniques, like BPMN, can not be used to model non-sequential systems. Only DFD's offer an Agile approach to big picture analysis. While Agile is about minimal documentation, it is also about quality documentation. Some high level DFD's (forget about written text), that strongly focus on the essitials (i.e., the data flows), provide the vehicle for minimal yet quality (i.e., capture the essentials) requirements specs.
Maiti: I have in the past tried to find such on-line. I have also done a significant amount of review of literature. Unfortunately, all the current on-line and book literature that I have seen about DFD's is very immature. There is a alot of discussion about what the circles or lines mean,and maybe a brief mention of decomposition, but that is about it. I have found nothing in recent writings about, for example, the importance of and how to proceed in a logical, natural partioning (and conversely nothing about how poor man DFD techniques such as Use Cases and User Stories lead to forced, artificial partitioninig).
You may have to go back to Structure Analysis and System Specification by Tom DeMarco (70's) for an intelligent discussion on partitioning, the non-sequential nature of systems, the need for litmus test of completedness, etc, etc. Tom's friend Ed Yourdon also had some good writings. I learn about effective partitioning, etc.
By tacking a Yourdon course using the DeMarco book and planned lessons. It was a good read, I am currently at university and we have to use Structured Analysis for our specifications. The thing I would like to point out in a more commercial sense is that processes should be numerated so that you can drill down into them.
Data Flow Diagram Visio Template Word
The above example is a good example of a DFD Level 0 Diagram. Except on a personal bias, I don't like bridges in diagrams it shows up as a mess. Also I like to put verb actions to my processes so that you know what is supposed to be happening. Cheers Anthony.