Hello! Welcome to the next lesson in our Business Analysis course.
In our previous lesson, we learned how to create use case diagrams to define a system's functionality from a user's perspective. We focused on the actors and the goals they could achieve. This helped us answer the question: "What will users do with the system?"
Today, we shift our focus from functionality to data. This lesson will teach you how to develop a Level 0 Data Flow Diagram (DFD), also known as a Context Diagram, to define system boundaries. While a use case diagram shows what a system does, a context diagram shows what data flows into and out of it. It provides a high-level, "bird's-eye view" of the system's place in its environment, making it an essential tool for clarifying project scope with stakeholders.
What is a Context Diagram?
A Context Diagram is the simplest form of a Data Flow Diagram. Its goal is to show the entire system as a single process and to illustrate all the interactions it has with the outside world. This is why it's so powerful for defining scope—it draws a clear line between what is inside our system and what is outside.
It's also called a Level 0 DFD. This is because it represents the highest, most abstract level of data flow. More detailed diagrams (Level 1, Level 2, etc.) can then be created to "explode" the single process and show the internal data flows, but the Context Diagram is always our starting point.
A Context Diagram has three simple components:
- The System (Process 0): A single circle or rounded rectangle in the center that represents the entire system you are analyzing.
- External Entities: Rectangles representing the people, organizations, or other systems that send data to or receive data from your system. These are often the same as the "actors" from your use case diagrams.
- Data Flows: Labeled arrows that show the information being passed between the external entities and the system.
Here is a classic example for an Online Banking System.

To get a more formal understanding of these components, let's turn to a video resource.
Data Flow Diagram EXAMPLE [How to Create Data Flow Diagrams]
This video from The Business Analysis Doctor provides a clear overview of Data Flow Diagrams and their core components. It will help formalize the concepts we've just introduced.
Watch from 01:10 to 06:02. Pay close attention to the definitions of External Entities, Processes, Data Stores, and Data Flows. Note that for a Context Diagram, we only use three of these: External Entities, a single Process (the system itself), and Data Flows. Data Stores are introduced in lower-level diagrams.
Context Diagram vs. Lower-Level DFDs
It is crucial to understand that the Context Diagram (Level 0) is a high-level summary. Its purpose is to define boundaries. A Level 1 DFD, by contrast, "decomposes" or "explodes" the single system process into its main sub-processes. It shows how data moves between these internal processes and introduces Data Stores (repositories where data is held, like a database).
- Context Diagram (Level 0): One process bubble. Shows data flowing in and out of the system. No data stores.
- Level 1 DFD: Multiple process bubbles (e.g., 1.0, 2.0, 3.0). Shows data flowing between internal processes. Introduces data stores.
Let's see this distinction explained visually.
Data Flow Diagram EXAMPLE [How to Create Data Flow Diagrams]
Let's return to The Business Analysis Doctor video to see how a Context Diagram is 'exploded' into the next level of detail. The video confusingly calls this next level 'Level 0', but in standard practice it's often referred to as Level 1. The key concept is the decomposition.
Watch from 06:13 to 07:28, and then jump to the example from 12:45 to 14:12. Notice how the single 'Purchase Product System' process from the Context Diagram is broken down into four main processes in the more detailed diagram, and how data stores like 'User Details' appear.
This lesson focuses only on creating the Context Diagram, the essential first step.
How to Build a Context Diagram
Creating a Context Diagram involves a straightforward, three-step process.
- Identify the System: Draw a single process shape in the center of your page and label it with the name of the system you are analyzing.
- Identify External Entities: Ask yourself, "Who or what provides information to the system or receives information from it?" These are your external entities. Place them around the central system process.
- Identify Data Flows: For each entity, determine the specific data it sends to the system and receives from it. Draw and label arrows to represent these data flows. The arrow's direction indicates if the data is an input or an output.
This short tutorial provides a practical demonstration of these steps.
How to create a Context-level Data Flow Diagram (DFD)
This video from Degan Kettles provides an excellent, practical walkthrough of creating a Context Diagram for a 'Hiring System'.
Watch from 00:58 to 05:01. Observe how the creator first identifies the central system, then the external entities ('Applicant', 'Engineering Manager'), and finally maps the specific data flows between them ('job description', 'application', 'interview schedule').
Applying it to your AdTech Background
Let's connect this to your experience. The programmatic advertising ecosystem is a complex network of systems exchanging data. A Context Diagram is a perfect way to model it.
Imagine we are creating a Context Diagram where the central system is the Ad Exchange (the marketplace where ad impressions are bought and sold in real-time).
- System: Ad Exchange
- External Entities:
- Demand-Side Platform (DSP): The system used by advertisers to buy ad inventory.
- Supply-Side Platform (SSP): The system used by publishers to sell ad inventory.
- Advertiser: The company that wants to place ads.
- Publisher: The website or app with ad space to sell.
- Data Flows:
- The SSP sends a
Bid Requestto the Ad Exchange. - The Ad Exchange forwards the
Bid Requestto the DSP. - The DSP sends back a
Bid Response(including the price and the ad creative). - The Ad Exchange notifies the SSP of the winning bid.
- The SSP tells the Publisher's website to display the
Ad Creative.
- The SSP sends a
The diagram below shows a slightly more detailed version of this ecosystem. You can see how it visually represents the flow of information between different parties, which is exactly what a Context Diagram aims to do.
Test your understanding!
You are the Business Analyst for a project to build a new 'ExpressEats' online food delivery platform. The system needs to interact with Customers, Restaurants, and Delivery Drivers.
Based on this scenario, create a basic Context Diagram by listing:
- The name of the central System.
- The three External Entities.
- For each entity, identify at least one data flow into the system and one data flow out of the system.
Show answer
- System: ExpressEats Platform
- External Entities: Customer, Restaurant, Delivery Driver
- Data Flows:
- Customer:
- Input:
Food Order,Payment Details - Output:
Order Confirmation,Restaurant Menu
- Input:
- Restaurant:
- Input:
Menu Updates,Order Acceptance - Output:
New Order Notification
- Input:
- Delivery Driver:
- Input:
Delivery Confirmation,Current Location - Output:
Delivery Assignment,Customer Address
- Input:
- Customer:
Conclusion
In this lesson, you've learned how to create a Context Diagram (or Level 0 DFD). This is a foundational BA technique used early in a project to establish the system's scope by clearly defining its boundaries and high-level data interactions. It perfectly complements the use case diagram by shifting the perspective from user functions to data flows.
Key Takeaways:
- A Context Diagram shows an entire system as a single process, defining its boundaries.
- It visualizes the data flows between the system and the external entities it interacts with.
- It answers the question, "What data enters and leaves the system?" and is the highest-level view in a set of Data Flow Diagrams.
Preview of the Next Lesson:
We've now defined our system's functional scope (with use cases) and its data boundaries (with the context diagram). The next logical step is to start looking inside the system's processes. In our next lesson, we will explore how to model business rules using decision tables or decision trees, a technique for clearly specifying the logic a system uses to make decisions.