A Data Flow Diagram is intended to depict how the business system will work, not how any particular computer system will work.
The Context Data Flow Diagram defines the scope of a business system. It's critical that we reinforce, often, the fact that data flows illustrate business systems, not computer systems. Many of the sites that are failing today with their data flow efforts are drawing system flows and calling them data flows.
A Context Data Flow Diagram shows the flow of data in and out of the process that is the target of analysis. It sets the context in which analysis will be carried out.
3-Step Process for Context
A Context Data Flow Diagram shows the flow of data in and out of the process that is the target of analysis. All data originates at external agents, passes through the context process, and terminates at external agents.
The process we invent becomes the root of an implicit process decomposition diagram that uses the flow of data as the criterion of decomposition.
We need a process in place to assure that the Context Data Flow Diagram is correct. Historically, analysis projects have gone about defining their scope backwards. We've traditionally identified the process first, and then gone after the inputs and outputs. The flaw in this approach is that it presumes that the scope is understood well enough a priori to be able to go after the inputs and outputs. This is why defects-of-omission are so common in requirements.
In this class, we teach the reverse. Always start with the target of analysis least understood, and least within project control. At the context level, it's the external agents. We start by identifying external agents. Much of this can be done intuitively, much can't.
If an ISP has been done there should be plenty of information on the interaction of organizations and functions to support this activity. Looking at the user, or sponsor, organization for the project also usually highlights one or more external agents.
We next describe the data flowing to, and from, each external agent. This activity forces us to justify each external agent and discuss the role each has to play in the project scope. We need to be able to identify an input from, and output to, each external agent. If we can't, we probably don't fully understand that agent's role, and hence our scope.
The last thing we do is invent the context process. This step is mechanical. Warn students not to put to much weight in the name of this process. Names usually tell you more about the analyst's bias toward something than anything real about the it. This isn't just true about context processes, but about every piece of the process model.
Many projects have failed to understand their scope precisely because to much weight was given to the perceived name of the context process. For example, take the fairly classic case of an Order Processing project. Once named, the name quickly biases the analysis effort. Clearly external agents will include Customer because it's their order. We'll probably also spot the Warehouse, since that's where order are shipped from. But we may miss Accounting, where invoices and payments for orders are handled, and from which we get customer credit information. We'll probably miss the Government, which tells us about taxation and various regulations needed in the processing of customer orders.
These are all things that will eventually be spotted in any project. Worst case, the programmers stumble across them. What we're trying to get across here is an attitude which causes them to be discovered immediately.
Three simple steps...Context Data Flow Diagram