Chapter 4: Documenting Information Systems

Two types of systems documentation are:

1. Data flow diagrams 2. Systems flowcharts

Actvity:

Actions related to data (send data, transform data, file or store data, retrieve data from storage, or receive data) Operations process activities including picking goods, inspecting goods at a receiving dock, or counting cash.

Internal Entity

An entity within the system that transforms data.

(T/F) A customer is an example of an internal entity.

False

(T/F) In a data flow diagram (DFD), a square represents an internal entity.

False

(T/F) The advantage of a physical data flow diagram (DFD) versus a logical data flow diagram (DFD) is that we can concentrate on what activities a system is performing without having to specify how, where, or whom.

False

Systems Flowchart

Graphical representation of a business process, including information processes, as well as the related operations processes (people, equipment, organization, and work activities). Presents a logical and physical rendering of the who, what, how, and where of information and operations processes. Depicts the sequence of activities performed as business events flow through the process.

Physical Data Flow Diagram (DFD)

Graphical representation of a system showing the system's internal and external entities, and the flows of data into and out of these entities. Specified where, how, and by whom a system's processes are accomplished. Internal Entity: An entity within the system that transforms data.

Logical Data Flow Diagram (DFD)

Graphical representation of a system showing the system's processes (as bubbles), data stores, and the flows of data into and out of the processes and data stores. Specifies what activities the system is performing Logical DFDs portray a system's activities.

Exception Routines or Error Routines

Handle required actions for out-of-the-ordinary (exceptional) or erroneous events data. Documented below the level 0 DFD with reject stubs that indicate exceptional processing must be performed.

Reject Stub

Is a data flow assigned the label "Reject" that leaves a bubble but does not go to any other bubble or data store. Shown only in lower-level diagrams.

Context Diagram

Least detailed picture of a system that defines the process being documented and shows the data flows into and out of the process to external entities.

Information Processing Actities:

Retrieve data from storage, transform data, or file data.

Data flow diagrams (DFDs)

Show business processes, flows of data within those processes, and the sources and storage of the data required for the process. Depict systems components. Data flows among components, and the sources. Destinations. Storage of data. Use a limited number of symbols.

External Entities

Those entities (i.e., persons, places, or things) outside the system that send data to, or receive data from, the system.

(T/F) Data flow diagrams (DFDs) depicts a system's components; the data flows among the components; and the sources, destinations, and storage of data.

True

(T/F) Flowcharts are commonly used for new systems implementations, business process reengineering, finance function transformations, and assessments of internal controls.

True

(T/F) In a data flow diagram (DFD), an external entity symbol portrays a source or a destination of data outside the system.

True

(T/F) Information processing activities retrieve data from storage, transforms data, or file data.

True

(T/F) Processes that handle other-than-normal situations are called exception routines.

True

Balanced

When two DFDs have equivalent external data flows. Only balanced set of DFDs (i.e., context diagram, a logical DFD, and a physical DFD) are correct.

Preparing Systems Flowcharts:

1. Divide the flowchart into columns; one column for each internal entity and one for each external entity. Label each column. 2. Flowchart columns should be laid out so that the flowchart activities flow from left to right. Minimize crossed lines and connectors. 3. Flowchart logic should flow from top to bottom and from left to right. For clarity, put arrows on all flow lines. 4. Keep the flowchart on one page, if possible. Use off-page connectors if multiples pages are required. 5. Within each column, there must be at least one manual process, keying operation, or data store between documents. 6. When crossing organizational lines show a document at both ends of the flow line unless the connection is so short that the intent is unambiguous. 7. Documents or reports printed in a computer facility should be shown in that facility's column first. You can then show the document or report going to the destination unit. 8. Documents or reports printed by a centralized computer facility on equipment located in another organizational unit should not be shown within the computer facility. 9. Processing within an organizational unit on devices such as a PC, laptop, or a computerized cash register should be shown within the unit or as a separate column next to that unit, but not in the central computer facility column. 10. Sequential processing steps with no delay between them (and resulting from the same input) can be shown as one process or as a sequence of processes. 11. The only way to get data into or out of a computer data storage unit is through a computer processing rectangle of offline process square. 12. A manual process is not needed to show the sending of a document. It should be apparent from the movement of the document. 13. Do not use manual processes to file documents. Show documents going into files.

Common Systems Flowcharting Routines:

1. Enter document into computer via keyboard, edit input, record input. 2. User queries the computer. 3. Update data store. 4. Key and key verify data. 5. Enter document via scanning 6. Enter journal in manual accounting system 7. Pick and ship goods

DFD Guidelines:

1. Include within the system context (bubble) any entity that performs one or more information processing activities. 2. For now, include only normal processing routines (NOT exception routines or error routines) on context diagrams, physical DFDs, and logical level 0 DFDs. 3. Include in the process documentation all (and only) activities and entities described in the systems narrative. 4. When multiple entities operate identically, depict only one to represent all. Drawing the current physical Data Flow Diagram 5. For clarity, draw a data flow for each flow into and out of a data store. Label each flow with the activity number that gives rise to the flow or with a description of the flow. 6. If a data store is logically necessary, include a data store in the diagrams, even if it not mentioned in the narrative. 7. Group activities if they occur in the same place and at the same time. 8. Group activities if they occur at the same time but in different places. 9. Group activities that seem to be logically related. 10. To make DFD readable, use between five and seven bubbles. Summary of Drawing Data Flow Diagrams 11. A data flow should go to an operations entity square when only operations process functions are to be performed by that entity. A data flow should enter an entity bubble if the operations process entity is to perform an information processing activity. 12. On a physical DFD, reading computer data stores and writing to computer data stores must go through a computer bubble 13. On a logical DFD, data flows cannot go from higher-to lower-numbered bubbles.