are you looking for a visual way to communicate the flow of data through a processor system
if so check out this comprehensive tutorial on data flow diagrams
hey doc squad dr white here with the business analysis doctor
today i'm giving you a comprehensive tutorial on data flow diagrams but before we get started if
you want more business analysis tips and training be sure to subscribe to the page and turn on the
notification bell with that said let's get started data flow diagrams are useful for illustrating a
transaction and transformation based system and for presenting the boundaries of that system
now let's look at what you'll learn we'll be discussing what a data flow
diagram is the data flow diagram notations the main components of a data flow diagram
the levels and categories of a data flow diagram
then we'll discuss data flow diagrams rules and best practices we'll take a look at some
examples of data flow diagrams and then we'll look at the different types of data flow diagrams
what is a data flow diagram a data flow diagram is a visual model that represents the flow of data
through a process or system data flow diagrams are used to show where data comes from and goes
it shows which activities transform data it shows which outputs are stored in the system
and it also shows which outputs are utilized by other activities or entities
let's look at some of the common notations of a data flow diagram
first we have the your data in demarco and the you're done in code as you can see both
represent the entities as rectangles the processes as ovals or sometimes circles
the data flows are lines with arrowheads however the data stores in these notations are different
urine and demarco represents the data store as two parallel horizontal lines
while you're not in code represents the data store as a rectangle with the right side open
the ssadm notation which stands for structured system analysis and design method usually swaps
how the shapes are used here the entity has a circular shape while the process is a square the
data store here is also a rectangle with the right side open and the data flows are lines with arrows
now let's look at gain and sarson here the entities are rectangles the processes are
represented through rounded rectangles the data stores are also represented as rectangles with
the right side open and the data flows are lines with arrowheads in the process note and data store
you'll notice these reference numbers we'll talk more about those later through the remainder of
the lesson i'll be using the gaining sarso notation since it does have this additional
component so the main components of a data flow diagram includes external entities processes
data stores and data flows now let's take a closer look at each of these components
external entities are outside objects that interact with the system these objects could be
a person organization or another system entities can also be classified into the following subsets
a source is an entity that provides an input to a process we'll see this when the entity
inputs or sends data to a process in order to change it data flows point away from the source
a sync is an entity that is a destination for the process outputs
data flow arrows point toward the sink also an external entity can be both a source and a sink
and this can be identified when the data is flowing to and from that entity when adding
descriptions the external entities should always be labeled as a noun for example customer now
let's look at processes a process is an activity which can be manual or automated that transforms
incoming data into outputs all outputs must have at least one data input and one data output
there are two key considerations for labeling processes
a process description must be an active verb noun format and a reference number is placed above the
description to indicate the level of the diagram as well as the process placed within the function
for example the process here is labeled as order item where order is the active verb and the item
is the noun also this process has a reference number of 1.0 which indicates that this is
the first process we're examining the system and also that we're at the level 0 data flow diagram
we'll discuss more about the reference number notations in a moment data stores model a
repository for a collection of data at rest each data store must have inputs and output data flows
data store labels must be a noun phrase such as order details the gain insertion notation
also includes a unique identifier for the data store to distinguish the various data stores from
one another since there can be multiple within the same diagram now let's look at data flows
a data flow is the representation of data or information moving between external entities
processes and data stores data flows will either be an input and output or both
data flows are always labeled as nouns for example sales order there are various
levels of the data flow diagram which are determined based on the level of detail needed
to represent the data flow the levels are facilitated through system decomposition
now let's take a look at each one the first level is the context diagram the context diagram is the
highest level diagram that represents the general function or boundaries of the entire system it
only contains one process node which is process zero this could be interpreted as zero because
here the node represents a system versus a process the context diagram also includes key external
entities and data flows the next dfd level is level zero this level decomposes or explodes
the entire system into the main or primary processes within the system of the context diagram
this level takes the name level 0 because the reference numbers of the processes
have whole numbers such as 1.0 2.0 3.0 and so on level 0 also introduces the datastore component
when documenting level 0 we have to maintain the same external entities
as the context diagram as those serve as the sinks or sources for our inputs and outputs
the next level is the level 1 data flow diagram
the level 1 data flow diagram decomposes the main processes into sub-processes
the name level 1 comes from the fact that one decimal place is included in the reference
numbers on the process nodes here the whole number represents the process that is being exploded
while the decimal represents somewhat of a sequence of the sub-process it represents
for example if process one is exploded into two subprocess they will be labeled as 1.1 and 1.2
a unique feature of the level 1 dfd in further levels is that they only require the processes
and data flow inputs and outputs which means that external entities are optional here
also at this level we have to consider a concept called balance which is maintaining
the same key input and output labels from the primary process that we've exploded
as you can see here process one has one input and one output therefore the boundary of the sub
processes need to include those same inputs and outputs the next level i'll discuss is level 2.
one thing to note is that the data flow diagram levels can go as far as you need them
to but generally they don't go past level 3. the lowest level should include processes that make
it possible to create a process specification document the level of detail that needs to be
illustrated is only that which is required based on the complexity of the data and requirements
now let's talk more about level 2. the level 2 dfd decomposes the sub processes into more
detailed activities now most literature on dfds doesn't refer to these as activities but i think
considering concepts such as system decomposition or business system hierarchies can help determine
when an additional level of detail of the dfd may be required like the previous levels level 2 takes
on its name because now we're considering two decimal points in the reference number
the whole number represents the process the first decimal represents the sub process
while the second decimal represents the sequence of the activity
here we have to maintain the same inputs and outputs as the sub-process that we exploded
now let's look at some data flow diagrams rules and best practices
first data must not flow between two entities data flow must be from an entity to a process or
a process to an entity they can also be multiple data flows between one entity and a process
next data must not flow between two data stores data flow must be from a data store to a process
or a process to a data store data flow can occur from one data store to several processes
next data must not flow from an external entity directly to a data store data flow from an entity
must be transformed by a process before going to datastore and vice versa
a process must have both input and output data flows every process must have input data flows to
process the data and an output data flow for the process data next a data store must also have both
input and output data flows every data store must have an input data flow to store the data and an
output data flow for the retrieval of the data the next rule is the number of processes in a
dfd should not exceed 12. some literature states 6 or 9 as the maximum but the idea is to maintain
simplicity and clarity and last but not least all the processes must be linked to at least one data
store or another process in the system now let's take a look at some examples of data flow diagrams
in this example here i'll be using amazon as our case study we'll start with the simplified
context diagram of purchasing products on amazon the primary process node is amazon's system to
purchase products the external entities here are customer vendor and customer financial
institution the flow of data is that the customer inputs user credentials and a product query
amazon then sends an availability request to the vendor and the vendor provides an inventory
status then amazon checks the availability of funds from the customer's financial institution
if the funds are available the financial institution sends a payment to amazon then
amazon will send an order confirmation back to the customer now let's explode the purchase product
system into a level zero diagram theoretically a system for purchasing a product on amazon would
include four primary processes complete login 1.0 search products 2.0 manage shopping cart
3.0 and complete checkout process 4.0 now that we have our four processes we need to incorporate the
same external entities and overall inputs from the context diagram we'll also add our data stores and
data flows that occur between the processes so the flow of data here will be as follows
the customer inputs user credentials to the login process then the login process validates the login
the user details data store here then sends the user profile to the user interface where the
customer will search for the products by entering a product query from there a product availability
request is sent to the vendor the vendor provides an inventory status which allows the customer
to select the products that are available the product selection gets sent to the shopping cart
and the total amount for the finalized order details are sent to the checkout page
here the customer selects a payment method the payment method details are retrieved from there
the system will check the fund's availability from the customer's financial institution
if the funds are available the payment is sent back to amazon and upon payment the
checkout process is complete and the order confirmation is sent back to the customer
now let's look at a level 1 diagram to do this we'll be exploding the complete checkout
process from the level 0 diagram into 4 sub processes including enter shipping details
4.1 enter billing details 4.2 choose delivery 4.3 and select payment method sub process 4.4
since we've identified our four sub processes we can go ahead and omit the external entities
if we want because we're taking a more detailed view here now remember a level 1 diagram must
be balanced with the level 0 diagram so we have to ensure that all of the input and output data flows
from the complete checkout process are included here looking back at the level zero diagram
we can see that the complete checkout process has four associated data flows including order details
a payment input a payment method output as well as the order confirmation output so these
are included within the boundaries of these four sub-processes so for these the flow of data would
be the order details are received the customer enters the shipping details which provides the
shipping address to validate if the billing and shipping details are the same the address
information is then sent to the delivery section so the customer can choose the delivery method
based on the method chosen the total cost details are calculated and sent to the payment screen
where the customer enters the payment method which is retrieved from the payment details on file
from there the system will check the availability of funds if the funds are available the payment is
sent back to amazon upon receipt of the payment the checkout process is complete and an order
confirmation is sent back to the customer now let's discuss the two types of data flow diagrams
these are logical data flow diagrams and physical data flow diagrams logical data
flow diagrams illustrate what will happen to the data during the business processes and activities
physical data flow diagrams illustrate how the data will move through the elements from a system
perspective and how the physical structures will be implemented to help delineate between logical
and physical data flow diagrams remember the following logical data flow diagrams focus on
the business perspective they illustrate what will happen they focus on business operation goals and
a business analyst or business system analyst usually creates this type of diagram for the
physical data flow diagram the focus is on the system perspective it illustrates how
the data flow will happen it facilitates the system implementation and usually a developer
or database analyst will create this type of diagram when creating logical versus physical dfds
you just need to adjust the perspective of what you're representing with the elements
for example the main process node might be to complete a specific process while in the
physical dfd that process node would represent the physical system in which the process occurs
to compare logical and physical dfds let's look at a simple context diagram from our amazon example
here we have our customer providing user credentials in order to purchase
a product which is a process and then a payment method is sent to a data store
adding implementation references is done for processes data flows and data stores
but not external entities data flows may be forms input screens fields records or output reports
data stores are generally tables in a database or files processes may be systems applications
or programming languages also it's a common practice to create a human machine boundary so
here we create the human machine boundary between the customer and the interface with this dashed
line here then we see that in the physical dfd the user credentials are passed from a login form
and the purchase product process is done through an ordering system or website then the payment
method is entered through a payment selection form and pass to a sql payment table to be retrieved
well there you have it folks that's what you need to know to properly create the various levels of
data flow diagrams if you learn something new tell me about it because i'd love to hear your feedback
also be sure to check out all of the business analysis and
ba certification training resources we have you on our website at theba.com thank you so much
for watching i hope you have a productive and prosperous day until next time bye now