Data Flow Diagram

Concepts and Case Study Analysis

Detailed Explanation of Data Flow Diagram :

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system
requirement graphically. It can be manual, automated, or a combination of both. It shows
how data enters and leaves the system, what changes the information, and where data is
stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may
be used as a communication tool between a system analyst and any person who plays a part
in the order that acts as a starting point for redesigning a system. The DFD is also called as a
data flow graph or bubble chart.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to elements in the DFD.

2. Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve any
order of events.

3. Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in
a DFD, suppress that urge! A diamond-shaped box is used in flow charts to represents
decision points with multiple exists paths of which the only one is taken. This implies
an ordering of events, which makes no sense in a DFD.

4. Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are
shown in figure :

Symbol Name Function

 Used to connect processes
Data Flow to each other , arrow head
indicates direction of data
flow.

Performs some
Process transformation of input dta
to yield output data.

Source Of Sink A source of system inputs or

(External Entity) sink of system outputs.

A repository of data ; the

Data Store arrow heads indicate net
inputs and net outputs to
store.

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data store
indicates that the data is stored which can be used at a later stage or by the other processes
in a different order. The data store can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or
sink of system outputs.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact,
DFDs may be partitioned into levels that represent increasing information flow and
functional detail. Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily
three levels in the data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.

0-level DFD

It is also known as fundamental system model, or context diagram represents the entire
software requirement as a single bubble with input and output data denoted by incoming
and outgoing arrows. Then the system is decomposed and described as a DFD with multiple
bubbles. Parts of the system represented by each of these bubbles are then decomposed
and documented as more and more detailed DFDs. This process may be repeated at as
many levels as necessary until the program at hand is well understood. It is essential to
preserve the number of inputs and outputs between levels, this concept is called levelling
by DeMacro. Thus, if bubble "A" has two inputs x1 and x2 and one output y, then the
expanded DFD, that represents "A" should have exactly two external inputs and one
external output as shown in figure.

1-level DFD

A 1-Level DFD, also known as Level-1

DFD, is a more detailed version of the
context-level DFD (Level-0). It breaks
down the main process of the system
into multiple sub-processes, providing a clearer view of how data flows between these sub-
processes, external entities, and data stores. Each sub-process in Level-1 represents a
specific functionality of the system and has its own data inflows and outflows.

The data stores introduced at this level help to indicate where data is stored temporarily or
permanently during the system's operation. This level helps stakeholders understand how
the entire system operates internally, beyond the single black-box view of Level-0. The goal
is to decompose the main process into logical smaller parts to capture functional details,
which makes it easier to identify data dependencies and system behaviour. While still
abstract, it adds significant clarity to system functionality. It is particularly useful for
developers, analysts, and system designers during requirement analysis.
2-level DFD

A 2-Level DFD or Level-2 DFD takes the decomposition a step further by breaking down
each of the sub-processes identified in the Level-1 DFD into even finer processes. This level
shows greater detail about the internal operations of each sub-function and how they
communicate with each other, external entities, and data stores. It helps in understanding
complex systems by zooming in on individual components or modules. For each process in
Level-1, a corresponding Level-2 DFD is created, which maps out the internal logic of that
specific function.

This level is essential during the design phase to ensure a thorough understanding of data
flow and process interaction within smaller parts of the system. It often includes more data
stores and may involve repeated data flows for better explanation. As it shows lower-level
functions, it supports the development of modular, maintainable, and testable code.
Ultimately, Level-2 DFD helps bridge the gap between high-level system requirements and
actual implementation planning.

Case Study: Designing a Smart Campus Navigation

System (SCNS) :

Introduction

The Smart Campus Navigation System is designed to help students, faculty, staff, and
visitors find their way around a large university campus efficiently. Using GPS technology, QR
codes, and digital maps, the system allows users to search for locations (classrooms,
departments, canteens, admin offices, libraries, labs), get optimal routes, and even access
live updates on building accessibility or closures. The system will also allow users to access
floor-wise maps for multi-story buildings and get voice-based or visual step-by-step
directions.

DFD for Smart Campus Navigation System

Level 0 DFD (Explanation)

The Level 0 DFD for the Smart Campus Navigation System shows the system as a single
centralized process, interacting with various external entities like User
(Student/Visitor/Staff), Campus Map Database, and Admin. The user requests location or
direction information, and the system responds with route guidance. The admin updates
building locations or map data in the system. All data is processed and retrieved from the
central Campus Map Database.

The Level 0 DFD for the Smart Campus Navigation System shows the entire system as a
single process that communicates with users and administrators. Users (students, faculty, or
visitors) interact with the system to locate destinations on campus, such as lecture halls,
departments, or facilities. The admin has the ability to manage map data, update locations,
and ensure that the system reflects real-time changes. The system retrieves navigation
information from the campus map database and may utilize GPS or indoor beacon systems
to guide the user. This high-level view helps understand the external communication
without diving into internal process complexities.

Level 1 DFD (Decomposition of the System)

This diagram decomposes the main system into logical sub-processes. The Level 1 DFD of
the Smart Campus Navigation System breaks the system into five detailed processes. Users
first register or log into the system (Process 1), after which they can search for locations and
receive route suggestions (Process 2). For indoor areas, such as multi-floor buildings,
beacon-based indoor navigation is activated (Process 3).

The map and location data is accessed from a centralized data store and is maintained
through the admin interface (Process 4). The admin handles all back-end updates (Process
5), such as adding new buildings, changing routes, or updating floor maps. This
decomposition provides a structured view of how the navigation system operates internally
to assist the users effectively.

Conclusion

The development of Data Flow Diagrams (DFDs) for the Smart Campus Navigation System
provides a clear and structured representation of how data moves within the system.
Through Level 0 and Level 1 DFDs, the system's core functions—such as user interaction,
location search, indoor navigation, and administrative management—are broken down into
comprehensible processes. These diagrams help in understanding the flow of information
between users, system processes, and data stores, while also clarifying the roles of external
entities like GPS and administrators. By visualizing the system this way, stakeholders can
easily analyze, design, and improve the architecture of the navigation platform, ensuring
better usability, maintainability, and scalability. The DFD approach thus plays a crucial role in
transforming conceptual requirements into a working model for a smart, efficient, and user-
friendly campus navigation solution.