System Design and Analysis Chapter 7 Structuring system process requirements KEY TERMS 1. 2. 3. 4. 5. 6. 7. 8. 9.

Action stubs Balancing Condition stubs Context diagram Data flow diagram (DFD) Data Store Decision table DFD completeness DFD consistency 10. Functional decomposition 11. Gap analysis 12. Indifferent condition 13. Level-0 diagram 14. Level-n diagram 15. Primitive DFD 16. Process 17. Rules 18. Source/sink

Match each of the key terms above with the definition that best fits it Data flow diagram (DFD)A picture of the movement of data between external entities and the processes and data stores within a system Action stubsThe part of a decision table that lists the actions that result for a given set of conditions BalancingThe conservation of inputs and output to a DFD process when that process is decomposed to a lower level Level-0 diagramA DFD that represents a systems major processes, data flows, and data stores at a high level of detail Source/sinkThe origin and/or destination of data; sometimes referred to as external entities. Indifferent conditionIn a decision table, a condition whose value does not affect which actions are taken for two or more rules Context diagramAn overview of an organizational system that shows the system boundary, external entities that interact with the system, and the major information flows between the entities and system Primitive DFDThe lowest level of decomposition for a DFD DFD completenessThe extent to which all necessary components of a DFD have been included and fully described Decision tableA matrix representation of the logic of a decision; it specifies the possible conditions for the decision and the resulting actions DFD consistencyThe extent to which information contained on one level of a set of nested DFDs is also included on the other levels Level-n diagramA DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram

Condition stubsThat part of a decision table that lists the conditions relevant to the decision. ProcessThe work of actions performed on data so that they are transformed, stored, or distributed Data storeData at rest, which may take the form of many different physical representations. Gap analysisThat process of discovering discrepancies between two or more sets of DSFs or discrepancies within a single DFD. RulesThat part of a decision table that specifies which actions are to be followed for a given set of conditions. Functional decompositionAn iterative process of breaking the description of a system down into finer and finer detail, which creates a set of charts in which one process on a given chart is explained in greater detail on another chart. REVIEW QUESTIONS 1. What is a DFD? Why do systems analysts use DFDs? A data flow diagram is a picture of the movement of data between external entities and the processes and data stores within a system. Systems analysts use data flow diagrams to help them model the processes internal to an information system as well as how data from the systems environment enter the system, are used by the system, and are returned to the environment. DFDs help analysts understand how the organization handles information and what its information needs are or might be. Analysts also use DFDs to study alternative information handling procedures during the process of designing new information services. 2. Explain the rules for drawing good DFDs. The rules for DFDs are as follows: Process: No process can have only outputs. It is making data from nothing (a miracle). If an object has only outputs, then it must be a source. No process can have only inputs (a black hole). If an object has only inputs, then it must be a sink. A process has a verb phrase label. Data Store: Data cannot move directly from one data store to another data store. Data must be moved by a process. Data cannot move directly from an outside source to a data store. Data must be move by a process that receives data from the source and places the data into the data store. Data cannot move directly to an outside sink from a data store. Data must be moved by processes. A data store has a noun phrase label. Source/Sink: Data cannot move directly from a source to a sink. Data must be moved by a process. If the data are of any concern to our system. Otherwise, the data flow is not shown on the DFD. A source/sink has a noun phrase label Data Flow:

A data flow has only one direction of flow between symbols. It may flow in both directions between a process and a data store to show a read before an update. The latter is usually indicated; however, by two separate arrows because these happen at different times. A fork in a data flow means that exactly the same data goes from a common location to two or more different processes, data stores, or sources/sinks (this usually indicates different copies of the same data going to different locations). A join in a data flow means that exactly the same data come from any of two or more different processes, data stores, or sources/sinks to a common location. A data flow cannot go directly back to the same process it leaves. There must be at least one other process that handles the data flow, produces some other data flow, and returns the original data flow to the beginning process. A data flow to a data store means update (delete or change). A data flow from a data store means retrieve or use. A data flow has a noun phrase label. More than one data flow noun phrase can appear on a single arrow as long as all of the flows on the same arrow move together as one package.

3. What is decomposition? What is balancing? How can you determine if DFDs are not balanced? Decomposition is the iterative process by which a system description is broken down into finer and finer detail, creating a set of diagrams in which one process on a given diagram is explained in greater detail on a lower-level diagram. Balancing is the conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level. You can determine if a set of DFDs are balanced or not by observing whether or not a process that appears in a level-n diagram has the same inputs and outputs when decomposed for a lower-level diagram. 4. Explain the convention for naming different levels of DFDs. The highest level DFD is called a context diagram. It represents the system as a single process, with all the related entities and the data flows in and out of the system. The next level diagram, called a level-O, decomposes the one process from the context diagram into between two to nine high-level processes. Each process in a level-O diagram can be decomposed if necessary. Each resulting diagram is called a level-1. Should processes in a level-1 diagram be decomposed, each resulting diagram would be called a level2 diagram. Each of these processes would be decomposed on a level-3 diagram, and so on. 5. Why do analysts draw multiple sets of DFFDs? The various views, among others, process, logic, and data, of an information system each have their own unique characteristics and provide the most relevant information to different information system specialists. This variety is best understood, expressed, and managed by using diagrams and documentation that are specifically tailored for each view of the system.

As for example, data flow diagrams are useful for capturing the flow of data through business processes, but they are not useful for describing the forms and relationships among data. As information systems become larger and more complex, it becomes even more important to use the right tool and technique to develop each component to an information system. One technique that captured all aspects of an information system model on one diagram or in one notation would likely be too complex for systems professionals to handle. 6. How can DFDs be used as analysis tools? DFDs can be used as analysis tools to help determine the completeness of a system model and a models internal consistency, as a way to determine when system events occur through analyzing timeliness, and through iterative use, to develop and check models. Analysts can study DFDs to find excessive information handling, thus identifying areas for possible efficiencies. 7. Explain the guidelines for deciding when to stop decomposing DFDs. The guidelines for deciding when to stop decomposing DFDs are as follows: 1. Each process is a single decision or calculation or a single data base operation, such as retrieve, update, create, delete, or read. 2. Each data store represents data about a single entity, such as a customer, employee, product, or order. 3. The system user does not care to see any more detail to do subsequent systems development tasks 4. Every data flow does not need to be split further to show that different data are handled in different ways. 5. You believe that you have shown each business form or transaction, computer screen, and report as a single data flow 6. You believe there is a separate process for each choice on all lowest-level menu options for the systems. 8. How do you decide if a system component should be represented as a source/sink or as a process? Sources and sinks as always outside of the system being considered. They are of interest to the system being considered only because they represent sources of data coming into the system and destinations for data leaving the system. If any data processing occurs inside a source or sink, it should be of no interest to the system being modeled. If the processing is of interest, however, or if the identified source/sink has several inputs and outputs to and from the rest of the system, it may be better considered as an internal process. 9. What unique rules apply to drawing context diagrams? Context diagrams have only one process that represents the entire system being modeled and show only the data flows into and out of the system. The diagram also includes sources and sinks, which represent the systems environmental boundaries. There are usually no data stores in a context diagram. 10. What are the steps in creating a decision table? How do you reduce the size and complexity of a decision table? The steps in creating a decision table are as follows:

1. Name the conditions and the values each condition can assume. Determine all the conditions relevant to the problem and then determine all the values each condition can take. For some conditions, the values will be simply yes or no (called a limited entry). For others the conditions may have more values (called an extended entry). 2. Name all possible actions that can occur. 3. Lists all possible rules. 4. Define the actions for each rule. 5. Simplify the decision table. To reduce the size and complexity of a decision table, use separate, linked decision tables, or use numbers that indicate sequence rather than Xs where rules and action stubs intersect. Also, the analyst should identify indifferent conditions and simplify the decision table. 11. What does the term limited entry mean in a decision table? The term limited entry mean in a decision table that some conditions will simply have a limited set of possible values, such as yes or no. 12. What is the formula that is used to calculate the number of rules a decision table must cover? To determine the number of rules a decision table must cover, simply determine the number of values each condition may have and multiply the number of values for each condition by the number of values for every other condition.