Chapter 7 of Modern Systems Analysis and Design was all about process modeling and data flow diagrams. My biggest takeaway is that DFDs are an important way to map requirements and processes to allow for further analysis. The context diagram gives an overview of the system, while level-n DFD diagrams progressively break down the processes.
There are two standard sets of symbols used in data flow diagrams. However, overall best practices can be universal. DFDs contain data stores, processes, and sources/sinks. A data store is data at rest. It can be a physical location. A process is the actions performed on data. It can be done manually or by a computer. A source/sink is the origin and/or destination of data. They are outside of the system.
The following are important concepts to remember when creating data flow diagrams:
- Completeness – need to have all the necessary components for the system, everything should be labeled and described
- Consistency – the depictions of the system at the different levels must be compatible
- Timing – DFDs can’t display time so draw them as if the system has never started and will never stop
- Iterative Development – the first DFD will rarely capture everything so it’s important to keep improving
- Primitive DFDs – deciding when to stop decomposing processes, one rule is to stop drawing when you have reached the lowest logical level
It’s also important to remember the DFD rules (e.g. no process can have only outputs.)
An important takeaway I learned in this week assignment for Chapter 7 was how to model and analyze 2 important views of an information system:
– the flow of data between manual or automated steps and
– he decision logic of processing data. None of the techniques discussed so far, however, has concentrated on the data that must be retained in order to support the data flows and processing described
In reality, some systems developers believe that a data model is the most important part of the statement of information system requirements. This belief is based on the following reasons. First, the characteristics of data captured during data modeling are crucial in the design of databases programs. I also learned that data, not processes, are the most complex aspects of many modern information systems and hence require a central role in structuring system requirements. According to the chapter 7, the characteristics about data such as format, length or relationships are reasonably permanent and have significant similarity for different organizations in the same business
I also thought it was interesting that the book brought up how data modeling is often more complex than modeling processes. I’m sure that’s not the case for every single system but usually true. Either way, you can’t get away with doing one or the other. Requirements gathering and analysis is all about being comprehensive and thorough. Different types of diagrams give you different ways to look at a system and conceptualize its requirements.
DFDs are versatile diagramming tools which can represent both physical and logical information systems with four symbols. The four symbols represent data flows, data stores, processes, and sources/sinks. The chapter also talks about the guidelines for drawing DFDs. The guidelines are completeness, consistency, timings considerations, the iterative nature of drawing DFDs, and primate DFDs. Completeness refers to whether all the components that are necessary for the system are included in the DFDs. In addition, each of the components must be fully described in the project dictionary. Consistency refers to the information contained on one level of a set of data-flow diagrams is also included on other levels.
A key focus of this unit’s reading was the concept of the Data Flow Diagram (DFD). DFD is a form of process modeling, which is a way of graphically representing the functions or processes of an organization. DFDs are often used to study and document the processes of an organization, which makes them especially useful when determining the requirements of a system. One benefit of DFDs that make them so useful is their versatility and simplicity. DFDs can describe a variety of systems using only four systems: data store, process, source/sink, and data flow. Personally, the main value I see in DFDs is their hierarchical nature. Each level of a DFD can be expanded into a lower-level DFD diagram. I find this incredibly useful, especially for systems in which an analyst would need to understand the system on both a high-level and a low-level. This is called DFD decomposition.
Taylor,
I thought that you did a very good job explaining what the DFD is, what they are used for, and the benefits of using a DFD. I also liked how you mentioned the DFD decomposition. I also think that the DFD is a very helpful tool that will help the team see in a flowchart, the process, that they would like to create, think that have or actually have.
I learned in this week and understand DFD. Data flow diagrams are used to graphically represent the flow of data in a business information system. DFD describes the processes that are involved in a system to transfer data from the input to the file storage and report generation. Data flow diagrams can be divided into logical and physical. The logical data flow diagram describes the flow of data through a system to perform certain functions of a business. The physical data flow diagram describes the implementation of the logical data flow.
DFD graphically representing the functions, or processes, which capture, manipulate, store, and distribute data between a system and its environment and between components of a system. The visual representation makes it a good communication tool between the User and the System designer. The structure of DFD allows starting from a broad overview and expand it to a hierarchy of detailed diagrams. DFD has often been used due to the following reasons:
Logical information flow of the system; Determination of physical system construction requirements; Simplicity of notation; Establishment of manual and automated systems requirements
DFD maps out the flow of information for any process or system graphically. It uses defined symbols such as circles, rectangles, arrows, etc. They can be used to analyze an existing system or model a new one. DFD can often visually say things that would be hard to explain to technical and nontechnical audiences, from developer to CEO.
The use of data flow diagram is to represent the information gathered as part of requirements determination phase. It helps the analyst to map the flow of data throughout the information system, relationship between the data, and process of data stored. The data flow diagram (DFD) happens during requirements structuring. It requires that analysts organize the information into a meaningful representation of the information system that currently exists and of the requirements desired in a replacement system. The DFD should be designed to show the shows the scope of the system, specify which processes move and transform data, illustrate important concepts about the movement of data between manual and automated steps, depict workflow. The process modeling should demonstrate what you learned from the system requirements determination.
The one of key points I want to discuss in chapter 7 how the three key parts affect the decision table. The first part is condition stubs that have relevant conditions to the decision and apply to different situations. Then, the action stubs show all possible actions that result from the exit condition stubs. Last, the rules present specific actions that are linked to relevant conditions, and they could be shown as text or numeric. By making an effective decision, the decision table with these key parts can let the management determine appropriate actions in a particular set of conditions. This decision table can also help the management to ignore some inefficient actions, which are redundancy. In implementing successful decision tables, we can use the relatively complicated logic of a process to review the extent, which the logic is completed.
The data flow diagram is a tool used in structured analysis methods. It graphically depicts the process of data flow and processing in the system. Since it only reflects the logical functions that the system must complete, it is a functional model. In the structured development method, the data flow diagram is the result of the requirements analysis phase.
Data Flow Diagram or Data Flow Diagram abbreviated as DFD. Data flow diagram DFD is a graphical tool to describe the data flow in the system. It marks the logical input and logical output of a system and the processing required to convert the logical input to the logical output.
It is worth noting that the data flow diagram is not a traditional flowchart or block diagram, and the data flow is not a control flow. The data flow diagram describes a system from the perspective of data, while the block diagram describes the system from the perspective of the staff who processes the data.
Keep in mind the definition can slightly change for a DFD depending on if we are discussing the business or the software.
In Business Analysis — DFD is used for the assessment of existing and projected systems and its elements. Diagramming provides a useful toolset for exposing possible weaknesses and structural flaws.
In Software Development — DFD is used to explain and visualize the requirements of the projects — from the business perspective and a technical point of view. This feature allows hatching through and through step by step plan for the development of each element.