How does a DFDer properly partition a system?
Key Concepts: What works in partitioning a system at the detail level most often does not work at higher levels of abstraction. And in order to properly partition at the detail level, the analyst first needs to properly partition the system at the higher levels.
Let me at this point, as best as I can remember, restate how Ed Yourdon (or was it Tom DeMarco?) said partitioning at higher levels of abstraction should be done: By following the flows of data like rivulets of water flowing down a pane of glass. When the flows of data naturally combine (like rivulets of water flowing down glass have a tendency to do), the business analyst has identified a logical function/process, as some process is necessary to accomplish the merging of the data. Likewise, when a flow of data naturally splits apart, the analyst has flushed out a logical function necessary to accomplish the splitting.
Also per Yourdon: When a function/process has a more than a total of about five (5) inputs and/or outputs, it is a 'dead ringer' that it needs to be split apart. Such functions are called "functional spiders", and, if a diagram has functional spiders, it soon becomes impossible to understand it. And if the diagram is not understandable, it will be impossible to properly proceed with further analysis.
Comparing the DFD approach with the more common approach that Guy B. presented in his last posting:
Top level processes: It would seem that top level processes are easy to identify. However, it has been my experience that a usable Context diagram (a data flow diagram where the entire system is displayed as a single high-level process), is very rare. I once worked at a very large company that promoted and taught Context diagrams to everyone short of the janitors. End result, across dozens of requirements specifications efforts that I evaluated: 0 (zero) Context diagrams. Present party excluded of course :-)
Guideline of mutual dependency: Basically, this is partitioning according to sequencing considerations (example: when function A always happens in sequence with function B, combine them). But, how can a business analyst use sequencing to partition at higher levels? At a higher level, especially for a larger scale system, there is most often many things going on at the same time. In such cases, trying to partition according to sequencing considerations does not work - there is no sequence. Yourdon referred to this phenomenon as the "asynchronous" nature of information systems.
Also, what if function A and function B, even though they always happen at the same time, have entirely different inputs and outputs? Combining them may very well result in a functional spider. Again, with functional spiders, the analyst soon reaches a point where things are too confusing to understand what is going on.
Guideline of initiation and outcome linkage: Again, at other than the detail level, Process A is properly split apart based upon its number of inputs and outputs. Partitioning based on sequencing considerations is for the detail level.
Guideline of user concurrency: As I read it, this is combining processes/functions to avoid having the work wait in queue. While eliminating queues is a valid goal, the analyst needs to look at the inputs and outputs of each process. If combining them will result in a functional spider, then something other than a simple combination is required.
Guideline of meaningfulness: If a process does not produce any meaningful output, a DFDer would definitely not combine it into another process. He/she would document it on a diagram as a process without outputs - making it stick out like "a sore thumb" as something that needs to be addressed.
Guideline of unit of work: Splitting a process into two for efficiency reasons is a very good thing. After the analyst has partitioned the system logically and so that there are no functional spiders, this can be done.
Guideline of conciseness of specification: Good recommendation: If the analyst needs more than a page of specification for a function, then split it up. Of course the way to avoid functions that are to big is to avoid functional spiders.
Guideline of transaction steps: I agree that simple processes, like one step processes, should be combined into other processes.