1. Systems Analysis I Data Flow Diagrams
ISYS 200
Glenn Booker
ISYS 200
Week #4

2. Data Flow Diagrams
Data Flow Diagrams (DFDs) are the primary tool for summarizing the processes a system can perform
They are useful both for capturing the existing system’s capabilities, and then are revised to show the new system’s processes
A DFD shows processes, entities, and data stores, connected by data flow lines
ISYS 200
Week #4

3. Data Flow Diagrams
Processes are the functions some user can perform using the system
Users indicate the kind of user who is allowed to perform each process (clerk, sales manager, etc.)
The data stores on a logical DFD are a high level description of the types of data storage needed to perform each process
ISYS 200
Week #4

4. Data Flow Diagrams
DFDs can show either the logical structure of processes, or the physical structure
Logical structure shows all possible processes, regardless of where they occur in the system
Physical structure indicates what physical parts of the system (e.g. type of servers) perform each kind of process
Unless specified, assume we imply a logical DFD
ISYS 200
Week #4

5. DFD Notation
Here are Visio examples of the entity, process, and data store shapes, with data flow lines connecting them
If your shapes differ from the text’s, provide a legend
Note that in Visio, these shapes are under the Flowchart family, not Database
ISYS 200
Week #4

6. DFD Scope
A DFD does not show any kind of business rules for processes – just all possible paths
No decisions, or conditions (if)
A logical DFD does not show the subsystems involved in a process
We might show a Customer data store, but don’t specify how or where is it implemented
Processes may be manual or automated – there is no distinction on a logical DFD
ISYS 200
Week #4

7. DFD Notation – Entities
More formally, the ‘kind of user’ is called an entity in the text – an unfortunate choice when we get to the ERD*
An entity can be a type of user, or some kind of external system with which your system interacts
External systems might include other information systems within or outside of your organization
Like a legacy system used for processing invoices
* An entity in a DFD could be more general than an entity in an ERD
ISYS 200
Week #4

8. DFD Notation – Processes
Processes are the business functions performed using the system
We prefer a “verb (adjective) noun” naming convention for processes
Prepare shipping invoice
Enter new customer
Remove backorder
Update reorder parameters
Number processes for later reference
ISYS 200
Week #4

9. DFD Notation – Data Stores
A data store is a kind of data needed to perform processes
Temporary data isn’t shown on a logical DFD
Data stores can be manual or automated
A data store is labeled with the type of data
Sales
Customer
Put a reference number in front of each data store name, e.g. D1, D2, D3, etc.
ISYS 200
Week #4

10. Creating a Logical DFD
Data flow diagrams can be done on multiple levels of detail, as your understanding of the system evolves
Start by listing the processes and activities associated with your system, and look for entities, processes, and data stores
Create a context diagram (the simplest DFD)
Create the diagram 0 data flow diagram, showing entities, general processes and data stores
Include data flow names
ISYS 200
Week #4

11. Creating a Logical DFD
Pick significant processes, and expand them into more detailed DFDs if needed
The numbering of processes reflects the level of detail shown
The system is process ‘0’ in a context diagram
In a diagram 0 DFD, the processes are numbered 1, 2, 3, etc. (parent diagram)
To expand on process 3, Diagram 3 would show processes 3.1, 3.2, 3.3, etc. (child diagram)
ISYS 200
Week #4

12. Creating a Logical DFD
Watch the zeros! Process ‘0’ does NOT appear on the Diagram 0 DFD!
Diagram ‘x’ means it is a DFD which expands on the contents of the process numbered ‘x’
So Diagram 3.2 would contain processes 3.2.1, 3.2.2, 3.2.3, etc.
Page 200 has a good Diagram 0 DFD
This is the lowest level of DFD detail we’ll use
ISYS 200
Week #4

13. Levels of DFD Context Diagram Shows system as one box, process 0
Diagram 0 DFD
Shows high level data flows for the entire system
Diagram x DFD (where x>0)
Shows processes within process number ‘x’ from the Diagram 0 DFD
Diagram x.y DFD (x, y >0)
Shows processes within process number ‘x.y’ from the Diagram x DFD
ISYS 200
Week #4

14. Rules for Data Flow Diagrams
Entities never connect directly to a data store
They must use some process to access or modify the data
Hence a user or external system can only connect to one or more processes
All kinds of entities which appear on the context diagram must appear somewhere on the DFD
Otherwise they don’t do anything!
ISYS 200
Week #4

15. Rules for Data Flow Diagrams
Each process will connect to at least one user or external system, and one data store
Each process may send data to one or more data stores, and/or get data from one or more data stores
Processes rarely connect to other processes
Each process needs data flowing in and out of it
Fix processes which have logically incomplete inputs and outputs
ISYS 200
Week #4

16. Rules for Data Flow Diagrams
Leave in processes which calculate something, make decisions, manipulate data, or organize data
Data flows into and out of parent and child diagrams should be consistent
Data flows pointing away from an entity imply they provide input to the system
Data flows pointing to an entity imply they receive an output from the system
ISYS 200
Week #4

17. Rules for Data Flow Diagrams
Every data store needs data flowing both in and out somewhere on the diagram
Otherwise you have a data black hole = inputs but no output, or
A miracle = outputs without input
Data stores do not connect directly to each other
A process is needed to take data from one data store, and write it to another one
ISYS 200
Week #4

18. DFD Evolution Typically three steps are used with DFDs
The first DFD captures the processes used by the existing system
The second DFD describes the processes to be used by the new system
A third DFD is a physical description of the new system
The first two DFDs are logical DFDs
Now we’ll mention the physical DFD
ISYS 200
Week #4

19. Physical DFDs A physical DFD shows how processes will be implemented
Entities are still entities
Data stores are now files, and may include temporary files
Processes are now specific programs or manual procedures
See example on page 202
ISYS 200
Week #4

20. Partitioning a DFD
A Physical DFD can be partitioned to help determine the structure of the application
Partitioning groups processes by similarity
Group manual processes vs. automated ones
Group processes by the type of user
Group processes by their time sequence
Group processes which perform similar tasks
Group processes which use similar resources
ISYS 200
Week #4

21. Partitioning
Group processes to ensure consistent data
Group processes for security protection
Partitioning can also be done at the user interface level (e.g. a web site) for the same kinds of reasons
ISYS 200
Week #4

22. CRUD Matrix
A CRUD matrix maps data and processes to verify that all data is used correctly throughout the system
CRUD refers to the possible activities
Create new data
Read existing data
Update or change or modify existing data
Delete existing data
ISYS 200
Week #4

23. CRUD Matrix
The CRUD matrix shows process names in each row, and data stores in each column (p. 203)
For each process and data store, enter C, R, U, and/or D to indicate the possible data activities
A blank indicates that process does not affect that data store
For further clarity, use the process and data store numbers from the DFD
ISYS 200
Week #4

24. CRUD Matrix
At a minimum, make sure each data store is Created and Read by at least one process
Update and Delete may be optional
ISYS 200
Week #4

25. Event Response Table Further documentation of processes is encouraged
One form is the event response table (p. 204)
This provides a summary of each process
Event – is the process name
Source – is the entity who starts the process
Trigger – is the data or stimulus which is needed from the source
ISYS 200
Week #4

26. Event Response Table Activity – is a brief description of the process
Response – is typically an interface screen (for a human Destination) or type of data (for an external system Destination) which conveys the results of the process
Destination – is the entity which received the output from the process (whether human or an external system)
ISYS 200
Week #4

27. Other DFD Documentation
Another approach for documenting a DFD is to outline the contents of the DFD before making the drawing
Identify the entities and processes
Make a table to show
Process Name, Description, Entities, Inputs, Outputs, and Data Sources
ISYS 200
Week #4

28. Other DFD Documentation
Except Description, these all correspond directly to stuff which appears on the DFD:
Process Name – the label inside the process shape (later add the numbering)
Description – a brief description of the process
Entities – are the entities which participate in the process
Inputs – are data flow(s) leading into the process
Outputs – are data flow(s) leading out of the process
ISYS 200
Week #4

29. Other DFD Documentation
Data Sources – are the data stores connected to the process (later add the numbering)
Notice that the Inputs and Outputs are the data flow labels, which could be coming from or to entities or data stores
Use the table to help arrange the processes
For example, sort the processes by Entity to help see which processes should be grouped together on the DFD
ISYS 200
Week #4

30. Other DFD Documentation
Duplication of entities and data stores is permitted on a DFD for clarity
Flag or footnote them to indicate a deliberate duplicate is being used
In addition to the description of processes, provide a brief description of the data stores and entities
Note any assumptions about the scope or responsibilities of anything in the DFD which affected your modeling decisions
ISYS 200
Week #4