Lesson 1: Context Diagrams
System Boundaries & External Entities: Context Diagrams
What are Context Diagrams?
Context Diagrams are high-level diagrams used in the early stages of system analysis and design. They are part of the NESA Software Engineering syllabus and serve a crucial purpose in understanding system scope.
Context Diagrams help us answer key questions:
- WHAT is our system? (The central process)
- WHO or WHAT interacts with it? (External entities)
- HOW does data flow in and out? (Data flows)
- WHERE are the system boundaries? (What's inside vs outside)
Think of a Context Diagram as a "bird's eye view" of your entire system and everything that connects to it from the outside world.
Key Components of Context Diagrams
🎯 Central System
The main system or process being analyzed. Usually drawn as a circle or rounded rectangle in the center.
Example: "Dead by Daylight Game System"
🔗 External Entities
People, organizations, or other systems that interact with your system but are outside its control.
Example: Players, Steam Platform, Game Servers
➡️ Data Flows
Arrows showing information or data moving between the system and external entities.
Example: "Player Input" → System, System → "Match Results"
📦 System Boundary
The invisible line that separates what's inside your system from what's outside. Everything inside is your responsibility to build.
Example: Game logic is inside, internet infrastructure is outside
Dead by Daylight Example: Game System Context
Let's create a Context Diagram for the Dead by Daylight game system to understand its boundaries and external interactions:
Keyboard/Mouse
Achievement Updates
Game System
Player Statistics
Violation Reports
Understanding System Boundaries
The Context Diagram clearly shows what Behaviour Interactive (the developers) is responsible for building versus what they rely on from external sources:
| Inside the System (Our Responsibility) | Outside the System (External Dependencies) |
|---|---|
| Game logic and rules | Players' computers and controllers |
| Character models and animations | Steam platform infrastructure |
| Sound effects and music | Internet service providers |
| User interface design | Third-party anti-cheat software |
| Matchmaking algorithms | Hardware manufacturers (graphics cards, etc.) |
Why this matters: Understanding these boundaries helps developers know what they need to build versus what they can rely on existing external systems to provide.
Data Flows in Detail
Context Diagrams also help us understand the types of information flowing in and out of our system:
Input Data Flows (Into the System)
- From Players: Movement commands, skill checks, perk selections, chat messages
- From Steam: User authentication, purchase confirmations, friend lists
- From Game Servers: Player profiles, unlocked content, previous match history
- From Anti-Cheat: Suspicious behavior alerts, player reputation scores
Output Data Flows (Out of the System)
- To Players: Visual game state, audio cues, UI feedback, match results
- To Steam: Achievement progress, playtime statistics, screenshot data
- To Game Servers: Match outcomes, player performance data, new unlocks
- To Anti-Cheat: Player behavior patterns, game state validation
Why Context Diagrams are Essential for NESA
Context Diagrams are specifically included in the NESA Software Engineering syllabus because they:
- Define Project Scope: Clearly show what you're building vs. what already exists
- Identify Stakeholders: Show all external entities that will interact with your system
- Plan Interfaces: Help design how your system will communicate with external systems
- Manage Complexity: Simplify complex systems into understandable high-level views
- Support Documentation: Provide clear system overview for technical specifications
- Enable Testing: Identify all external interactions that need to be tested
In HSC exams, you might be asked to draw Context Diagrams for various systems or analyze existing diagrams to identify missing components.
Activity: Create Your Own Context Diagram
Your Turn: Draw a Context Diagram for a simpler system - the Dead by Daylight Store (where players buy cosmetics and DLC).
Consider these questions:
- What is the central system? (Hint: "DbD Store System")
- What external entities interact with the store?
- Players (browsing, purchasing)
- Payment processors (credit cards, PayPal)
- Game client (updating owned content)
- Content management system (new items)
- What data flows in and out?
- IN: Purchase requests, payment confirmation, browsing queries
- OUT: Store catalog, purchase receipts, content unlocks
Challenge: Try to identify at least 4 external entities and 6 different data flows. Draw it on paper or describe the relationships in words.
Context Diagrams vs Other NESA Diagrams
Context Diagrams work together with other NESA-required diagrams:
📊 Context Diagrams
Purpose: Show system boundaries and external entities
Level: Highest level view (Level 0)
🔄 Data Flow Diagrams
Purpose: Show detailed processes and data movement
Level: Breaks down the Context Diagram into sub-processes
🏗️ Structure Charts
Purpose: Show program hierarchy and module relationships
Level: Implementation-level view of code structure
Each diagram serves a different purpose in the software development process, and understanding when to use each one is crucial for NESA success.