If I want to show the flow of data through a system for adding a new customer record, would the data flow diagram (DFD) suit my needs?  Are external entities required?  I've seen examples of data flow diagrams with arrows all over the place which I find visually unappealing.  Is there a preferred DFD style among BAs?

Thanks in advance,

Larry

Larry:

Data flow diagrams are of course appropriate for showing data flows.   Does anything else show the flow of data?   Exteneral (to the system) entities are typcially considered when scoping out a project.   For scoping, a special kind of data flow diagram called a Context diagram is used to document the flow of data between external entities and the system.  

If you have seen data flow diagrams with arrows all over the place, you have seen diagrams that need to be redrawn.   Functional spiders are common  (i.e., one process with a whole bunch of inputs and outputs.)   These spiders need to be busted up (repartitioned in dfd lingo) so that no process (function) has no more than about 5 input and outputs in total.   Another common problem is real big hunker diagrams.   These diagrams need to be redrawn into a parent-child set with no more than about 7 processes (functions) per diagram.

Is there a preferred DFD style among BAs?    Circles vs squares is just cosmetic.   Parent child layering is essential.   Properly constructed dfd facilitate end-user reviews.   Poorly construction ones (i.e., complex looking ones) hinder the review cycle.

Tony

Adrian,

that's my conundrum - most examples include processes like 'compute total' or 'look up such and such'.  I'm interested in showing the flow of data as far as which tables it hits and required fields/types of info.  For example, the data entered will differ if I enter  spouse info (different table).  How will the DFD look?

Thanks,

Larry