Process GuidePrevious (disabled)Next - IntroductionGlossaryShortcutSummaryUp (disabled)

Data Flow Diagrams

Introduction
Notation
Steps
Tutorial


Process GuidePrevious - Data Flow DiagramsNext - NotationGlossaryShortcutSummaryUp - Data Flow Diagrams

Data Flow Diagrams

Introduction

A Data Flow Diagram (DFD) is a concise way of describing the flows of information within a system. As such it is an important method for understanding and communicating the functionality of a system.
Data Flow Diagrams fulfill this objective in a number of ways:
  • they are a non-technical representation that is relatively quick to produce and easy for users to understand
  • inter-connections are graphically shown, making the effects of changes easy to identify and incorporate, particularly when the technique is supported by graphics software
  • the use of different symbols, each with its own specific meaning, allows unambiguous and concise definition
  • the Data Flow Diagram technique of top-down expansion allows varying levels of detail to be shown and lets the reviewer progress between levels in a controlled way.
Data Flow Diagramming is useful from the earliest stages of analysis (e.g. taking notes at user interviews) through to specification of user requirements. Data Flow Diagrams are working documents that are subject to continual revision and change. Some simple guidelines to be observed include:
  • produce 'first cut' Data Flow Diagrams quickly, as rough working documents
  • check them by reviewing against the system being modeled, and discuss them with users, etc.
  • modify them in response to new information, user requests, feedback from walk-throughs, etc.
  • wait until the work is in its final form and has been agreed before producing final copies of "documentation quality".
Too much emphasis on the aesthetic quality of the diagram at an early stage is counter-productive in that the author can become resistant to change.

Process GuidePrevious - IntroductionNext - External Sources or RecipientsGlossaryShortcutSummaryUp - Data Flow Diagrams

Data Flow Diagrams

Notation

The shapes used for the various diagram components have been chosen so that they are easily distinguishable.
External Sources or Recipients
Processes
Datastores
Dataflows
Boundary Box

Process GuidePrevious - NotationNext - ProcessesGlossaryShortcutSummaryUp - Notation

Notation

External Sources or Recipients

An oval denotes a Source or Recipient of information that is external to the system, or project, with which the system communicates.
The external sources and recipients are always outside the boundary box.
In most diagrams, only those sources and recipients that originate and/or receive data need to be represented. These may include company management or other external systems.
A source of information may also be a recipient of another piece or type of information.
To minimize complex crossing dataflows in diagrams, sources and recipients may be duplicated.
Duplicated sources or recipients are indicated by a diagonal line at the top right hand of the oval.

Process GuidePrevious - External Sources or RecipientsNext - Unique IdentifierGlossaryShortcutSummaryUp - Notation

Notation

Processes

A rectangle represents a process which transforms or manipulates information in a system
It contains three descriptive elements:
Unique Identifier
Location
Description

Process GuidePrevious - ProcessesNext - LocationGlossaryShortcutSummaryUp - Processes

Processes

Unique Identifier

The identification is a number. It has no implications for priority or sequence, and serves simply as a unique reference.
That number may be allocated arbitrarily at top level Data Flow Diagram.
In order to maintain simple, cross-referenced documentation, each process within the boundary of a lower level Data Flow Diagram is identified by a decimal extension to the higher level process identifier.
For example, lower level processes within Process 12 would be 12.1, 12.2, etc.

Process GuidePrevious - Unique IdentifierNext - DescriptionGlossaryShortcutSummaryUp - Processes

Processes

Location

The location is a reference to where in the system the process takes place.
This may be a physical department, e.g. "Personnel Office", or a "computer".

Process GuidePrevious - LocationNext - DatastoresGlossaryShortcutSummaryUp - Processes

Processes

Description

The description is a simple imperative sentence, with the verb as specific as possible, e.g.
  • allocate inventory to order
  • issue renewal notice
  • assign team members to project.
Avoid the trap of glossing over processes without really being clear about what they are. Indications of this are vague terms such as "process", "update", etc.

Process GuidePrevious - DescriptionNext - DataflowsGlossaryShortcutSummaryUp - Notation

Notation

Datastores

The open-ended, narrow rectangle represents a store of data that is retained and used within the system. This may be a computer file, box of documents, or any other means of storing data. Datastores may be standing, long-term files, such as sales and purchase ledgers, or short-term accumulations, e.g. daily batches of documents.
Each store is given a unique number and a reference :
"D" - a permanent computer file
"T" - a temporary manual file, or an internal transient /transaction computer file
"M" - a permanent manual file.
As with sources and recipients, the same datastore may occur several times on a Data Flow Diagram, to avoid complex flows.
Multiple instances are indicated by a double vertical bar at the left hand edge.

Process GuidePrevious - DatastoresNext - Boundary BoxGlossaryShortcutSummaryUp - Notation

Notation

Dataflows

A dataflow represents the direction, and content, of the flow of information both within the system, and between the system and its environment.
A dataflow is represented by a line, with an arrowhead showing the direction of flow.
Each dataflow may be referenced by using the references of the processes, sources and recipients, or datastores, at its head and tail, but may have a description of its contents written alongside it.
The description must be meaningful to the reviewers of the data flow diagram.
At the top level the description may be omitted if a representative name cannot be found. As the process is broken down, however, names should be found.
In some cases, it is obvious what data is involved, and not essential to name the flow, but it is better to include an unnecessary name than to leave any margin for doubt or confusion.
In describing an existing system, actual document titles or references may be used.
For convenience and conciseness, a double-headed arrow may be used in place of two lines, where dataflows are paired.
Physical Resources - goods - often carry a data content which is used in the information system.
As such they are included in the Data Flow Diagrams as dataflows. Their name should make it clear that they are physical resources.

Process GuidePrevious - DataflowsNext - StepsGlossaryShortcutSummaryUp - Notation

Notation

Boundary Box

The boundary between the system, or project, and its external environment is shown by a large rectangle.
The Boundary Box icon is used to show either the boundary of the whole system/project, or the boundary of an individual process.
It is a special form of the process icon which displays the process name, reference and location.
On top level Data Flow Diagrams, it defines the system boundary and has reference 0.
On lower level Data Flow Diagrams, it defines the process boundary and displays the name, reference and location of the parent process.

Process GuidePrevious - Boundary BoxNext - Data Flow Diagram TypesGlossaryShortcutSummaryUp - Data Flow Diagrams

Data Flow Diagrams

Steps

Data Flow Diagram Types
Level 1 Data Flow Diagram Steps
Leveled Data Flow Diagram Steps
Logical Data Flow Diagram Steps

Process GuidePrevious - StepsNext - Physical Data Flow DiagramsGlossaryShortcutSummaryUp - Steps

Steps

Data Flow Diagram Types

There are four types of Data Flow Diagram that are developed at different times during a development project:
Physical Data Flow Diagrams
Logical Data Flow Diagrams
Business System Options
Required Data Flow Diagrams
If it has been decided to investigate the current system, then the physical Data Flow Diagrams will be the first type produced.
If, however, the current system is not to be investigated, then the technique will first be used to create a set of Business System Option to present to the user. These options will be depicted, in part, as Level 1 Data Flow Diagrams.

Process GuidePrevious - Data Flow Diagram TypesNext - Logical Data Flow DiagramsGlossaryShortcutSummaryUp - Data Flow Diagram Types

Data Flow Diagram Types

Physical Data Flow Diagrams

Physical Data Flow Diagrams depict the scope of the project and the current system.
They can be of varying degrees of complexity.
A simple model can be used for estimating purposes and for initial scoping.
A more complex diagram can model the current business.
Use the Level 1 and Leveled Steps.

Process GuidePrevious - Physical Data Flow DiagramsNext - Business System OptionsGlossaryShortcutSummaryUp - Data Flow Diagram Types

Data Flow Diagram Types

Logical Data Flow Diagrams

These are derived from the current physical Data Flow Diagrams, and show the underlying functionality of the system, without the constraints imposed by its current implementation.
Use the Logical Steps.

Process GuidePrevious - Logical Data Flow DiagramsNext - Required Data Flow DiagramsGlossaryShortcutSummaryUp - Data Flow Diagram Types

Data Flow Diagram Types

Business System Options

These show one or more business system options from which one must be chosen to form the basis of the required system
Use Level 1 Steps.

Process GuidePrevious - Business System OptionsNext - Level 1 Data Flow Diagram StepsGlossaryShortcutSummaryUp - Data Flow Diagram Types

Data Flow Diagram Types

Required Data Flow Diagrams

These depict the required system and are developed from the Data Flow Diagram that represents the selected business option.
Use the Leveled Steps.

Process GuidePrevious - Required Data Flow DiagramsNext - Overview of ApproachGlossaryShortcutSummaryUp - Steps

Steps

Level 1 Data Flow Diagram Steps

Overview of Approach
Step 1: List Key Flows of Information
Step 2: Create Initial Data Flow Diagram
Step 3: Agree System Boundary
Step 4: Identify Processes and Datastores
Step 5: Complete the Level 1 Data Flow Diagram
Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning
Step 7: Review the Data Flow Diagram


Process GuidePrevious - Level 1 Data Flow Diagram StepsNext - Step 1:  List Key Flows of InformationGlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Overview of Approach

The approach set out below can be used for creating a Level 1 Data Flow Diagram depicting a current system, or a proposed Business System Option.
The analyst is first concerned with establishing the basic characteristics of the system being considered. These basic characteristics are:
  • the system boundaries
  • the sources and recipients
  • the main system inputs and outputs, flowing between the system and the sources and recipients
  • the main system processes.
The partitioning implied in the identification of system processes may also be useful in partitioning the workload and allocating analysts to specific areas of the system.
Note that although the user must review results in steps 3 and 7, the user should be involved in the other activities at least in the form of interviews and question and answer sessions, etc.
Users may also actively participate in constructing the Data Flow Diagram.

Process GuidePrevious - Overview of ApproachNext - Step 2:  Create Initial Data Flow DiagramGlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Step 1: List Key Flows of Information

List key documents and information flows used in and produced by the system, and the sources and recipients of those flows.
These information flows will help to define the main elements of the system. Examples are:
  • telephoned messages
  • inputs
  • transaction files between processes.
Notice that minor documents and exception documents are omitted at this stage so that attention is initially focused on the main functions of the system.
Other documents can be noted for consideration at a later stage, when expanding the top level Data Flow Diagram or developing second and third level Data Flow Diagrams.
Also omitted are "inquiry only" dataflows.
Initially, expect to deal with no more than about 15 dataflows.
The objective at this stage is to identify the sources and recipients of information in the system and to chart the main communications between them. Too much detail will obscure the basic "shape" of the system.
As well as listing documents in Step 1, sending and receiving locations (the sources and recipients) must be determined.

Process GuidePrevious - Step 1:  List Key Flows of InformationNext - Step 3:  Agree System BoundaryGlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Step 2: Create Initial Data Flow Diagram

Build an Initial Data Flow Diagram showing only the source and recipient of each key document and the flows between them.
In this activity, the receiver and sender locations of each document are identified, and the Initial Data Flow Diagram (or Information Flow Diagram) is drawn. For this activity, a receiver or sender may be one of the following:
  • an organization or individual outside the organization altogether (e.g. Customer)
  • a department, section or area within an organization (e.g. Warehouse, Customer Service)
  • an existing computer system (e.g. Computer Order Processing).
In this activity, all senders and receivers are represented by the Source/Recipient symbol.
The initial Data Flow Diagram is built incrementally, document by document. To improve clarity, experiment with different layouts.
Actual document names should be used during this step to improve readability and user understanding. There may sometimes be conflicts between accuracy and readability which common sense should be able to resolve. For example, the readable term may be "sales order" but what the system strictly processes is the "sales order form."
Unless there is real danger of confusion, the simpler term can be used at this stage, to be replaced by more accurate definitions, and even document reference numbers, once the detailed Data Flow Diagrams have been produced.
A quick completeness check should be performed by identifying locations that are only sources or recipients, and by considering whether this is correct.

Process GuidePrevious - Step 2:  Create Initial Data Flow DiagramNext - Step 4:  Identify Processes and DatastoresGlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Step 3: Agree System Boundary

Determine the system boundary and mark it on the Initial Data Flow Diagram.
The Initial Data Flow Diagram must be reviewed with the user, initially to ensure accuracy and then to determine the system boundaries, i.e. the scope of further systems analysis and design needs.
At this point, the user may mention further documents and communications between senders and receivers. These can either be added to the Initial Data Flow Diagram if they are of major importance, or listed with the minor documents for attention later.
When the current system is being investigated, the analyst must obtain the user's guidance and agreement on the scope of the systems analysis.
Those areas whose method of working is likely to be radically changed should probably be within the scope of the analysis. Those who will not be changed will, usually, not be investigated further.
The main exception is when the information provided to, or received from the excluded area is to be changed. In this case, it may be necessary to provide instructions or explanations connected with the changed information flows.
It may also be necessary to review the identification of the senders and receivers in the light of user comments and the definition of the scope of systems analysis.
In these areas, only the portions of the activities that impact the order processing system are addressed.
Note that when a system boundary is added to the Initial Data Flow Diagram, external sources and recipients cannot be inside the system boundary - the sources and recipients inside the boundary are replaced by processes.
If there is any difficulty conveying the exact scope of the system, it may be worth drawing a 'Context Diagram' showing the entire system area to be investigated as a single 'black box' process, receiving inputs and supplying outputs to the external entities.
Although conceptually trivial, this representation for more complex systems does focus attention on the system boundaries. It can convey clearly and concisely the scope of a system and the environment in which it exists.

Process GuidePrevious - Step 3:  Agree System BoundaryNext - GlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Step 4: Identify Processes and Datastores

For each flow crossing the system boundaries on the Initial Data Flow Diagram, identify its receiving or generating process and associated datastores.
Now the parts of the Initial Data Flow Diagram that are within the system boundary can be expanded. This is done by identifying the processes associated with each flow.
Each sender or receiver within the system boundary will be expanded into one or more processes. Datastores should also be added at this stage.
A single (Level 1) level Data Flow Diagram should be produced, but if the emerging picture seems too extensive and elaborate (more than 12 process boxes), some of these processes should be grouped under a more general name.
This step is initiated by adding a "generating" and/or "receiving" process to each document in the flow.
For each process, physical datastores that may be used to store or retrieve data are identified. In discussions with the user, or from existing knowledge of the Business System Option being depicted, datastores that are used are identified, and then recorded on the Data Flow Diagram.
Three main types of datastores may be identified:
"D" Type Datastores - Permanent Computer Files
"T" Type Datastores - Temporary, Transient, Transaction Files
"M" Type Datastores - Permanent Manual Files
Each process must be evaluated to determine whether it needs to retrieve data from, or store data in, any of the three types of datastores.
Input processes, for example, often retrieve standing data for validation purposes and create reference copies and batch accumulations of transactions.
It is useful to have a checklist of likely datastores or types of datastores to ensure that none are missed.
Every sender and receiver which is now located outside the system boundary becomes an external source or recipient with respect to the system being depicted.
Each of the documents entering the system is received by a process which deals with it, similarly each document produced by the system originates with a process.
The initial assumption is that every document has a separate input or output process. However, processes may be combined if this is clearly appropriate.
Each process is given:
  • a unique reference number
  • its appropriate operating area or location (the sender or receiver taken directly from the diagram produced in Step 3)
  • a brief, descriptive phrase with an active verb.

Process GuidePrevious - Step 4:  Identify Processes and DatastoresNext - GlossaryShortcutSummaryUp - Step 4:  Identify Processes and Datastores

Step 4: Identify Processes and Datastores

"D" Type Datastores - Permanent Computer Files

  • the standing data, kept up to date and used for maintaining and operating the system day-to-day (e.g. customer, inventory, employee files, etc.)
  • historical data, retained in the system for inquiry, analysis and reference, but not changed once it has been inserted

Process GuidePrevious - Next - GlossaryShortcutSummaryUp - Step 4:  Identify Processes and Datastores

Step 4: Identify Processes and Datastores

"T" Type Datastores - Temporary, Transient, Transaction Files

  • accumulations of computer transactions passed between processes, e.g. a batch of filled orders may be accumulated for later production of a picking list
  • extracted data to be sorted, formatted etc., for production of reports and listings

Process GuidePrevious - Next - Step 5:  Complete the Level 1 Data Flow DiagramGlossaryShortcutSummaryUp - Step 4:  Identify Processes and Datastores

Step 4: Identify Processes and Datastores

"M" Type Datastores - Permanent Manual Files

  • reference copies of transactions produced by a computer system and maintained as original documents or manual files, e.g. copies of purchase orders, which are retained for comparison with delivery notes from suppliers

Process GuidePrevious - Next - Step 6:  Check for Consistency, Completeness and Effectiveness of PartitioningGlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Step 5: Complete the Level 1 Data Flow Diagram

Complete the overview Data Flow Diagram by adding further dataflows and processes if needed.
There are two reasons why the Data Flow Diagram produced in Step 4 may still be incomplete.
  • Some of the processes may communicate with each other directly, and not through datastores, so extra dataflows may need to be identified.
  • Intermediate processes may be needed to transform the results of input processes into a form suitable for output processes.
In this step, the most effective approach is generally to work backwards from the output processes, asking the following questions:
  • Does the process now have access to all the data it needs?
  • Can a process obtain the data it needs directly from an existing process or datastore, or is a further process needed to provide the necessary data?
The extra elements identified are then added to the Data Flow Diagram.

Process GuidePrevious - Step 5:  Complete the Level 1 Data Flow DiagramNext - Step 7:  Review the Data Flow DiagramGlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning

Review the Data Flow Diagram for consistency, completeness, and effectiveness of the partitioning into processes.
Before the final review some simple checks for consistency and completeness should be carried out. Before considering these checks in more detail, the purpose of a Data Flow Diagram should be reviewed.
For the current system, these checks are:
  • to document the main structure of the current system in a form that can be easily understood
  • to demonstrate that the analyst understands the current system
  • to provide a basis for discussion
  • to define the scope of the area of systems investigation
  • to provide a partitioning of the system as a start point for further analysis.
For Business System Options, the checks are:
  • to document an impression of each option so that it may be checked
  • to convey to the users and management how each option will operate
  • to provide the basis of defining the required system from the selected option.
It is helpful in this activity to ensure that each process can be investigated independently with few references to other processes; this is called partitioning.
If partitioning has taken place, it is easier for many analysts to work in the detailed investigation without duplicating, overlapping or getting in each other's way.
The three tests listed below are intended to help verify that the most useful or optimum approach to partitioning has been chosen.
  • Each process should ideally have a strong active verb and a single object, (e.g. Match Payments.) If it is difficult to give a concise name, it is probable that either the process has not been clearly understood, or further partitioning is needed to separate processes into more clearly definable ones.
  • All the dataflows into a single process should be clearly related to all the dataflows out of the process. If there are four dataflows in and four out, but two of the inputs are sufficient to produce two of the outputs, the process should probably be further divided.
  • The smaller the number of dataflows between a pair of processes the better the partitioning is likely to be. It is not possible to be precise about this guideline, but it is worth experimenting with different ways of identifying processes to see if the dataflows are increased or reduced. If it is difficult to further reduce the number of dataflows, a good level of partitioning has probably been achieved.
Initially, producing too low a level should be avoided. Level 1 Data Flow Diagrams will later be expanded into level 2s, and some of these may possibly be expanded into level 3s.
To ensure completeness and consistency.
  • Processes cannot simply be data sources or recipients of data. A process transforms input dataflows to output dataflows. It can not generate data out of thin air, nor can it use data without passing it on to another process, datastore or source/recipient.
  • Datastores should normally have dataflows both entering and leaving them. In other words, data must be created and used. Exceptions may occur when the "'creation"' or "'use"' processes are so trivial that they are not shown on the Level 1 Data Flow Diagram, e.g. datastores used for queries only.
  • It should now be possible to trace the full life and usage of each dataflow entering the system, through processing, reporting, transformation and deletion or other removal from the system. Normally this can be done by inspection. In a more complex case, individual document flows can be prepared for specific documents and used to further check the completeness of the Data Flow Diagram.

Process GuidePrevious - Step 6:  Check for Consistency, Completeness and Effectiveness of PartitioningNext - Leveled Data Flow Diagram StepsGlossaryShortcutSummaryUp - Level 1 Data Flow Diagram Steps

Level 1 Data Flow Diagram Steps

Step 7: Review the Data Flow Diagram

The final step in producing the Level 1 Data Flow Diagram for the current physical system is to review it with the user. Given the amount of interaction in producing the Level 1 Data Flow Diagram, major surprises should be rare at this point. However, it is worth ensuring that:
  • the Data Flow Diagram accurately reflects the structure of the current system
  • the user is certain that the scope of the system investigation is correctly defined
  • the partitioning is practical and helpful as a basis for work allocation and further development.
When producing Data Flow Diagrams of Business System Options, normally two or more options are produced for user review and discussion.

Process GuidePrevious - Step 7:  Review the Data Flow DiagramNext - Overview of ApproachGlossaryShortcutSummaryUp - Steps

Steps

Leveled Data Flow Diagram Steps

Overview of Approach
Step 1: Minimize Number of Level 1 Data Flow Diagram Processes
Step 2: Identify Lower Level Processes and Datastores
Step 3: Balance Lower Level Data Flow Diagram with Higher Level Data Flow Diagram

Process GuidePrevious - Leveled Data Flow Diagram StepsNext - Step 1:  Minimize Number of Level 1 Data Flow Diagram ProcessesGlossaryShortcutSummaryUp - Leveled Data Flow Diagram Steps

Leveled Data Flow Diagram Steps

Overview of Approach

If the original definition of processes (partitioning) has been done effectively, it should be possible to expand or decompose each process with little or no reference to other processes.
The basis of effective partitioning is that each process defined should represent a self-contained activity, i.e. that, as far as possible it should contain no activities which are also contained in another process at the same level.
For example, it would be unhelpful to partition a Level 1 Data Flow Diagram on the basis of geographic locations (process 1 represents office A, process 2 office B, etc.) when similar or overlapping activities are carried out in each one.

Process GuidePrevious - Overview of ApproachNext - Step 2:  Identify Lower Level Processes and DatastoresGlossaryShortcutSummaryUp - Leveled Data Flow Diagram Steps

Leveled Data Flow Diagram Steps

Step 1: Minimize Number of Level 1 Data Flow Diagram Processes

Avoid the creation of giant Level 1 Data Flow Diagrams. As a general rule, a Level 1 diagram should have not more than 12 to 15 process boxes. For large systems, this may seem difficult to achieve.
The recommended solution is to reduce the number of Level 1 processes defined by merging some under a more general name.
For example, "Maintain Customer Names and Addresses" and "Set Credit Limits" might become "Maintain Customer Details".
In looking for suitable processes to merge, look for the following indicators. Processes which:
  • have the same location
  • are linked by dataflows
  • use the same datastores
  • communicate with the same external source/recipients.
Start by merging those processes which seem the least complex and continue until a reasonable number of Level 1 processes remain.
This will result in a better "balanced", more readable set of Data Flow Diagrams - probably without increasing the overall number of levels involved. The merged processes should not be lost but held for inclusion in a lower level Data Flow Diagram.

Process GuidePrevious - Step 1:  Minimize Number of Level 1 Data Flow Diagram ProcessesNext - Step 3:  Balance Lower Level Data Flow Diagram with Higher Level Data Flow DiagramGlossaryShortcutSummaryUp - Leveled Data Flow Diagram Steps

Leveled Data Flow Diagram Steps

Step 2: Identify Lower Level Processes and Datastores

When the user has reviewed and accepted the Level 1 Data Flow Diagrams of the current system, the work may be defined in greater detail by the creation of level 2 Data Flow Diagrams.
If the Level 1 Data Flow Diagrams represent Business System Options, then it is after the chosen option has been selected that the analyst begins to define the required system in more detail. Part of this detailed definition will be in the form of level 2, and sometimes, level 3 Data Flow Diagrams.
Each process box on a Level 1 Data Flow Diagram should be considered separately and may be expanded into a Data Flow Diagram in its own right. These lower level processes can be further expanded until a satisfactory level of detail is achieved.
In order to maintain simple, cross-referenced documentation, each process within the boundary of the lower-level Data Flow Diagram is identified by a decimal extension to the higher level process identifier, e.g. processes within Process 12 would be 12.1, 12.2, etc.
A Level 1 process would typically expand to between 4 and 8, level 2 processes. When exception and error handling processes are added to the Data Flow Diagrams, each second-level Data Flow Diagram may have about 6-12 process boxes.
Again giant lower levels should be avoided. The processes should be merged using the same techniques for reducing the number of Level 1 processes.
External sources and recipients are not shown within the boundary of a process even if they communicate only with that process but are always shown outside the process boundary.
If datastores are used only within a process boundary, they are drawn inside the boundary. Datastores which are also used by other processes remain outside the boundary of the lower level Data Flow Diagram.
The lower level expansion may force the analyst to investigate the details of processing in greater depth in order to create an accurate view.

Process GuidePrevious - Step 2:  Identify Lower Level Processes and DatastoresNext - Logical Data Flow Diagram StepsGlossaryShortcutSummaryUp - Leveled Data Flow Diagram Steps

Leveled Data Flow Diagram Steps

Step 3: Balance Lower Level Data Flow Diagram with Higher Level Data Flow Diagram

Inclusion of the changes introduced by the expansion of a process to a lower level may result in changes/additions to the Level 1 Data Flow Diagram.
When producing lower level Data Flow Diagrams, it is often necessary to show separately the processes which are activated by the same source but are treated differently.
The maintenance procedure for a Product and Prices file may, for instance, be shown on the Level 1 as:
The lower level Data Flow Diagram would show this as three separate flows. This approach to breaking down dataflows is called "parallel decomposition".

Process GuidePrevious - Step 3:  Balance Lower Level Data Flow Diagram with Higher Level Data Flow DiagramNext - Overview of ApproachGlossaryShortcutSummaryUp - Steps

Steps

Logical Data Flow Diagram Steps

The production of logical Data Flow Diagrams involves a three step conversion from physical to logical.
Overview of Approach
Step 1: Convert Datastores (Physical to Logical)
Step 2: Convert Dataflows (Physical to Logical)
Step 3: Convert Processes (Physical to Logical)

Process GuidePrevious - Logical Data Flow Diagram StepsNext - Step 1:  Convert Datastores (Physical to Logical)GlossaryShortcutSummaryUp - Logical Data Flow Diagram Steps

Logical Data Flow Diagram Steps

Overview of Approach

In producing the current physical Data Flow Diagrams, "how the system works" is recorded.
It is important that this is understood and can be demonstrated to the user. It is also a useful medium for identifying problems in the current system.
However "how the system works" is invariably more complex than "what the system achieves" because of the physical constraints within which it was designed to operate.
These constraints may include:
  • the hardware and software used
  • the geographical distribution of processes or data
  • the need to incorporate or interface with some previously existing system (and its own constraints)
  • other anomalies.
By creating a current physical Data Flow Diagram, an understanding of the current system processing and the underlying business activities it supports has been gained.
This knowledge is used to abstract those elements that needed to support the business activities and discard any physical constraints or anomalies
Produce a logical Data Flow Diagram to do this. Producing a logical model is an intermediate step towards the goal of specifying the required system.
Logical Data Flow Diagrams will provide:
  • a definition of the system's underlying functionality which is independent of its current implementation
  • a clarification of potential problem areas within the current system.

Process GuidePrevious - Overview of ApproachNext - Review Transient (T) DatastoresGlossaryShortcutSummaryUp - Logical Data Flow Diagram Steps

Logical Data Flow Diagram Steps

Step 1: Convert Datastores (Physical to Logical)

The files within a system usually provide the underlying structure around which the system's processing is designed. In cases where files are poorly designed, the system's processing will also contain related anomalies. Some typical problems associated with file designs are:
  • unnecessary Transient (T) files, which are developed for operational convenience, but serve no real logical purpose
  • redundancy, where the same data is held on several files
  • illogical files, which contain totally unrelated data
  • ambiguous files, which cover multiple data subject areas.
The purpose of this step is to identify the problems associated with the existing file structures.
The logicalization of datastores will provide a basis for redefining and streamlining the systems processes.
It is not a direct input to the process of rigorous physical design of the files/database to be used in the required system - a task addressed later in the project.
Outlined below are the steps necessary to convert the current physical datastores to logical datastores:
Review Transient (T) Datastores
Redefine Datastores by Reference to the Data Model
Replace Datastores on the Current Data Flow Diagram

Process GuidePrevious - Step 1:  Convert Datastores (Physical to Logical)Next - Redefine Datastores by Reference to the Data ModelGlossaryShortcutSummaryUp - Step 1:  Convert Datastores (Physical to Logical)

Step 1: Convert Datastores (Physical to Logical)

Review Transient (T) Datastores
Transient files are normally introduced when there is a time delay between processes or a performance pay-back in batch processing.
"T" type datastores are reviewed in order to check that they are logically required. This is done by applying two tests:
  • "Does the receiving process "require" multiple (batched) records as input?"
  • "Is there a genuine business reason for a time delay between the two processes?"

Process GuidePrevious - Review Transient (T) DatastoresNext - Replace Datastores on the Current Data Flow DiagramGlossaryShortcutSummaryUp - Step 1:  Convert Datastores (Physical to Logical)

Step 1: Convert Datastores (Physical to Logical)

Redefine Datastores by Reference to the Data Model
The current physical Datastores may contain badly organized or redundant data. This will be highlighted when the Physical Datastore/Entity Cross-Reference table is drawn up.
To prevent such a situation being carried forward into the new system, the Datastores must be re-organized logically.
The files needed to reflect the data accurately within the application can be determined from the Current Data Model.
There are three rules that must be applied:
  • an entity must be represented in only one logical datastore.
  • all entities in a datastore should be related (a Datastore may contain one or several entities).
  • a datastore should, wherever possible, cover only one data subject, e.g. Customer, Product, etc.
The physical datastores shown on the Data Flow Diagrams are replaced with the entity or group of entities shown on the Data Model. (Note that this Data Model has no redundancy, i.e. each entity occurs only once).
Rather than re-draw the Data Flow Diagram showing entities and collections of entities instead of datastores, the Data Model is divided into a set of "subject" clusters. Each cluster will represent a "logical" datastore.
The Data Flow Diagram is modified to show these logical datastores instead of physical ones.

Process GuidePrevious - Redefine Datastores by Reference to the Data ModelNext - Step 2:  Convert Dataflows (Physical to Logical)GlossaryShortcutSummaryUp - Step 1:  Convert Datastores (Physical to Logical)

Step 1: Convert Datastores (Physical to Logical)

Replace Datastores on the Current Data Flow Diagram
Revise the datastores on the Data Flow Diagram to reflect the entity sub-structures they represent.
This is done by replacing the "current physical" datastores shown on the Data Flow Diagram with the "logical" datastores that have been defined.
To achieve this, it may be necessary to combine or split dataflows.
Logical datastores should all be given the "D" prefix.

Process GuidePrevious - Replace Datastores on the Current Data Flow DiagramNext - Rename the DataflowsGlossaryShortcutSummaryUp - Logical Data Flow Diagram Steps

Logical Data Flow Diagram Steps

Step 2: Convert Dataflows (Physical to Logical)

Many of the redundant dataflows would have been removed in the previous step.
In order to resolve any remaining anomalies, the dataflows must first be renamed to reflect the actual data being passed.
Any duplicate flows can then be removed.
Rename the Dataflows
Remove Redundant Dataflows

Process GuidePrevious - Step 2:  Convert Dataflows (Physical to Logical)Next - Remove Redundant DataflowsGlossaryShortcutSummaryUp - Step 2:  Convert Dataflows (Physical to Logical)

Step 2: Convert Dataflows (Physical to Logical)

Rename the Dataflows
Provided below is a checklist of the things to consider when renaming dataflows:
  • remove references to the physical media used to transport data
  • convert goods flows into dataflows which reflect the information derived
  • remove unnecessary 'adjectives' describing the physical state of data (e.g. sorted, key-punched, etc.).

Process GuidePrevious - Rename the DataflowsNext - Step 3:  Convert Processes (Physical to Logical)GlossaryShortcutSummaryUp - Step 2:  Convert Dataflows (Physical to Logical)

Step 2: Convert Dataflows (Physical to Logical)

Remove Redundant Dataflows
Redundant dataflows appear in two forms.
  • Duplicate dataflows - in situations where dataflows containing the same information are input to a process, the redundant flows can be removed.
  • Unnecessary dataflows are more difficult to identify. The processes should be reviewed to ensure that the dataflows are both necessary and sufficient to complete the process.
In order to discover redundancy in dataflows, the data contained in each flow must be defined. Producing a list of the content of each flow helps to highlight redundancy.

Process GuidePrevious - Remove Redundant DataflowsNext - Redundant ProcessesGlossaryShortcutSummaryUp - Logical Data Flow Diagram Steps

Logical Data Flow Diagram Steps

Step 3: Convert Processes (Physical to Logical)

The final Logical Data Flow Diagram Step is to remove possible problems associated with the processes. This involves reviewing each process for the following types of problem:
Redundant Processes
Incorrect or Unnecessary Functional Division
Illogical Sequencing of Processes
Unnecessary Processing Cycles

Process GuidePrevious - Step 3:  Convert Processes (Physical to Logical)Next - Incorrect or Unnecessary Functional DivisionGlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Redundant Processes
This activity ensures that each process either:
  • validates an input dataflow, or
  • logically changes a dataflow or datastore.
Any process which does not satisfy the above conditions, should be removed from the Data Flow Diagram because they are a feature of the current environment and do not support the business.
At this point, the remaining processes are renamed to reflect the actual activity performed and references to physical locations are removed.

Process GuidePrevious - Redundant ProcessesNext - Illogical Sequencing of ProcessesGlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Incorrect or Unnecessary Functional Division
This activity may result in merging Data Flow Diagram processes (in a similar way to that employed when avoiding 'giant' Data Flow Diagrams) in order to improve functional division.
The rationale for deciding which processes to combine is as follows:
  • two processes driven by the same input should be combined
  • trivial processes should be merged with other preceding or succeeding processes.

Process GuidePrevious - Incorrect or Unnecessary Functional DivisionNext - Unnecessary Processing CyclesGlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Illogical Sequencing of Processes
The rule to be applied for this step is that sequencing of processes is only necessary when:
  • the preceding process provides, alters or stores information necessary to the subsequent processes
  • the preceding process verifies or checks the data used by the processes that succeed it.

Process GuidePrevious - Illogical Sequencing of ProcessesNext - TutorialGlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Unnecessary Processing Cycles
Systems will frequently have physical processing cycles associated with them. Such processing cycles are concessions to implementation constraints and should be removed.
Processes that are carried out daily, weekly, or monthly in the current system may be constrained by the current physical organization and not by the requirements of logical processing (e.g. a picking list may not be produced until a certain number of orders to be filled are received).
However, if the processing cycle represents a business or legislative constraint upon the system (e.g. end of year accounting, weekly payroll, etc.) it should be retained.

Process GuidePrevious - Unnecessary Processing CyclesNext - Level 1 Data Flow DiagramsGlossaryShortcutSummaryUp - Data Flow Diagrams

Data Flow Diagrams

Tutorial

Level 1 Data Flow Diagrams
Leveled Data Flow Diagrams
Logical Data Flow Diagrams

Process GuidePrevious - TutorialNext - Overview of TutorialGlossaryShortcutSummaryUp - Tutorial

Tutorial

Level 1 Data Flow Diagrams

Overview of Tutorial
Step 1: List Key Flows of Information
Step 2: Create Initial Data Flow Diagram
Step 3: Agree System Boundary
Step 4: Identify Processes and Datastores
Step 5: Complete the Level 1 Data Flow Diagram
Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning

Process GuidePrevious - Level 1 Data Flow DiagramsNext - Step 1:  List Key Flows of InformationGlossaryShortcutSummaryUp - Level 1 Data Flow Diagrams

Level 1 Data Flow Diagrams

Overview of Tutorial

A simple order processing system is developed to illustrate the process. The systems operation can be described as follows:
  • customers send in Sales Orders which are received and batched by the Customer Service department
  • batches are passed to the Data Entry department where they are key punched and submitted to a computer system
  • the system first validates the Sales Orders, rejects errors, and produces a validation report for Customer Service
Customer Service uses the report to identify errors, correct the original Sales Orders, and send the corrected Sales Orders to Data Entry as re-input Sales Orders
  • the computer system checks inventory availability and Customer balances. Orders that cannot be fulfilled are stored as Pending Orders for re-cycling. Fulfilled orders are written to an Invoice Detail file, Picking Lists are sent to the Warehouse, and Consignment notes are sent to the Shipping department
  • when making up consignments from the Consignment Notes, the Shipping department may discover that discrepancies exist between the quantity of goods picked and the consignment notes. When this occurs they adjust the notes and make on-line adjustments to the Invoice Details, the Inventory files and to Customer balances
  • when these adjustments have been made, the computer system produces Sales Invoices which are sent to Customers. The system also passes receivable debits to the Accounting department.

Process GuidePrevious - Overview of TutorialNext - Step 2:  Create Initial Data Flow DiagramGlossaryShortcutSummaryUp - Level 1 Data Flow Diagrams

Level 1 Data Flow Diagrams

Step 1: List Key Flows of Information

Assume that the following are relevant to the example:
  • sales order form
  • re-input sales order (after error correction)
  • validation report
  • picking list
  • consignment note
  • sales invoice
  • data prepared sales orders
  • receivable debits.
Examples of documents that typically would have been left out of the above list include:
  • customer name and address changes
  • product data amendments
  • price changes
  • inventory movements.
The sending and receiving locations appear to be:
  • customer
  • customer service
  • data entry
  • computer system
  • warehouse
  • shipping
  • accounting.

Process GuidePrevious - Step 1:  List Key Flows of InformationNext - Step 3:  Agree System BoundaryGlossaryShortcutSummaryUp - Level 1 Data Flow Diagrams

Level 1 Data Flow Diagrams

Step 2: Create Initial Data Flow Diagram

Is it reasonable that the Shipping department only receives documents but does not output anything?
In fact, the Warehouse sends the picked goods to the Shipping department. The Shipping department sends corrected Consignment Notes with the goods to the Customer and updates the computer system with Consignment Adjustments.

Process GuidePrevious - Step 2:  Create Initial Data Flow DiagramNext - Step 4:  Identify Processes and DatastoresGlossaryShortcutSummaryUp - Level 1 Data Flow Diagrams

Level 1 Data Flow Diagrams

Step 3: Agree System Boundary

The scope of the system may include most of the following areas:
  • customer service
  • data entry
  • warehouse
  • shipping
  • computer system.
Some of these areas are only partially within the system boundary:
  • data entry
  • warehouse
  • shipping.


Process GuidePrevious - Step 3:  Agree System BoundaryNext - Step 5:  Complete the Level 1 Data Flow DiagramGlossaryShortcutSummaryUp - Level 1 Data Flow Diagrams

Level 1 Data Flow Diagrams

Step 4: Identify Processes and Datastores

Starting with Sales Order Forms, these documents are sent by Customers to Customer Service where they are received and sorted into batches. The flow becomes:
"Are any files used in the process?"
In this case the answer is "no."
The document flow at the end of Step 3, can be used to assist in considering each document and adding a "generating" and/or "receiving" process.
Take each document in turn to build up the Level 1 Data Flow Diagram in this way.
When considering the third process and asking the question "does the process use or output any datastores?", it is discovered that in this case the Validate process uses both Customer and Product Files. These are added to the diagram at this stage.

Process GuidePrevious - Step 4:  Identify Processes and DatastoresNext - Question 1 - GlossaryShortcutSummaryUp - Level 1 Data Flow Diagrams

Level 1 Data Flow Diagrams

Step 5: Complete the Level 1 Data Flow Diagram

Question 1 - "How does Process 5, 'Check Inventory and Price', obtain Sales Order Data?"
Answer 1 - "A temporary datastore of Validated Sales Orders."
Question 2 - "From where does Process 8, 'Adjust Consignment Notes',get its data?"
Answer 2 - "A dataflow from Process 7 'Create Consignment'."
Question 3 - "Does 'Create Invoices', Process 9, require only Invoice Details as input?"
Answer 3 - "Process 9 also requires Customer Names and Addresses from the Customer datastore Create Invoices."

Process GuidePrevious - Step 5:  Complete the Level 1 Data Flow DiagramNext - Answer 1 - GlossaryShortcutSummaryUp - Step 5:  Complete the Level 1 Data Flow Diagram

Step 5: Complete the Level 1 Data Flow Diagram

Question 1 - "How does Process 5, 'Check Inventory and Price', obtain Sales Order Data?"

Process GuidePrevious - Question 1 - Next - Question 2 - GlossaryShortcutSummaryUp - Step 5:  Complete the Level 1 Data Flow Diagram

Step 5: Complete the Level 1 Data Flow Diagram

Answer 1 - "A temporary datastore of Validated Sales Orders."

Process GuidePrevious - Answer 1 - Next - Answer 2 - GlossaryShortcutSummaryUp - Step 5:  Complete the Level 1 Data Flow Diagram

Step 5: Complete the Level 1 Data Flow Diagram

Question 2 - "From where does Process 8, 'Adjust Consignment Notes',get its data?"

Process GuidePrevious - Question 2 - Next - Question 3 - GlossaryShortcutSummaryUp - Step 5:  Complete the Level 1 Data Flow Diagram

Step 5: Complete the Level 1 Data Flow Diagram

Answer 2 - "A dataflow from Process 7 'Create Consignment'."

Process GuidePrevious - Answer 2 - Next - Answer 3 - GlossaryShortcutSummaryUp - Step 5:  Complete the Level 1 Data Flow Diagram

Step 5: Complete the Level 1 Data Flow Diagram

Question 3 - "Does 'Create Invoices', Process 9, require only Invoice Details as input?"

Process GuidePrevious - Question 3 - Next - Step 6:  Check for Consistency, Completeness and Effectiveness of PartitioningGlossaryShortcutSummaryUp - Step 5:  Complete the Level 1 Data Flow Diagram

Step 5: Complete the Level 1 Data Flow Diagram

Answer 3 - "Process 9 also requires Customer Names and Addresses from the Customer datastore Create Invoices."

Process GuidePrevious - Answer 3 - Next - Question 1 - What happens to Valid Sales Orders for which there is no Inventory?GlossaryShortcutSummaryUp - Level 1 Data Flow Diagrams

Level 1 Data Flow Diagrams

Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning

In the example provided, a completeness check will indicate the following:
Question 1 - What happens to Valid Sales Orders for which there is no Inventory?
Answer 1 - The Check Inventory and Price process (process 5), has as both input and output a re-cycling Pending Order datastore
Question 1 - What happens to the original Sales Order Forms?
Answer 1 - The original Sales Orders, once data prepared (process 2), are stored in a manual datastore and used in the Correction process (process 4).

Process GuidePrevious - Step 6:  Check for Consistency, Completeness and Effectiveness of PartitioningNext - Answer 1 - The Check Inventory and Price process (process 5), has as both input and output a re-cycling Pending Order datastoreGlossaryShortcutSummaryUp - Step 6:  Check for Consistency, Completeness and Effectiveness of Partitioning

Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning

Question 1 - What happens to Valid Sales Orders for which there is no Inventory?

Process GuidePrevious - Question 1 - What happens to Valid Sales Orders for which there is no Inventory?Next - Leveled Data Flow DiagramsGlossaryShortcutSummaryUp - Step 6:  Check for Consistency, Completeness and Effectiveness of Partitioning

Step 6: Check for Consistency, Completeness and Effectiveness of Partitioning

Answer 1 - The Check Inventory and Price process (process 5), has as both input and output a re-cycling Pending Order datastore

Process GuidePrevious - Answer 1 - The Check Inventory and Price process (process 5), has as both input and output a re-cycling Pending Order datastoreNext - Step 2:  Identify Lower Level Processes and DatastoresGlossaryShortcutSummaryUp - Tutorial

Tutorial

Leveled Data Flow Diagrams

Step 2: Identify Lower Level Processes and Datastores
Step 3: Balance Lower Level DFD with Higher Level DFD

Process GuidePrevious - Leveled Data Flow DiagramsNext - Initial Level 2 Diagram For Process 5GlossaryShortcutSummaryUp - Leveled Data Flow Diagrams

Leveled Data Flow Diagrams

Step 2: Identify Lower Level Processes and Datastores

Initial Level 2 Diagram For Process 5
Question 1 - "Does the Process 5 feed Picking Lists and Consignment Notes directly into Processes 6 and 7?"
Question 2 - "Is there anything else missing from the process?"
Question 3 - "Is the Pending Order file, D5, used only within the Check Inventory and Price process?"
Final Level 2 Diagram for Process 5

Process GuidePrevious - Step 2:  Identify Lower Level Processes and DatastoresNext - Question 1 - GlossaryShortcutSummaryUp - Step 2:  Identify Lower Level Processes and Datastores

Step 2: Identify Lower Level Processes and Datastores

Initial Level 2 Diagram For Process 5

Process GuidePrevious - Initial Level 2 Diagram For Process 5Next - Question 2 - GlossaryShortcutSummaryUp - Step 2:  Identify Lower Level Processes and Datastores

Step 2: Identify Lower Level Processes and Datastores

Question 1 - "Does the Process 5 feed Picking Lists and Consignment Notes directly into Processes 6 and 7?"

Process GuidePrevious - Question 1 - Next - Question 3 - GlossaryShortcutSummaryUp - Step 2:  Identify Lower Level Processes and Datastores

Step 2: Identify Lower Level Processes and Datastores

Question 2 - "Is there anything else missing from the process?"
Answering the second question reveals that when Balance Failures occur in Process 5.4, the system creates a temporary file of failures that is later processed to produce a "Credit Failure" report which is sent to the Accounting department.

Process GuidePrevious - Question 2 - Next - Final Level 2 Diagram for Process 5GlossaryShortcutSummaryUp - Step 2:  Identify Lower Level Processes and Datastores

Step 2: Identify Lower Level Processes and Datastores

Question 3 - "Is the Pending Order file, D5, used only within the Check Inventory and Price process?"
The third question, concerning the "Pending Order" file, highlights the point that a datastore, shown on a Level 1 Data Flow Diagram, must be shared by more than one process.
In the example, the "Pending Order" file is used wholly within the "Check Inventory and Price" process, and thus becomes an internal datastore.

Process GuidePrevious - Question 3 - Next - Step 3:  Balance Lower Level DFD with Higher Level DFDGlossaryShortcutSummaryUp - Step 2:  Identify Lower Level Processes and Datastores

Step 2: Identify Lower Level Processes and Datastores

Final Level 2 Diagram for Process 5

Process GuidePrevious - Final Level 2 Diagram for Process 5Next - Logical Data Flow DiagramsGlossaryShortcutSummaryUp - Leveled Data Flow Diagrams

Leveled Data Flow Diagrams

Step 3: Balance Lower Level DFD with Higher Level DFD

After inclusion of the changes introduced by the expansion of the "Check Inventory and Price" process, the Level 1 Data Flow Diagram will have to be modified accordingly.

Process GuidePrevious - Step 3:  Balance Lower Level DFD with Higher Level DFDNext - Overview of TutorialGlossaryShortcutSummaryUp - Tutorial

Tutorial

Logical Data Flow Diagrams

Overview of Tutorial
Step 1: Convert Datastores (Physical to Logical)
Step 2: Convert Dataflows (Physical to Logical)
Step 3: Convert Processes (Physical to Logical)

Process GuidePrevious - Logical Data Flow DiagramsNext - Step 1:  Convert Datastores (Physical to Logical)GlossaryShortcutSummaryUp - Logical Data Flow Diagrams

Logical Data Flow Diagrams

Overview of Tutorial

In order to illustrate these steps, an example based on an order processing Data Flow Diagram is provided.
The Data Flow Diagram is the same as the one developed in the section on Level 1 Data Flow Diagrams, except that the "Pending Order" datastore and amendment process have been added to provide an example of logicalizing datastores.
An "Adjust Inventory Quantity" process box has also been added to demonstrate the logicalization of processes.
A Data Model has been provided to assist in the process.

Process GuidePrevious - Overview of TutorialNext - Review Transient (T) DatastoresGlossaryShortcutSummaryUp - Logical Data Flow Diagrams

Logical Data Flow Diagrams

Step 1: Convert Datastores (Physical to Logical)

Review Transient (T) Datastores
Redefine Datastores by Reference to the Data Model

Process GuidePrevious - Step 1:  Convert Datastores (Physical to Logical)Next - Redefine Datastores by Reference to the Data ModelGlossaryShortcutSummaryUp - Step 1:  Convert Datastores (Physical to Logical)

Step 1: Convert Datastores (Physical to Logical)

Review Transient (T) Datastores
The creation of picking lists requires batched input and needs a transient file.
The creation of consignment notes, on the other hand, requires neither batched input nor a time delay between the processes.
Therefore, the Data Flow Diagram should be modified to show this.
The result is the separation of the "Create Picking Lists" and "Create Consignment Note" processes, with consignment note data going directly to the latter process.

Process GuidePrevious - Review Transient (T) DatastoresNext - D1 CustomersGlossaryShortcutSummaryUp - Step 1:  Convert Datastores (Physical to Logical)

Step 1: Convert Datastores (Physical to Logical)

Redefine Datastores by Reference to the Data Model
D1 Customers
D2 Products and Prices
D3 Inventory
D4 Invoice Details and D5 Pending Orders

Process GuidePrevious - Redefine Datastores by Reference to the Data ModelNext - D2 Products and PricesGlossaryShortcutSummaryUp - Redefine Datastores by Reference to the Data Model

Redefine Datastores by Reference to the Data Model

D1 Customers
Existing Datastore is Logical

Process GuidePrevious - D1 CustomersNext - D3 InventoryGlossaryShortcutSummaryUp - Redefine Datastores by Reference to the Data Model

Redefine Datastores by Reference to the Data Model

D2 Products and Prices
Existing Datastore is Logical

Process GuidePrevious - D2 Products and PricesNext - D4 Invoice Details and D5 Pending OrdersGlossaryShortcutSummaryUp - Redefine Datastores by Reference to the Data Model

Redefine Datastores by Reference to the Data Model

D3 Inventory
Existing Datastore is Logical

Process GuidePrevious - D3 InventoryNext - Step 2:  Convert Dataflows (Physical to Logical)GlossaryShortcutSummaryUp - Redefine Datastores by Reference to the Data Model

Redefine Datastores by Reference to the Data Model

D4 Invoice Details and D5 Pending Orders
In the above illustration, the Order Line entity is represented in two datastores, (the rule states that an entity can belong to only one datastore).
Also, the Invoice Detail datastore contains a significant amount of Sales Order data.
The logical solution is to create a single datastore from Invoice details and Pending Orders.
The logical datastore resulting from this combination would be represented on the Data Model as the following sub-structure.

Process GuidePrevious - D4 Invoice Details and D5 Pending OrdersNext - Rename DataflowsGlossaryShortcutSummaryUp - Logical Data Flow Diagrams

Logical Data Flow Diagrams

Step 2: Convert Dataflows (Physical to Logical)

Rename Dataflows
Redundant Flows

Process GuidePrevious - Step 2:  Convert Dataflows (Physical to Logical)Next - Redundant FlowsGlossaryShortcutSummaryUp - Step 2:  Convert Dataflows (Physical to Logical)

Step 2: Convert Dataflows (Physical to Logical)

Rename Dataflows

Process GuidePrevious - Rename DataflowsNext - Step 3:  Convert Processes (Physical to Logical)GlossaryShortcutSummaryUp - Step 2:  Convert Dataflows (Physical to Logical)

Step 2: Convert Dataflows (Physical to Logical)

Redundant Flows
Note that the filled orders passed to Process 13, "Create Consignment Notes", contains the Customer name and address (left hand side of diagram). Assuming that this data is available in the Customer datastore, it should logically be passed to the process from there, rather than through the "Check Inventory and Price" process (right hand side of diagram).

Process GuidePrevious - Redundant FlowsNext - Remove Redundant ProcessesGlossaryShortcutSummaryUp - Logical Data Flow Diagrams

Logical Data Flow Diagrams

Step 3: Convert Processes (Physical to Logical)

Remove Redundant Processes
Incorrect or Unnecessary Functional Division
Illogical Sequencing of Processes
Unnecessary Processing Cycles

Process GuidePrevious - Step 3:  Convert Processes (Physical to Logical)Next - Incorrect or Unnecessary Functional DivisionGlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Remove Redundant Processes
Processes 1 and 2 are removed because they neither validate the dataflows, nor logically change dataflows or datastores.

Process GuidePrevious - Remove Redundant ProcessesNext - Illogical Sequencing of ProcessesGlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Incorrect or Unnecessary Functional Division
Processes 9 and 11 are separated only because of a difference in location (i.e. Dispatch and Inventory departments). Logically, they should be combined.
The "Create Consignment" process, (process 7), in data processing terms, only adds actual quantities to the consignment details. It can therefore be merged with Process 11.

Process GuidePrevious - Incorrect or Unnecessary Functional DivisionNext - Unnecessary Processing CyclesGlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Illogical Sequencing of Processes
It is logically correct for the order to be validated prior to being filled; this sequence must be retained. Note that no occurrence of illogical sequencing exists in the example.

Process GuidePrevious - Illogical Sequencing of ProcessesNext  (disabled)GlossaryShortcutSummaryUp - Step 3:  Convert Processes (Physical to Logical)

Step 3: Convert Processes (Physical to Logical)

Unnecessary Processing Cycles
In the previous example, there was no business constraint that specifically required the balance failures to be reported on a particular cycle, i.e. weekly, or monthly, etc., so this processing cycle could be removed, as shown below.