| Once you have established the hierarchical structure of a business's activities (functions and processes), you can determine which activities are dependent on which other activities. That is, to perform an activity, what other activities must be done first? Because sequence is implied , a dependency diagram is about activities as processes, rather than as functions, although these processes may or may not be technologically neutral. There are three ways one process may be dependent upon another: -
Resource dependency a process produces a tangible resource that is required before another process can be executed. For example, "Ship ordered materials" cannot occur until "Pick ordered materials" has been done. This only applies to resource-handling processes. -
Data dependency a process requires data that is produced by another process. For example, "Issue purchase order" cannot be done until after "Receive requisition ". -
Constraint dependency a process depends on a constraint that was set in another process. For example, "set up production" determines whether "produce widgets" or "produce gadgets" is performed. This should be avoided, because it implies too great a coupling between the two activities. It would be better for the first process to pass data to the second process for it to act upon. There are various ways of drawing dependency diagrams. A typical version is presented by Carma McClure and James Martin in their 1985 book, Diagramming Techniques for Analysts and Programmers , and is shown in Figure 4.3. Figure 4.3. Dependency Diagram.  Ms. McClure and Mr. Martin have elaborated on the basic concept of a dependency diagram with some annotations [McClure and Martin, 1985, pp. 8385]. A solid dot next to one end or the other means the process is optional. As shown in Figure 4.4, if it is next to the first process, it means that one may or may not be followed by the other. If it is next to the second, then the first process may or may not be the cause of the second's happening. Figure 4.4. Optionality in a Dependency Diagram.  It is also possible to identify the cardinality of occurrences of processes. Figure 4.5 shows examples where each occurrence of the second process may be preceded by one or more occurrences of the first process (upper diagram) and each occurrence of the first process may be followed by one or more occurrences of the second process (lower diagram). Figure 4.5. Cardinality in a Dependency Diagram.  It is common for dependencies to branch. A process may be followed by numerous other processes, or a process may be dependent on one or more processes. These situations are all shown in Figure 4.6. Note that no sequence is implied for the activities that follow "Receive a book shipment". Figure 4.6. Branching in a Dependency Diagram.  | 
