• DFD has no time dimension = does not reflect synchronization / parallel execution of processes
• there are no swimlanes = processes are performed by the system, not by a human 
• imagine inputs from terminators as buttons pressed (or data fields filled-in) in a screen mockup 
• to get more readable diagrams, one terminator may be used more than once 
• processes must be labelled with a name of an activity 
• processes must have at least 1 input and output
• memory is passive part of the system, CRUD operations are applied
• memory is denoted in a diagram only if it is shared by at least two different processes (if it is used only by one, then it should be modeled when this process is decomposed)
• in a context diagram, memory can be denoted only if there is a data  storage  used for communication with other systems
• DFD notation does not natively support inheritance. To illustrate that some function can be triggered by two different actors, a "shared" terminator can be created [Waiter / Cook]
• Processes with only one-way data flows (i.e. all inputs with no outputs, or vice versa) could be in fact terminators
• It is unlikely that DFD would be split into several subgraphs that do not communicate between one another. If this happens in your diagram, you have probably forgotten some data flows or processes.

A process is specified by:

• its own DFD (= decomposition)
• minispecification - for "atomic" processes where it makes no sense to decompose 

This represents the "top-down" approach to create DFDs - as opposed to bottom-up approach via event partitioning.