Information Systems Documentation PDF

INFORMATION SYSTEMS DOCUMENTATION (DIAGRAMS) ACC 351: Accounting Information Systems Instructor: Dr. M. Walters NOTES OUTLINE Systems Documentation Concepts  Systems Documentation  Diagram Elements  Systems Documentation  Diagram Symbols  Additional Concepts Preparing System Documentation  N...

INFORMATION SYSTEMS DOCUMENTATION (DIAGRAMS) ACC 351: Accounting Information Systems Instructor: Dr. M. Walters NOTES OUTLINE Systems Documentation Concepts  Systems Documentation  Diagram Elements  Systems Documentation  Diagram Symbols  Additional Concepts Preparing System Documentation  Narratives & Tables  Data Flow Diagrams  Systems Flowchart Walters Systems Documentation Notes 1 SYSTEMS DOCUMENTATION CONCEPTS Systems Documentation Systems documentation refers to an interrelated set of systems narratives, tables, and diagrams that “document” or represent how an information system (IS) works. Common documentation relevant to accountants includes narratives, tables, and diagrams such as business process diagrams, data flow diagrams, and flowcharts (Romney et al. 2024). Systems documentation clarifies and simplifies an information system (IS) to make it easier to understand, analyze, and assess. Systems documentation may be used to train users, design new systems, and/or audit IS processes/systems. Accountants (as IS users, designers, developers, and auditors) must understand systems documentation/diagrams at the following levels (Gelinas et al. 2018, Hall 2019, Romney et al. 2024): Read. Accountants must be able to read systems diagrams to understand how IS processes work. Analyze. Accountants must be able to analyze systems diagrams to assess the effectiveness, efficiency, data processing integrity, and/or control adequacy of IS processes (to support audit, advisory, and/or process analysis functions). Prepare. Accountants must be able to prepare systems diagrams to document and explain how a current or proposed process works. Diagram Elements Activities. Activity. An activity is an action/task performed for a specific purpose. For the purposes of preparing systems documentation, there are two basic types of activities, information processing and non-information processing activities. Information Processing Activity. An action/task performed to capture (enter, input), process (transform), maintain/store (organize, file, retrieve), or distribute (disseminate, report) information. Capture (Input) Activities. Include collecting, selecting, verifying, and entering data into a system. Processing (Transform) Activities. Include adding/altering, reviewing/verifying, updating/revising, and/or deleting/removing data. Data Maintenance (Storage) Activities. Include organizing, filing, accessing, and retrieving data. Data Distribution (Output) Activities. Include aggregating, summarizing, preparing, and distributing information. For example, all the following activities are information processing activities: analyzing, arranging, calculating/computing (e.g., adding, subtracting, multiplying, dividing), classifying, coding, documenting/reporting, entering/inputting, editing, filing/retrieving, sorting, summarizing, and verifying. Non-Information Processing Activity. An action/task performed to fulfill an operational aspect Walters Systems Documentation Notes 2  of the business or an activity/task that merely involves sending data to or receiving data from a system. Note the simple sending or receiving of data between entities is not considered an information processing task as such actions do not capture, process, maintain/store, or distribute data. However, note that “sends” and “receives” are distinguished from “files” and “retrieves” which are considered information processing activities (see above). Processes. Data Processing Cycle. Also referred to as the information processing cycle. Refers to the processes necessary to convert data into information and includes data capture (input), data processing (transform), data maintenance (store), and data distribution (output) processes. Process. A series or sequence of activities performed to accomplish a specific purpose. Note the process of interest is the focus for diagramming. Subprocess. Also referred to as a logical subprocess. A process is referred to as a subprocess when it is viewed relative to the larger process of which it is a part. A logical subprocess is group of logically related activities that accomplish a specific objective within a larger process. For diagramming purposes, logical subprocesses are constructed by grouping together logically related activities within a process (and then indicating these groupings on a table of entities and activities, see below). Logically related activities are generally performed consecutively, in closely related steps, and/or at the same time in the same place. Constructed logical subprocesses are used as a basis for constructing the logical DFD. Operations Process. A sequence of non-information processing activities performed to fulfill the central business function(s) of a business entity (i.e., selling, acquiring, producing). Operations processes perform the “work” function of a business entity and are necessary to ensure the organization fulfills its purpose. Information Process. A series of information processing activities performed to convert data into information (i.e., capture, processing, maintenance/storage, distribution). Information processes perform the “keeping track” function within a business entity and are necessary to track and support operations processes. Entities. Entity. An entity is an autonomously functioning person, (e.g., clerk, customer), place (e.g., department, office), or thing (e.g., computer) associated with an information system process. Internal Entity. An entity that performs an information processing activity (capture/enter, process, maintain/store, or distribute, see above) within the defined scope of analysis for the process to be analyzed. External Entity. An entity that does not perform an information processing activity (capture/enter, process, maintain/store, or distribute, see above) within the defined scope of analysis for the process to be analyzed. An external entity merely sends data to the system or receives data from the system but does not capture/enter data into the system, process data, maintain/update records/files, or prepare/distribute documents/reports. Walters Systems Documentation Notes 3  Whether an entity is considered internal or external depends on whether or not the entity performs an information processing activity within the defined scope of analysis for the process being diagrammed. Effectively diagramming a process requires defining a scope for the process by identifying both a starting point and a stopping point for the transaction activities to be diagrammed (see below for further discussion). Activities that fall outside the specified starting and stopping point are not diagrammed in detail, and entities that only perform activities outside the defined scope are considered external. For instance, if you are diagramming a cash receipts process involving three entities (a receipts clerk, a general ledger clerk, and the bank) and you have defined your scope to include activities from the point where the clerk receives payments to the point where the clerk deposits the payments at the bank (which excludes recording the deposit and the bank’s activities involved in processing the deposit), then the receipts clerk would be considered internal and both the general ledger clerk and the bank would be considered external because they fall outside the defined scope of the process. However, if you are diagramming the same cash receipts process and you have redefined your scope to include activities from the point where the clerk receives payments to the point where to the general ledger clerk records the deposit in the accounting records (which still excludes the bank’s activities involved in processing the deposit), then the receipts clerk and general ledger clerk would be considered internal but the bank would be considered external. Source. An entity that initiates and as such, represents the start of a process. The source acts as a starting point (or origin) for the process by “sending” data to the system/subsystem. The source may be an external entity OR an internal entity. Sink. An entity that concludes and as such, represents the end of a process. The sink acts as the ending point (or destination) for the process by “receiving” data from the system. The sink may be an external entity OR an internal entity. Flows. Data Flow. A data flow represents the transfer of data from one entity or subprocess to another entity or subprocess in a DFD. Data flows may be manual (i.e., physical) or electronic (i.e., digital). In a DFD, a data flow indicates the directionality of data transfers and the nature (e.g., payment) or form (e.g., cash) of the data as it flows from one entity or subprocess. Logical Flow. A logical flow indicates directionality of data or task flows within a system flowchart. In system flowchart, activities typically flow from top to bottom and left to right. Unidirectional Flow. A unidirectional flow is a data or task flow that goes only one direction. In system diagrams, a single-headed arrow is used to represent unidirectional flows with the arrowhead indicating one-way directionality. Multidirectional Flow. A multidirectional flow is a data or task flow that goes both directions (to/from). In system diagrams, two single-headed arrows with the arrowheads indicating two- way directionality (one to and one from) OR a double-headed arrow with arrowheads on both ends may be used to indicate multidirectional flows Walters Systems Documentation Notes 4 Documents, Files, and Reports. Documents. Refers to manual or electronic forms or instruments designed to support data processing. Documents may be source document, product documents, and/or turnaround documents. Files. Refers to a logically related set of records. A database is a centrally managed, logically related set of files. Reports. Refers to an account or summary of information in a standardized or non-standardized form. Systems Documentation A “full set” of systems documentation includes a system narrative, table of entities and activities, data flow diagrams (context, physical, logical), and a system process flowchart. Narratives & Tables. Systems Narrative. A system narrative is chronological, written step-by-step description of system entities, activities, data flows, documents, files, and reports for a specified system/process. The system narrative is generally written in prose form (like a story) with customary paragraph breaks; it contains paragraph and line numbers to facilitate analysis of the described system processes. Table of Entities & Activities. A table of entities and activities is a table that organizes the entities and processing activities described in the associated systems narrative in chronological order of occurrence. The table includes entities performing activities (internal and external), paragraph and line references (indicating paragraph in which and line on which the activity is described in the narrative), and activities (listed and numbered in chronological order of occurrence). Logical subprocesses are also notated on the table of entities and activities to provide the basis for preparing the logical DFD. The chronological table of entities and activities is used to organize significant data from the narrative to simplify and facilitate the preparation of systems diagrams. System Diagrams. System Diagram. A system diagram is a graphical (i.e., symbolic or pictorial) representation of system elements and/or processes; depending on the diagram, it may portray how an IS works and include the who, what, and/or how of IS processes. Key system diagrams include data flow diagrams and flowcharts. Data Flow Diagram (DFD). A data flow diagram (DFD) is a graphical representation of a process and its elements. A DFD portrays entities or subprocesses, data flows between entities or subprocesses, and file stores for a specified process. In a DFD, external entities are represented as boxes, internal entities and internal subprocesses are represented as bubbles, file stores are represented as double-lined symbols, and data flows are represented as directional arrows (see Exhibit 1 below). There are three basic types of DFDs, the context DFD, the physical DFD, and the logical DFD and each shows a different view of the system. Walters Systems Documentation Notes 5 Context Data Flow Diagram (Context DFD). The context DFD is a top-level (most general, least detailed) diagram that shows the boundary and external environment (i.e., the “context”) for the process it portrays. The focus of the context DFD is the process of interest (as a whole) and external data flows to/from the process (i.e., the context). The context DFD shows the process (as a whole), its external entities, and external data flows to/from the process (i.e., between the process and its external entities). The diagram consists of multiple boxes representing external entities (sources and sinks), a single bubble symbol representing the process as whole, and directional arrows representing external data flows to/from the process and external entities. The context DFD uses noun labels to describe the process (as a whole), external entities, and data flows. The context DFD does not show internal entities, internal processes, internal data flows, or file stores and does not use verb labels. Physical Data Flow Diagram (Physical DFD). The physical DFD shows who (persons or groups) or what (computers, devices) performs activities for the process it portrays. The focus of the physical DFD is internal entities and data flows between them. The physical DFD shows external entities, internal entities, file stores, and data flows between entities and to/from file stores. The diagram consists of multiple boxes representing external entities (sources and sinks), multiple bubble symbols representing internal entities, double-lined symbols representing file stores, and directional arrows representing data flows to/from internal and external entities and file stores. Like the context DFD, the physical DFD uses noun (i.e., thing) labels to describe the external entities, internal entities, file stores, and data flows. The physical DFD does not show internal processes and does not use verb labels. Logical Data Flow Diagram (Logical DFD). The logical DFD shows what logical subprocesses are performed within the process it portrays. The focus of the logical DFD is internal subprocesses and data flows between them. The logical DFD shows external entities, internal subprocesses, files, and data flows between external entities, internal subprocesses, and file stores. The diagram consists of multiple boxes representing external entities (sources and sinks), multiple bubble symbols representing logical subprocesses, double-lined symbols representing file stores, and directional arrows representing data flows to/from external entities, logical subprocesses, and file stores. The logical DFD uses verb (i.e., action) labels to describe subprocesses and noun labels to describe external entities, file stores, and data flows. The logical DFD does not show internal entities. System Flowchart. The systems flowchart is a detailed diagram that shows who/what performs activities (entities), what activities are performed, and how activities are performed within the process it portrays. Physical and logical DFDs show a selected view of the system; the physical DFD shows the physical view (i.e., internal entities) and a logical DFD shows the logical view (i.e., internal subprocesses). A systems flowchart is a more inclusive diagram that shows both physical and logical aspects of a process. A system flowchart shows entities (internal and external), information activities (capture, processing, storage, and distribution activities), operations activities (relevant work activities that enable information activities), logical flows, documents, reports, and files for a specified process. In a system flowchart, system inputs, processing activities, system outputs, logical flows, data/file stores, and connectors are represented by different symbols specific to the type of input, processing, output, data store, or connection being represented. The system flowchart uses noun (i.e., thing) labels to describe entities, documents, reports, and files and verb (i.e., action) labels to describe manual and Walters Systems Documentation Notes 6 electronic input, processing, and output activities performed. Walters Systems Documentation Notes 7 Diagram Symbols DFD Symbols. DFD symbols consist of simple shapes to represent entities, subprocesses, file stores, and data flows. DFD symbols consist of boxes (to represent external entities), bubbles (to represent internal entities or subprocesses), double-lined symbols (to represent file stores), and directional arrows (to represent data flows to/from entities, subprocesses, and/or files stores). Note while numerous DFD symbols exist in Microsoft Visio, the symbol set we will for this course has been intentionally limited to simplify preparation of DFDs. You must use the symbols provided below (and only these symbols) to prepare DFDs for course assignments. Figure 1: DFD Symbols Note if the DFD file store symbol proves difficult to work with in Visio (sometimes it will not allow you to add text), you may reshape/resize the “open rectangle” symbol to serve as a DFD file store symbol. The open rectangle symbol appears on the “Miscellaneous Flowchart Shapes” menu in Visio. Walters Systems Documentation Notes 8 Flowchart Symbols. Flowchart symbols may be classified as input, processing, output, data store, and connector symbols. Each input, processing, output, data store, and connector symbol has a specific meaning. Note while numerous flowchart symbols exist in Microsoft Visio, the symbol set for this course has been intentionally limited to simplify preparation of systems flowcharts. You must use the symbols provided below (and only these symbols) to prepare flowcharts for course assignment. Figure 2: Flowchart Symbols Note “General Purpose Input/Output” symbol may only be used if the listed symbols do not apply to the nature of the input/output activity. This is extremely unlikely, so you must avoid using this symbol, as it is ambiguous and as such, will create confusion when reading a flowchart. Walters Systems Documentation Notes 9 Additional Concepts Annotation. An annotation is a brief comment linked to a symbol in a system flowchart using a dotted or solid line symbol. Annotations may be used to provide an explanatory note or to indicate that an activity or process (e.g., an error or exception routine) has been excluded and/or presented elsewhere. Balance. Balance refers to consistency of external entities and external data flows to/from external entities across associated DFDs (context DFD, the physical DFD, and the logical DFD). For DFDs balance, the external entities and the external data flows to/from external entities must be identical across all three DFDs. This means that all three DFDs must show identical external entities and data flows to/from external entities and external entities and flows to/from external entities must possess identical labels. Your course text states as much but is somewhat careless re balancing its illustrative diagrams. Nevertheless, when preparing assignments, take care to ensure that DFDs are balanced or you will lose credit on assignments. Chronological Order. Narratives, tables of entities and activities, and diagrams should present entities, activities, and data flows in chronological sequence. Exploding (A.K.A. Top Down Partitioning). Exploding refers to the process of breaking a top-level entity or subprocess within a level 0 DFD down into its component parts for display in a level 1 DFD. DFD Levels (level 0, level 1). Refers to the level of detail in a DFD. Level 0 DFD. A level 0 physical DFD or level 0 logical DFD is the least detailed DFD showing only a top-level view of internal entities or subprocesses, respectively. That is, it does not break entities or subprocesses down into component parts. Level 1 DFD. A level 1 physical DFD or level 1 logical DFD is a detailed diagram that takes a single entity bubble or subprocess bubble (from a level 0 physical or logical DFD, respectively) and breaks it down into its component parts. Level 1 Physical DFD. A level 1 physical DFD might take an internal place entity (e.g., a department or office) represented by a single bubble in a level 0 physical DFD and break it down into the internal person entities within the place entity (e.g., individual persons within the department or office). For example, an internal entity such as a cashier’s office represented by a single bubble in a level 0 physical DFD might be broken down to show individual clerks and flows between those clerks within the office in a level 1 physical DFD. Level 1 Logical DFD. A level one logical DFD might take a logical subprocess (a grouping of logically related activities within a process) represented by a bubble in a level 0 logical DFD and break it down into specific activities (i.e., individual actions, steps, or tasks) performed within the subprocess. For example, an internal subprocess such as “prepare cash deposit” represented by a single bubble in a level 0 logical DFD might be broken down to show individual tasks performed within the “prepare cash deposit” subprocess in a level 1 logical DFD. Exception/Error Routines. Subprocesses that consist of atypical and/or non-routine activities. An exception routine is a subprocess that must be performed when a transaction does not proceed in an ideal or typical manner. An error routine is a type of exception routine that must be performed when Walters Systems Documentation Notes 10 an error occurs or a problem is discovered. Exception and/or error routines are not typically shown in top-level (level 0) diagrams. Labels (nouns, verbs). Different symbols within of diagrams require different types of labels. Two types of labels are used, noun labels (“thing” labels) and verb labels (“action” labels). Labels in DFDs. Things (i.e., entities, data flows, file stores, and systems) must be labeled as nouns whereas actions (i.e., activities/tasks, processes, and subprocesses) must be labeled as verbs. Verb labels are only permitted in DFDs when designating internal subprocesses. Labels in Systems Flowcharts. Things (i.e., entities, documents, reports, file stores) must be labeled as nouns whereas actions (e.g., activities/tasks or processes) must be labeled as verbs. PREPARING SYSTEM DOCUMENTATION General Notes Note 1. System narratives and tables of entities and activities must be properly formatted and labeled. Note 2. Diagrams (context DFDs, physical DFDs, logical DFDs, and system flowcharts) must be constructed using the symbols provided in the course notes. These symbols are standardized, generally understood symbols. The location of correct symbols are indicated in the “Visio Basics Notes”. Note 3. The symbols and guidelines presented in the course notes and the course text represent generally accepted practice for preparing systems diagrams. However, a great deal of judgment goes into the preparation of systems diagrams (especially with logical DFDs and systems flowcharts). Note 4. Using symbols and diagramming rules to construct understandable diagrams is very much like utilizing language vocabulary and syntax to communicate effectively and as such, different “correct solutions” are possible, and a certain amount of judgement is required. Nevertheless, it is important to use accepted diagram symbols and diagramming practices to ensure diagrams are understandable. Note 5. Keep in mind that the purpose of systems diagrams is to clearly communicate an understanding of a system process to another individual who, in all probability, does not know anything about the system. Keep your diagrams clear, simple, and understandable. Narratives & Tables Identify Process and Elements. For the purposes of this course, the process of interest will consist of a business transaction process. A transaction process is essentially an information process (capture, process, maintain, distribute) designed to track core business operations. In order to diagram a transaction process properly, you must identify all entities, activities, data flows (to/from entities), documents (source, product, turnaround), files (temporary, master, archive, reference), and reports relevant to the transaction process of interest. Define the Scope for Analysis. The scope for analysis is the defined extent or range of processing to which analysis will be restricted. The scope is initially defined by identifying a starting point and a stopping point for transaction activities to be analyzed/diagrammed. Scope restrictions typically consist of the restricted extent/range of activities, entities identified as external, error/exception routines excluded from analysis, and/or other pragmatic/logistical restrictions placed on analysis (e.g., restricted Walters Systems Documentation Notes 11  access to sensitive data, inaccessibility of documents/reports). Activities that fall outside the defined scope (i.e., the specified starting and stopping point) are not diagrammed in detail, and entities that only perform activities outside the defined scope are considered external entities. Prepare a Systems Narrative. A system narrative is a detailed, chronological, written description of system entities, activities, data flows, documents, files, and reports for a specified system/process. Format. System narratives must be formatted/labeled as follows. Columns. System narratives must be formatted in three columns with appropriate headers. The first header (on far left) is labeled “paragraph” (or an abbreviation thereof) and is used to present paragraph numbers in chorological order (i.e., 1, 2, 3, etc). The second header in the middle is labeled “Line” and is used to present line numbers (for each line of text) in chronological order (i.e., 1, 2, 3, etc). The third header is labeled “Text” and is used to present the written description of the system process. Text. The text of the system narrative must be left justified, single-spaced, and contain appropriate paragraph breaks (i.e., typically a blank line between paragraphs). See the table template below for an illustration of narrative format (paragraphs/lines added as needed). NARRATIVE (COMPANY NAME AND PROCESS) Par Line Text a 1 Subject statement defining business. Subject statement defining the process described in narrative. 1 2 (Set apart from main narrative as separate paragraph and no more than two to three lines in length) Paragraph Break (indicates natural break, change, or pause in processing) 1 First paragraph describing transaction process. 2 2 3 etc Paragraph Break (indicates natural break, change, or pause in processing) 1 Next paragraph describing transaction process. 2 3 3 etc. Paragraph Break (indicates natural break, change, or pause in processing) 1 Next paragraph describing transaction process. 2 4 3 etc. Paragraph Break (indicates natural break, change, or pause in processing) etc. etc. etc. Figure 3: Narrative Illustration Content. System narratives must carefully describe all relevant system elements (entities, activities, data flows, documents, files, and reports/outputs) for the specified process a in as much detail as possible. Note that the narrative should focus on those elements within the Walters Systems Documentation Notes 12  defined scope for analysis but will generally include description of entities/activities just outside the defined scope to afford context for diagramming purposes. Entities. All entities (internal and external) associated with the process (along with activities the such entities perform) must be included in the narrative. Activities. Activities are a central focus of the narrative; all information processing activities must be included in the narrative. Activities must be described in chronological step-by-step form, contain adequate detail to enable understanding, indicate the entity who performs the activity, explain data flows to/from relevant entities (i.e., sends/receives) that support processing, and specify any associated documents utilized, files accessed/updated, and/or reports prepared. Note is extremely important to describe each activity step in meticulous, step- by-step detail as a basis for constructing systems diagrams, as such details are required to properly construct system diagrams; failure to include adequate detail in the narrative will result in poorly constructed diagrams. Students often omit computer processes (data processing tasks, data/record retrievals from file stores), so it is important to note a computer/system cannot display or print anything without first processing a task or retrieving data/records from a file store, so make sure to carefully describe computer processes in a narrative. Data Flows. All data flows (i.e., sends/receives) between entities must be included in the narrative. Documents. All relevant source, product, and turnaround documents relating to information processing activities must be included in the narrative. Files. All relevant file stores (i.e., files/records) necessary to support information processing activities must be included and properly labeled/named (i.e., the file label/name should clearly indicate records contained therein) in the narrative. Reports/Outputs. All relevant reports/outputs (e.g., batch totals, summaries, statements) must be included and properly labeled/named in the narrative. Structure. System narratives must be written in prose form (like a story).1 A system narrative must describe the “process story” (i.e., a chronological sequence of actions/tasks performed to carry out the specified transaction process). Subject Sentences. Subject sentences must consist of concise statements explaining what the narrative describes. There are two subject sentences. The first subject sentence must define the company. The second subject sentence must define the process the narrative describes and be of the form, “The following procedures are used by [company name] to process [definition of 1 Prose form refers to ordinary written language consisting of complete sentences, proper grammar, paragraph structure, appropriate punctuation, and logical flow of ideas as commonly used in essays, letters, memos, stories, and novels. Prose is distinguished from poetry or verse (which is characterized by rhyme, meter, and verse structure) and bulleted/numbered/outlined lists (which are characterized by a series of disconnected ideas often presented as sparsely worded descriptions or incomplete sentences). It is not acceptable to use bulleted points within a system narrative. Walters Systems Documentation Notes 13  transactions processed]”. Paragraphs. System narratives must contain customary paragraph breaks. Paragraph breaks should indicate a natural break, change, or pause in processing activities. Writing Mechanics. System narratives must clearly/succinctly express process elements, use simple direct sentences, flow logically from point to point, use appropriate professional language/word choice, and follow proper English spelling, grammar, and punctuation. Proofread narratives carefully. Last Sentence. The last sentence must indicate the end of the specified process and state where or to whom outputs from the specified process are sent. Prepare a Table of Entities & Activities. A table of entities and activities is a table that organizes the entities/processing activities described in the systems narrative in chronological order of occurrence. Format. Tables of entities and activities must be formatted/labeled as follows. Columns. Tables be formatted in four columns with appropriate headers. The first header (on far left) labeled “Entities” is used to indicate entities that perform each successive activity; this column should also indicate the nature of the entity in parentheses (i.e. internal abbreviated “I” or external abbreviated “E”). The second header from the left labeled “P, L” is used to indicate the paragraph and line number on which each activity starts within the narrative chronological order (i.e., 1, 1 indicates paragraph 1, line 1). The third header from the left labeled “Activities” is used to an abbreviated description of the activity (i.e., action/task) performed. The fourth column from the left labeled “Subprocesses” is used to indicate logical subprocesses constructed from the activities listed (see below). Activities. Each action/task performed must be listed in chronological step-by-step form, indicate data flows (i.e., sends/receives), and specify associated documents/files/reports. Logical Subprocesses. Logical subprocesses must be annotated (shown and properly labeled) in the table of entities and activities. Breaks between subprocesses should be indicated by merging subprocess cells. See the table template below for an illustration of table format (activity lines/subprocesses added as needed). TABLE OF ENTITIES (COMPANY NAME AND PROCESS) Entities (I, E) P, L Activities Subprocesses 1. 1.0 First Subprocess 2. (active, present-tense verb label) 3. 4. 2.0 Second Subprocess 5. (active, present-tense verb label) 6. etc. 7. etc., etc., etc. Walters Systems Documentation Notes 14  TABLE OF ENTITIES (COMPANY NAME AND PROCESS) Entities (I, E) P, L Activities Subprocesses Figure 4: Table of Entities & Activities Illustration Content. The table includes entities performing activities (internal/external), paragraph and line references (indicating paragraph in which and line on which the activity is described in the narrative), and activities (listed and numbered in chronological order of occurrence). Logical subprocesses are also notated on the table of entities and activities to provide the basis for preparing the logical DFD. Steps. Step 1. Read through the systems narrative and mark each activity as it appears in the process description. Include both information processing activities (i.e., capture, processing, maintenance/storage, and distribution activities) and non-information processing activities indicating data flows to/from entities (i.e., sends/receives). Step 2. Read through your systems narrative and mark each entity (internal/external) that performs each identified activity. Make a list consisting of the entities you have identified. Maintain consistent labels for entities. In some real-world narratives, inconsistent terms are used to indicate the same entities. The most common instance of this is to refer to both a place entity (e.g., a department or office) and a person entity (e.g., an individual clerk working in the department or office) as distinct entities within the same narrative. Note the course text tends to do this.2 When constructing your own narratives, you will have to decide whether it is more appropriate to list internal entities at a “place” level (e.g., department or office) or “person” level (e.g., an individual clerk working in the department or office)3 and then maintain consistency throughout the narrative. Step 3. Construct a table to organize the activities/entities you identified above. The table must be formatted as indicated above. Step 4. List activities you identified in chronological order in the “Activities” column and number them sequentially (i.e., 1, 2, 3, etc.). Indicate the paragraph/line number in/on which the activity appears in the system narrative under the “P, L” heading. Step 5. Indicate the entity that performed each activity in the “Entities” column. Carefully label each entity as internal (“I” ) or external ( “E”) in parentheses. Recall simply “sending” data to or “receiving” data from a system are not considered information processing activities as such activities do not involve capturing, processing, storing, or distributing data. As such, entities that only send information to the system or receive information from the system (and do 2 I have never been entirely sure whether this is because they are emulating a real-world system narrative, testing your reading comprehension skills, attempting to trick you, or just being sloppy in constructing narratives. ;-) 3 This will to some extent, depend on the complexity of the system process and the level of detail necessary to adequate portray process elements. For simple processes or processes within small entities that do not have a complex organization structure, it is preferable to list internal entities at the “person” level. For more complex processes or larger entities with more complex organizational structures, it may be preferable to list entities at the “place” level. Walters Systems Documentation Notes 15  not perform any information processing activities) are considered external entities. Some things to remember. Note 1. Include only those activities described in the system narrative. If a system entity, activity, data flow, document, file, or report is not described in the system narrative, it should not appear in your table of entities and activities. Note: Your table of entities and activities (and system diagrams) must be consistent with your system narrative. If you identify details omitted from your system narrative while constructing the table of entities and activities (or system diagrams), you must go back and revise your narrative to reflect these details. Note 2. Exception/error routines are not typically included top-level (level 0) DFDs. Critical error or exception routines are addressed separately in level 1 DFDs (showing the breakdown of internal subprocesses). Identify exception/error routines and set them aside as you may need to construct a level 1 DFD to detail these routines. You may find this necessary for the purposes of the project. Create Logical Subprocesses. Format. Logical subprocesses must be presented on the table of entities and activities (see the table template above). Content. A logical subprocess is group of logically related activities that accomplish a specific objective within a larger process. Logical subprocesses are constructed by grouping together logically related activities within a process (and then indicating these groupings on a table of entities and activities). Constructed logical subprocesses are used as a basis for constructing the logical DFD only. Steps. Step 1. Review the activities listed in your table of entities and activities and note those activities that seem to “go together”. Look for logically related activities/tasks that accomplish a similar goal and/or are performed consecutively in closely related steps. Group together logically related activities into multi-task activity groupings (i.e., subprocesses). For instance, one might group together individual tasks necessary to prepare cash deposits (e.g., total the cash receipts, verify the total, fill out a deposit slip, and verify deposit slip) into a logical subprocess labeled “prepare cash deposits”. It is okay to combine activities performed by different internal entities into a single logical subprocess; the internal entities that perform the tasks have no bearing on the construction of logical subprocesses. That is, logical subprocesses focus on the purpose of associated activities/tasks, not who is performing those activities/tasks. Tip: Cover up the entitles in your table when constructing your subprocesses. Step 2. Number each subprocess indicating its chronological place in the process (i.e., 1.0, 2.0, 3.0, etc.) and construct short (no more than two or three words), verb (i.e., action) label that defines the nature of the subprocess (e.g., prepare case deposits). Step 3. Indicate subprocess labels on your table of entities and activities to create an annotated table of entities and activities (see the table template above). Walters Systems Documentation Notes 16  Some things to remember. Note 1. Creating subprocesses is judgment-based and such, somewhat subjective. Consequently, subprocesses are likely to differ with respect to the activities included in subprocesses, number of subprocesses created, and subprocess labels across different individuals preparing logical DFDs. Note 2. If you simply group together activities that are performed by the same internal entities, you have merely recreated the entities represented by the physical DFD (albeit with different labels). The purpose of creating logical subprocesses is to provide the basis for constructing a logical DFD and thereby, offer an alternative view of the system (system subprocesses rather than internal entities). Note 3. There is no predetermined number of logical subprocesses within a process. The number of subprocesses will depend on the complexity of the process and the level of detail desired in the logical DFD. However, note a logical DFD must have a minimum of two logical subprocesses and a maximum number subprocesses equal to the number of activities listed in the table of entities and activities divided by two (i.e., a process must consist of two or more activities). Note, this will result in way too many subprocesses. As a general rule of thumb, take the number of activities and divide by two (this will give you the absolute maximum number of subprocesses), then divide by two again (this will give you a reasonable cap on the number of subprocesses as a benchmark), and then attempt to reduce the number of subprocesses to the minimum number of subprocesses needed to enable an uninformed user to understand of the process. The goal is to construct the least number of subprocesses possible, while still offering an adequate understanding of what the process accomplishes. For example, if you have twenty tasks. Divide by two which leaves you with an absolute maximum of ten subprocesses (way too many). Divide by two again which leaves you with a cap of five subprocesses (probably still too many for a simple process). Attempt to construct two to four subprocesses (depending on complexity and natural breaks in the process). Data Flow Diagrams Prepare a Context DFD. The context DFD shows the system, its external entities, and the external data flows between the system and external entities. Steps. Step 1. Refer back to your table of entities and activities and identify external entities for the specified process. Step 2. Use a box symbol to represent each external entity. Label each box with a noun (i.e., thing) that describes the nature of the external entity (e.g., “customer” or “bank”). Place the external entities on your drawing on the top left (for external source entities) and bottom right (for external sink entities). As system diagrams are generally read from top-to-bottom and left- to-right so it is customary to place the “source” entity in the top left-hand corner of the diagram and the “sink” entity in the bottom right-hand corner. Walters Systems Documentation Notes 17  Step 3. Use a single bubble symbol to represent the system as a whole. Label the bubble with a noun (i.e., thing) that describes the nature of the system. For instance, a process that involves receiving cash payments, verifying receipts, depositing receipts, and recording receipts might be labeled “Cash Receipts Process” or “Cash Receipts System”. Place the bubble symbol in the approximate center of your drawing. Step 4. Use directional arrows to represent external data flows to/from the system and external entities. Label each data flow with a noun (i.e., thing) label that describes either the nature of the data flow (e.g., “payment”) or form in which data flows to/from the system and external entities (e.g., “cash”). Data flow lines should never intersect or cut across one another; this makes it difficult to read the diagram and follow data flows. Use directional arrows to indicate flows on the drawing; arrow heads should clearly indicate connection points and directionality. Do not connect all flows to the same connection point, as this will obscure the directional arrow heads. Some things to remember. Note 1. DFDs use a limited number of symbols (boxes, bubbles, directional arrows, and double lines). DFDs do not use flowchart symbols. Note 2. A context diagram does not show internal entities, internal processes, internal data flows, or file stores. Note 3. A context DFD uses noun labels to describe the system, external entities, and data flows. The context diagram does not use verb labels. Note 4. A context DFD uses a separate box to represent each external entity, a single bubble symbol to represent the system as whole, and a directional arrow to represent each external data flow to/from the system process and external entities. A context DFD will have only one bubble, period. Prepare a Physical DFD. The physical DFD shows a system’s external entities, internal entities, files, and data flows between entities and file stores. Steps. Step 1. Refer to the context DFD and reproduce the entities and the external data flows to/from external entities exactly as they appear in the context DFD. This is necessary to ensure that the physical DFD is balanced with the context DFD. Step 2. Refer back to your table of entities and activities and identify the internal entities for the specified process. Use a bubble symbol to represent each internal entity. Label each bubble with a number indicating the entity’s chronological place in the process (e.g., 1.0, 2.0, 3.0 etc.) and a noun (i.e., thing) label that describes the nature of the internal entity (i.e., “cash receipts clerk” or “computer system”). Place internal entity bubbles in the approximate center of your drawing in- between sources and sinks in chronological order. Internal entity bubbles should be positioned so that data flows between entities that interact may be easily represented. Start by placing the internal entity bubble (labeled 1.0) directly connected to the source; that is, where/to whom does Walters Systems Documentation Notes 18  the source send its data to? Next, place the internal entity bubble for the entity directly connected to bubble 1.0; that is, where/to whom does entity number 1.0 send data to? Continue by placing internal entity bubbles that are directly connected by data flows to bubbles you have already placed until all of the internal entities have been represented (i.e., 3.0, 4.0, etc.). Step 3. Use double-lined symbols to represent file stores. Label each data flow with a noun (i.e., thing) label that describes either the nature of the data stored in the file (e.g., “deposit slips” or “cash receipts summary”). Place file stores adjacent to internal entities that interact with them. Students tend to omit file stores in narratives, table, and diagrams. If a file is logically necessary it must be included in the narrative, table, and diagrams. Step 4. Use directional arrows to data flows to/from internal and external entities and file stores. Show a data flow for each flow to/from each entity and file store. Label each data flow with a noun (i.e., thing) label that describes either the nature of the data flow (e.g., “payment”) or form in which data flows to/from the system and external entities (e.g., “cash”). Data flow lines should never intersect or cut across one another; this makes it difficult to read the diagram and follow data flows. Use directional arrows to indicate flows on the drawing; arrow heads should clearly indicate connection points and directionality. Do not connect all flows to the same connection point, as this will obscure the directional arrow heads. Connect data flows to/from a computer file stores (to represent accessing/updating records) to the internal entity that accesses the file store records. Computer files can only be accessed via a computer system. On a physical DFD, data flows to/from a computer file (to represent accessing/updating files) must go through a “computer” internal entity bubble. Some things to remember. Note 1. The physical DFD does not show internal subprocesses. Note 2. DFDs use a limited number of symbols (boxes, bubbles, directional arrows, and double lines). DFDs do not use flowchart symbols. Note 3. The physical DFD uses noun labels to describe the internal entities, external entities, and data flows. The physical DFD does not use verb labels. Note 4. Each internal entity identified in the table of entities and activities will become a separate bubble in the physical DFD. Note 5. The physical DFD uses of a separate box to represent each external entity, a bubble symbol to represent each internal entity, and a directional arrow to represent each data flow to/from internal and external entities and file stores. Prepare a Logical DFD. The logical DFD shows the system’s external entities, internal subprocesses, files, and data flows between external entities, internal subprocesses, and file stores.. Steps. Step 1. Refer to the context DFD and physical DFD and reproduce the entities and the external data flows to/from external entities exactly as they appear in the context and physical DFDs. This is Walters Systems Documentation Notes 19 necessary to ensure that the logical DFD is balanced with the context and physical DFDs. Step 2. Refer back to your annotated table of entities and identify the logical subprocesses you constructed. Use a bubble symbol to represent each logical subprocess. Label each bubble with a number that indicates the subprocess’ chronological place in the process (e.g., 1.0, 2.0, 3.0 etc.) and a verb (i.e., action) label that summarizes the subprocess and/or describes what the subprocess accomplishes. Place the logical subprocess bubbles in the approximate center of your drawing in- between sources and sinks in chronological order. Logical subprocess bubbles should be positioned so that data flows between subprocesses that interact may be easily represented. Start by placing the logical subprocess bubble connected to the source; that is, which subprocess occurs first in your table of entities and activities? Next, place the logical subprocess bubble for the subprocess chronologically connected to bubble 1.0; that is, which logical subprocess occurs next (sequentially) in your table of entities and activities? Proceed chronologically, placing subprocess bubbles directly connected by data flows to bubbles you have already placed until all of the logical subprocess you constructed have been represented (i.e., 3.0, 4.0, etc.). Step 3. Use double-lined symbols to represent file stores. Label each data flow with a noun (i.e., thing) label that describes either the nature of the data stored in the file (e.g., “deposit slips” or “cash receipts summary”). Place file stores adjacent to logical subprocesses that interact with them. Note: Students have a tendency to neglect files in their system narrative and diagrams. If a file is logically necessary it must be included in the narrative and diagrams. Step 4. Use directional arrows to data flows to/from logical subprocesses, external entities, and file stores. Show a data flow for each flow to/from each logical subprocess, external entity, and file store. To determine how to label data flows between subprocesses, look back at the table of entities and activities and determine what data element(s) within the first subprocess is (are) necessary for the next subprocess to perform its function. Label each data flow with a noun (i.e., thing) label that describes either the nature of the data flow (e.g., “payment”) or form in which data flows to/from the system and external entities (e.g., “cash”). Data flow lines should never intersect or cut across one another; this makes it difficult to read the diagram and follow data flows. Use directional arrows to indicate flows on the drawing; arrow heads should clearly indicate connection points and directionality. Do not connect all flows to the same connection point, as this will obscure the directional arrow heads. Connect data flows to/from a computer file stores (to represent accessing/updating records) to the logical subprocess bubble that contains the relevant accessing/updating activities. Computer files can only be accessed via a computer system. However, a logical DFD does not show internal entities so data flows to/from a computer file stores must be displayed to the logical subprocess bubble that contains the relevant activities. Some things to remember. Note 1. The logical DFD does not show internal entities. Note 2. DFDs use a limited number of symbols (boxes, bubbles, directional arrows, and double lines). DFDs do not use flowchart symbols. Note 3. The logical DFD uses verb (i.e., action) labels to describe subprocesses and noun labels to describe external entities, file stores, and data flows. The logical DFD does not use verb labels to describe external entities, file stores, and data flows. Walters Systems Documentation Notes 20  Note 4. The subprocesses and corresponding labels you constructed to describe the subprocesses will dictate the structure of the logical DFD. Each logical subprocess constructed from the table of entities and activities from the will become a bubble in the logical DFD. Note: Subprocesses describing error or exception routines are not represented in a level 0 diagram. These subprocesses are typically presented in a level 1 detail diagram. Note 5. The logical DFD consists of a separate box to represent each external entity, a bubble symbol to represent each logical subprocess, and a directional arrow to represent each data flow to/from external entities, internal subprocesses and file stores. Systems Flowchart Prepare a System Flowchart. A system flowchart shows entities (internal and external), information activities (capture, processing, storage, and distribution activities), operations activities (relevant work activities related to information activities), logical flows, documents, reports, and files for a specified process. Steps. Step 1: Refer back to your table of entities and activities and identify the entities (internal and external) for the specified process. Step 2: Divide your drawing into columns creating a separate column for each internal entity. Label each column with a noun (i.e., thing) that describes the nature of the internal entity (i.e., “cash receipts clerk” or “computer system”); these labels should be consistent with the labels used for your bubbles in your physical DFD. Do not create separate columns for external entities. These entities do not perform information processing activities so you will only need to show “sends” and/or “receives” to and/or from external entities. External entities are represented as start/stop connectors placed in the column under the internal entity with which they interact in system flowcharts. Place columns so that flowchart activities will flow from top-to-bottom and left-to-right. If possible, arrange columns so that entities that interact heavily with each other are adjacent to each to minimize use of on/off page connectors. Step 3: If an internal entity initiates the process (i.e., the source), represent the start of the process as a start/stop connector symbol and label the symbol with the word “start”. If an external entity initiates the process (i.e., a source), represent this external entity as a start/stop connector symbol and label the symbol with a noun (i.e., thing) that describes the nature of the external entity (e.g., “customer”). Place the start symbol under the column heading for the internal entity serving as or connected to the source. Use a directional flow line to indicate the flow from external (i.e., source) to internal entity. Step 4: Represent activities performed by each internal entity chronologically from top to bottom within each internal entity column. This may require you to leave an internal entity column before it is complete to go to another entity column to follow chronological order of activities. If you do, make sure to use on-page connectors. Flow lines should never cut across flowchart columns. Use appropriate input, processing, output, data store, and connector flowchart symbols to represent all relevant information activities (capture, processing, storage, and distribution activities), logical flows, documents, reports, and files. Walters Systems Documentation Notes 21 Input Activities. Input activities performed by an internal entity should be represented by an input symbol (manual keying or electronic input), placed in the internal entity column that performs those activities, and should be represented chronologically from top to bottom. Inputs “sent” to the system by an external entity should be placed in the receiving internal entity’s column and be shown flowing from an external entity source connector (a start/stop connector symbol). Processing Activities. Processing activities performed by an internal entity should be represented by a processing symbol (manual or computer), placed in the internal entity column that performs those activities, and should be represented chronologically from top to bottom. Note: Process symbols representing successive tasks should not flow from left to right within an entity column; successive tasks should be represented from top to bottom with each successive process symbol placed directly beneath the proceeding process symbol. Only annotations and file store symbols should be placed to the side within an entity column. Appropriate manual and computer process symbols should be used to represent all significant processing tasks. Only a person can perform a manual process and only a computer system can perform a computer process so make sure to use the manual process symbol to represent activities performed by a person and the computer process symbol to represent activities performed by a computer system. Moreover, the computer process symbol should appear only in a computer entity column and a manual process symbol should appear only in a person entity column. Documents/Reports. Documents or reports prepared by an internal entity (a person or computer) should be represented by a document symbol (or multiple documents symbol), placed in the preparing internal entity’s column first, and then also be shown again in the receiving internal entity’s column at the end of the flow. Documents “sent” to the system by an external entity should be placed in the receiving internal entity’s column and be shown flowing from an external entity source connector (a start/stop connector symbol). Documents “received” by an external entity from the system should be placed in the sending internal entity’s column and be shown flowing to an external entity sink connector (a start/stop connector symbol). Document flows within an internal entity column must be facilitated by input or processing tasks. That is, there should generally be a manual keying, electronic input, manual/computer process, or data store between documents; documents should not be directly connected to other documents within an entity column. Outputs. System outputs prepared by an internal entity (a person or computer) should be represented by an appropriate output symbol, placed in the preparing internal entity’s column with a directional flow to the receiving internal entity (or external entity start/stop symbol) going directly into the next processing activity performed by the receiving internal entity. File Stores. File stores accessed by an internal entity should be represented by the appropriate file store symbol (i.e., hard disk drive, database, tape, paper) and placed in the internal entity column that is accessing the file store. Electronic data stores (i.e., hard disks, databases, tapes) can only be accessed via a computer and as such, should only be placed in the computer entity column; computer entity columns may be made wider to allow electronic file stores to be conveniently placed to the side of the related computer process. Manual files (i.e., paper files) can only be accessed by a person and as such, should only be placed in a person entity column. Walters Systems Documentation Notes 22  Step 5: If an internal entity concludes the process (i.e., the sink), represent the end of the process as a start/stop connector symbol and label the symbol with the word “stop”. If an external entity concludes the process (i.e., a sink), represent this external entity as a start/stop connector symbol and label the symbol with a noun (i.e., thing) that describes the nature of the external entity (e.g., “bank”). Place the stop symbol under the column heading for the internal entity serving as or connected to the sink. Some things to remember. Note 1. Flowcharts use different symbols classified as input, processing, output, data store, and connector symbols. Flowcharts do not use DFD symbols. Note 2. The system flowchart uses noun (i.e. thing) labels to describe entities, logical flows, documents, reports, and files and verb (i.e., action) labels to describe manual and computer processing activities performed. Logical flows are designed to indicate the directionality of processing and are not typically labeled. Note 3. System flowchart activities should flow from top-to-bottom and flowchart logic should flow from left-to-right. Directional arrows should be used to indicate directionality of logical flows but should not be labeled; flow lines should be straight or right angled (not curved) lines. Columns should be arranged to avoid crossed lines and minimize use of on/off page connectors; if a flow must cross columns that are not adjacent, use an “on page connector”. Note 4. System flowcharts should be kept to one page when possible; however, do not “scrunch” up the diagram or make the diagram symbols/labels tiny to force it to fit. If the flow chart runs to multiple pages, you must use off-page connectors to indicate that the flowchart will continue to another page and direct a reader to the page and location where the process picks up again. Note 6. Error and exception routines are not typically represented in body of the system flowchart. Use an annotation to indicate that the error or exception routine is not shown (or is shown on a separate page). If error or exception routines are critical to the integrity of the system process, place them on a separate page and use an annotation in the body of the main system flowchart to indicate that the error or exception routine is shown on another page and use an off-page connector to direct a reader to the page and location where the error or exception routine is presented. REFERENCES Gelinas, U. J., Dull, R. B., Wheeler, P.R., & Hill, M. C. (2018). Accounting Information Systems, 11e. Southwestern-Cengage Learning. Hall, J. (2019). Accounting Information Systems, 10e. Southwestern-Cengage Learning. Romney, M. B. & Steinbart, P. J., Summers, S. L., and Wood, D. A. (2024). Accounting Information Systems, Sixteenth Edition. Pearson. Simkin, M. G., Norman, C. S., & Rose, J. M. (2018) Core Concepts of Accounting Information Walters Systems Documentation Notes 23 Systems, 14the Edition. Wiley. Walters Systems Documentation Notes 24