Data Flow Diagram (DFD) Tutorial: Texas Hold ‘Em

ArgonDigital - enterprise automation experts

Share This Post

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 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.

Texas Hold 'Em BDD

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.

Texas Hold 'Em Process Flow

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.DFD Symbols

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.

Texas Hold 'Em DFD

More To Explore

Defining requirements and specifications

Defining Requirements and Specifications

Why Defining Requirements and Specifications is Important I have been asked this question, or some variation of it, many times. This question is akin to