Systems Analysis & Modeling: Data Flow Diagrams, System Flowcharts, and Use Cases

SS3 Term 1 • Week 2

About 45 minutes

When civil engineers design a bridge over the Niger River, they do not begin by pouring concrete into the water. They draw architectural blueprints, calculate stress vectors, and model water currents.

In software engineering, you must never write lines of code until you have mapped the System Architecture and Information Flow.

How do business analysts communicate software logic to clients, managers, and developers? They use visual modeling techniques: Data Flow Diagrams (DFD), System Flowcharts, and UML Use Case Models. In this lesson, we study how to model real-world information systems visually.

Learning Outcomes

By the end of this lesson, you will be able to:

Construct Context Diagrams (Level-0 DFD) and decomposed Level-1 DFDs.
Apply standard DFD symbols: Processes, External Entities, Data Stores, and Data Flows.
Map hardware and physical media using ANSI System Flowcharts.
Author UML Use Case Specifications detailing actors, preconditions, and alternate flows.

Key Vocabulary

Term	Technical Definition
Data Flow Diagram (DFD)	A graphical representation of the flow of data through an information system, modeling inputs, transformations, and storage.
Context Diagram (Level 0)	The highest-level DFD that depicts an entire system as a single central process bubble interacting with external entities.
Level-1 DFD	A decomposed view that breaks down the context diagram into the main functional sub-processes, data stores, and internal flows.
External Entity	An outside person, organization, or external system that provides input data to or receives output data from the system.
Data Store	A repository of persistent data held within the system (e.g., database table, file, cache).
Use Case Diagram	A UML behavioral diagram illustrating the interactions between human/external actors and the system's functional services.

Data Flow Diagram (DFD) Conventions

In the standard Gane & Sarson notation, four symbols model any information system:

1. Process (Rounded Rectangle or Circle):
   Transforms incoming data into outgoing data.
   [ 1.0 Verify User Login ]

2. External Entity (Square / Rectangle):
   Sources or sinks of data outside the system boundary.
   ┌───────────────────┐
   │  Student / User   │
   └───────────────────┘

3. Data Store (Open-ended Parallel Lines):
   Where data rests permanently or temporarily.
   ─────────────────────
     D1: Students Table
   ─────────────────────

4. Data Flow (Directed Arrow):
   Packets of data moving between processes, entities, and stores.
   ──────( student_id, password )──────>

Critical Rules of DFD Syntax:

No Entity-to-Entity flows: Data cannot jump between two outside entities without passing through a system process.
No Entity-to-Store flows: An external entity cannot directly read or write to a database store without a process handling verification and authentication.
No Black Holes: A process cannot receive inputs without generating at least one output.
No Miracles: A process cannot generate outputs without receiving necessary input data.

Decomposing a System: From Level 0 to Level 1

Consider an Online Banking Mobile Transfer System:

Level-0 Context Diagram:

The entire bank application is a single circle:

┌──────────┐                                                   ┌──────────────┐
│ Customer │ ──────( 1. Transfer Request: Acct, PIN, ₦ )─────> │ 0.0          │
│          │ <─────( 4. SMS Debit Alert & Receipt )─────────── │ Central Bank │
└──────────┘                                                   │ Core Banking │
                                                               │ System       │
┌──────────┐                                                   │              │
│ NIBSS /  │ <─────( 2. Inter-Bank Clearing Settlement )────── │              │
│ Dest Bank│ ──────( 3. Transfer Acknowledgment )────────────> └──────────────┘
└──────────┘

Level-1 DFD (Opening the System Box):

We decompose Process 0.0 into distinct sub-processes: - 1.0 Authenticate Customer & Verify PIN (Checks D1: Customers Table) - 2.0 Check Account Balance (Checks D2: Ledger Accounts) - 3.0 Post Debit Transaction (Updates D2: Ledger Accounts, creates record in D3: Transaction Logs) - 4.0 Dispatch External Settlement (Transmits packet to NIBSS)

UML Use Case Specifications

A Use Case describes how an Actor (user or system) achieves a specific business goal.

Use Case Specification: Transfer Funds
--------------------------------------------------------------------------------
Primary Actor:    Retail Bank Customer
Preconditions:    Customer is authenticated and possesses a positive account balance.
Postconditions:   Customer's ledger balance is debited; recipient account is credited;
                  audit transaction record is permanently written.

Main Success Scenario (Happy Path):
1. Customer enters beneficiary bank, 10-digit account number, and amount (₦).
2. System queries NIBSS name inquiry service and displays recipient name.
3. Customer confirms recipient name and enters 4-digit transaction PIN.
4. System validates PIN against bcrypt hash in secure HSM.
5. System verifies customer has sufficient balance.
6. System debits sender, logs transaction ID, and displays success receipt.

Alternative / Exception Flows:
3a. Incorrect PIN entered:
    - System increments failed attempts counter.
    - If attempts >= 3, account transfer privileges are locked for 24 hours.
5a. Insufficient Funds:
    - System aborts transaction, generates error message: "Insufficient balance".
    - No debit record is posted.

Practical Activity: Software Simulation of a DFD Process Engine

Let us write a Python script that models a Level-1 DFD process engine with Data Stores, validation gates, and transaction logging.

Step 1: Create `dfd_process_sim.py`

# Simulated Data Stores (Level-1 DFD)
D1_CUSTOMERS = {
    "001": {"name": "Fatima Sanusi", "pin_hash": "4321", "balance": 50000.0, "status": "active"}
}
D2_TRANSACTIONS = []

# Process 1.0: Authenticate Customer PIN
def process_1_authenticate(account_no, entered_pin):
    customer = D1_CUSTOMERS.get(account_no)
    if not customer:
        return False, "Account does not exist"
    if customer["status"] != "active":
        return False, "Account is suspended"
    if customer["pin_hash"] != entered_pin:
        return False, "Invalid PIN"
    return True, customer

# Process 2.0: Check Balance
def process_2_check_balance(customer, amount):
    if customer["balance"] < amount:
        return False, "Insufficient balance"
    return True, "Balance sufficient"

# Process 3.0: Post Debit and Write to Transaction Store
def process_3_post_debit(account_no, amount, beneficiary):
    # Debit customer ledger
    D1_CUSTOMERS[account_no]["balance"] -= amount
    new_balance = D1_CUSTOMERS[account_no]["balance"]

    # Write to Data Store D2
    tx_record = {
        "tx_id": f"TXN-{1000 + len(D2_TRANSACTIONS)}",
        "sender": account_no,
        "beneficiary": beneficiary,
        "amount": amount,
        "remaining_balance": new_balance
    }
    D2_TRANSACTIONS.append(tx_record)
    return tx_record

# Run End-to-End DFD Process Flow
print("=== DFD PROCESS SIMULATION: FUNDS TRANSFER ===")
acc = "001"
pin = "4321"
transfer_amount = 12500.0
dest_acct = "0987654321"

# Flow step 1:
auth_ok, auth_msg = process_1_authenticate(acc, pin)
print(f"Process 1.0 (Auth):      Success={auth_ok} [{auth_msg}]")

if auth_ok:
    cust = auth_msg
    # Flow step 2:
    bal_ok, bal_msg = process_2_check_balance(cust, transfer_amount)
    print(f"Process 2.0 (Balance):   Success={bal_ok} [{bal_msg}]")

    if bal_ok:
        # Flow step 3:
        receipt = process_3_post_debit(acc, transfer_amount, dest_acct)
        print(f"Process 3.0 (Debit):     Posted Transaction {receipt['tx_id']}")
        print(f"Updated Data Store D1:   New Balance = ₦{receipt['remaining_balance']:,.2f}")
        print(f"Updated Data Store D2:   Logged Record {receipt}")

Step 2: Run the Script

python dfd_process_sim.py

Expected Results and Model Output

When you run dfd_process_sim.py, your terminal will display:

=== DFD PROCESS SIMULATION: FUNDS TRANSFER ===
Process 1.0 (Auth):      Success=True [{'name': 'Fatima Sanusi', 'pin_hash': '4321', 'balance': 50000.0, 'status': 'active'}]
Process 2.0 (Balance):   Success=True [Balance sufficient]
Process 3.0 (Debit):     Posted Transaction TXN-1000
Updated Data Store D1:   New Balance = ₦37,500.00
Updated Data Store D2:   Logged Record {'tx_id': 'TXN-1000', 'sender': '001', 'beneficiary': '0987654321', 'amount': 12500.0, 'remaining_balance': 37500.0}

The data flow followed every formal DFD constraint: data flowed from external actor through validation processes into persistent data stores!

Common Mistakes to Avoid

Confusing DFDs with Flowcharts: A Flowchart shows procedural control order (loops, if-else decisions, start/end). A Data Flow Diagram shows data movement and transformations without specifying chronological sequencing or loops.
Missing In-Flight Data Flow Labels: Every arrow in a DFD must be clearly labelled with the data item traveling along it (e.g., verified_credentials, monthly_sales_report). Unlabelled arrows violate DFD specifications.
Omitting Exception Paths in Use Cases: A use case that only describes the ideal "happy path" is incomplete. Up to 80% of software bugs occur in alternate and exception paths (timeouts, lost network, invalid cards).

Notebook Summary

Data Flow Diagrams (DFDs) map information flow across Processes, External Entities, Data Stores, and Data Flows.
Level-0 Context Diagrams model the overall boundary; Level-1 DFDs decompose core operational sub-processes.
DFD Syntax Rules: No direct entity-to-entity flows; no direct entity-to-store flows; every process must have inputs and outputs.
UML Use Cases capture actor interactions, preconditions, main success scenarios, and alternative exception flows.

Optional Extension Challenge

Draw an ANSI System Flowchart on paper showing the processing of a School Computer-Based Test (CBT) Examination. Include symbols for: Online Student Input (Terminal), CBT Web Server (Processing), Student Exam Answers (Magnetic Disk / Database Store), and Printed Results Sheet (Document / Hardcopy).