A system flowchart is a concrete, physical model that documents, in an easily visualized, graphical form, the system’s discrete physical components (its programs, procedures, files, reports, screens, etc.).
A system flowchart is a valuable presentation aid because it shows how the system’s major components fit together and interact. In effect, it serves as a system roadmap. During the information gathering stage, a system flowchart is an excellent tool for summarizing a great deal of technical information about the existing system. A system flowchart can also be used to map a hardware system.
System flowcharts are valuable as project planning and project management aids. Using the system flowchart as a guide, discrete units of work (such as writing a program or installing a new printer) can be identified, cost estimated, and scheduled. On large projects, the components suggest how the work might be divided into subsystems.
Historically, some analysts used system flowcharts to help develop job control language specifications. For example, IBM’s System/370 job control language requires an EXEC statement for each program and a DD statement for each device or file linked to each program. Consequently, each program symbol on the system flowchart represents an EXEC statement and each file or peripheral device symbol linked to a program by a flowline implies a need for one DD statement. Working backward, preparing a system flowchart from a JCL listing is good way to identify a program’s linkages.
A system flowchart’s symbols represent physical components, and the mere act of drawing one implies a physical decision. Consequently, system flowcharts are poor analysis tools because the appropriate time for making physical decisions is after analysis has been completed.
A system flowchart can be misleading. For example, an on-line storage symbol might represent a diskette, a hard disk, a CD-ROM, or some combination of secondary storage devices. Given such ambiguity, two experts looking at the same flowchart might reasonably envision two different physical systems. Consequently, the analyst’s intent must be clearly documented in an attached set of notes.
Here is a picture of how a system / process flow chart would look like:
