Context Diagram Explained: Draw Your Scope in One Picture (Full Example)
"Just build a returns portal." How big is that? A context diagram answers it in one picture. In this video I take one vague request from a made-up online shop and draw its context diagram: the 3 parts (the system as one bubble, the outside parties, the data flows), 5 steps to draw it, the finished diagram built in draw.io, how it becomes your in and out of scope list, and the 5 mistakes to avoid.
Step by step
A context diagram hides the inside
- A context diagram does not show how a system works inside. It draws the whole system as one closed circle, then shows everything around it: the people, teams and systems that send it data or get data from it. It answers one question: where does our system end?
Explain like I'm 5: the front door
- Think of your home seen from the street. You don't draw the rooms, only the front door and who comes to it: the postman, the pizza driver, the bin truck. The circle is the house, the outside parties are the visitors, and the arrows are what they bring or take away.
Where it sits in BABOK: scope and data flows
- In the BABOK Guide it fits in 2 places. It is a classic scope model, showing what is in and out. In data flow diagrams it is the top level: the whole system as one process, with the outside parties around it. Lower levels open the circle.
Before you draw: three lists
- Before you draw, write 3 lists: one sentence on what the system is for, everyone who might touch it (customers, warehouse, courier, finance, customer service), and the systems you already have, like the order system and the payment provider.
The vague request
- The example: an online shop's sales manager says "just build a returns portal". Does the portal pay the refund? Does it book the courier? Does it replace the order system? Nobody can say, so nobody can plan, price or test it. It's a wish, not a scope.
Part 1: the system, one circle
- Part 1 is the system: one circle in the middle, and only one, labelled Returns portal. Every screen, rule and database stays hidden inside. Name it after the system, not a team: Returns portal, not the returns team.
Part 2: the outside parties
- Part 2 is the outside parties, called external entities in data flow diagrams. Each is a box: a person (customer), an organisation (courier), a team in your own company (warehouse) or another system (order system). Outside the system doesn't mean outside the company.
Part 3: the data flows
- Part 3 is the data flows: arrows between a box and the circle, labelled with the data as a noun, like Return request. Every arrow touches the circle, and there are no data stores at this level, because files and databases live inside the circle.
Step 1: name the system and its purpose
- Step 1: put one circle in the middle, name it Returns portal, and write its purpose underneath: it lets customers return an item without calling us. Use that sentence to settle later questions. If two people describe the purpose differently, settle it first.
Step 2: list the outside parties
- Step 2: for each name on your list, ask: does it send data to the portal or get data from it? If yes, it gets a box. Here that gives 5: customer, courier, warehouse, payment provider and order system. A party that trades no data stays off, even if it matters to the project.
Step 3: draw the flows, both ways
- Step 3: for each box, ask what goes in and what comes back. Customer: Return request in, Return label out. Courier: Pickup booking out, Tracking update in. Warehouse: Expected return out, Inspection result in. Order system: Order details in. Payment provider: Refund instruction out, Refund result in.
Step 4: check every edge
- Step 4: check that every box has an arrow, every arrow touches the circle and every label is data, not an action. Then look for gaps. The Refund instruction arrow means the portal, not finance, decides when to refund. Finance and the sales manager agree: after the warehouse passes the item.
Step 5: walk it with the stakeholders
- Step 5: walk the diagram with each party and ask what is missing. Customer service says customers call daily asking where their refund is. That adds a 6th party and a new flow, Return status, plus a requirement area nobody had written down.
Worked example: the finished context diagram
- The finished diagram has 1 circle, 6 outside parties (customer, courier, warehouse, payment provider, order system, customer service) and 10 data flows, including Return request, Return label, Pickup booking, Tracking update, Refund instruction and Return status.
Build it in draw.io
- In draw.io, start a blank diagram. From the General shapes, drag an ellipse to the middle and type Returns portal. Add the customer as a rectangle on the left, hover over it and drag the blue arrow onto the circle, then label it Return request. Add the courier on the right.
Turn it into in and out of scope
- Turn each arrow into a line in your in-scope list: send a return label, book the pickup, show the return status. Then list what's out: changing the order system, running courier tracking, restocking items. Play it back to the sales manager and put both lists at the top of the requirements.
5 common mistakes
- 5 common mistakes: drawing the inside, verb labels, forgetting other systems, arrows between 2 outside parties, and never showing the diagram to the people in the boxes.
Recap
- Recap: draw the edges, not the inside. 3 parts: 1 circle, the outside parties and the data flows labelled with nouns. 5 steps: name the system and its purpose, list the parties, draw flows both ways, check every edge, walk it with stakeholders. Then write the in-scope and out-of-scope lists.
Common mistakes
- Drawing the inside of the system. Steps, screens and databases don't belong on a context diagram. Keep the circle closed and save the detail for the lower-level data flow diagrams.
- Labelling arrows with verbs. An arrow carries data, so name the data as a noun. Write Refund instruction, not send money.
- Forgetting other systems. Systems like the order system and the payment provider never come to meetings, so they get missed. Check your list of existing systems for any that send or receive data.
- Arrows between 2 outside parties. The courier and the warehouse may talk to each other, but that doesn't cross your system's border. Every arrow must touch the circle.
When a business analyst uses this
At the start of a project with a vague request like "build a returns portal", a BA draws the context diagram, walks it with each stakeholder in a workshop, and turns the arrows into the in-scope and out-of-scope lists that the sponsor signs off at the top of the requirements.
Questions people ask
What is the difference between a context diagram and diagram 0?
A context diagram shows the whole system as one process with the outside parties around it. Diagram 0 opens that process into its main sub-processes and data stores. Naming varies, and some teams call the context diagram level 0.
What does a context diagram show?
It shows one system as a single circle, the outside parties that send it data or get data from it, and arrows labelled with that data. It shows scope, not how the system works inside.
Is a context diagram a data flow diagram?
Yes. It is the top level of a data flow diagram: the whole system as one process, with no data stores. The levels below it show the inside.
