The data flow diagram is a useful, low-level data model that can show how data is transformed and manipulated through processes. This model does NOT show decisions, nor does it show a sequence of processes. This tutorial will take a commonly understood real-world scenario, a round of Texas Hold ‘Em, and provide step-by-step instructions for how to create this model. If you are unfamiliar with how the game of Texas Hold ‘Em works, check out this About.com article with step-by-step instructions.

Identify Business Data Objects
The first step in knowing modeling changing data objects is to identify the important data objects that will change. Start by creating a BDD, the highest level data model, to show the relevant data objects of your system and how they relate. Below is the BDD created for the Texas Hold ‘Em scenario. In this model, I’ve also included data stores, which are essentially unique combinations of data objects, identified with a different color (green). This way, we can start with an understanding of not only which data objects get passed, but where they might end up.

Identify Processes
Once data objects have been identified, reference process flows and system flows to find process steps where identified objects are created, updated, deleted, used, moved, or copied. Below is a simplified L2 process flow for a single round of Texas Hold ‘Em. It is important to understand that not every single process with a data flow should be modeled. Try and select the most important, thematic processes to model, instead of creating a DFD for every step in your flow. In this example, there are really three major processes that happen in the round: dealing cards, placing bets, and awarding the win.

Identify External Entities
Typically you would reference ecosystem maps to find related systems and org charts to find individuals or roles that manipulate the data. In this relatively simple example, we can easily brainstorm a list of entities that will touch the data: players and dealers. We already have a list of data stores identified in the BDD. The only additional conceptual data store we might consider including is the Hierarchy of Hands, or the rules that dictate which combinations of cards beat others.

Tie the Diagram Together
If you are unfamiliar with the DFD symbols and notations, reference this chart of elements and meanings from Beatty and Chen’s Visual Models for Software Requirements book.

Now that the data objects, data stores, external entities and processes have been identified, it’s a matter of pulling them all together using the DFD model notation.