Chapter 6 Structuring System Requirements: Process Modeling Chapter Overview This chapter continues the discussion of systems analysis, introducing students to requirements structuring. Specifically, students are introduced to process modeling and logic modeling. Although there are several methods and techniques available for process modeling, this chapter focuses on Data-flow Diagrams (DFDs) because they have been popular for many years, especially in the structured analysis and design literature. Also, many CASE tools have incorporated DFDs into their sets of system development tools and techniques. Structured English and decision tables are the two logic models presented in this chapter. The chapter discusses how Structured English statements are used to represent the basic constructs in structured programming: sequence, choice, and repetition. Decision tables are discussed in reference to how they can represent more complicated processing logic than simple Structured English statements. Instructional Objectives Specific student learning objectives are included at the beginning of the chapter. From an instructor’s point of view, the objectives of this chapter are to: 1. Show how data-flow diagrams can logically model processes. 2. Teach students data-flow diagram symbols and the mechanical rules necessary for them to create accurate and well-structured process models. 3. Show students how to decompose data-flow diagrams into lower-level diagrams. 4. Illustrate the concept of balanced DFDs. 5. Explain and demonstrate the differences among the four types of DFDs: current physical, current logical, new physical, and new logical. 6. Illustrate how data-flow diagrams can be used as tools to support systems analysis. 7. Show how Structured English can be used to model process logic. 8. Demonstrate how decision tables can be used to represent the logic of choice in conditional statements. 9. Explain that process modeling for Internet-based electronic commerce applications is no different than the process used for other applications. Classroom Ideas 1. Use Figures 6–2 and 6–6 to illustrate the basic DFD symbols and the correct and incorrect ways to draw the diagrams. Use Figure 6–3 to demonstrate the problem with trying to include sources/sinks inside the system being modeled. 2. Once you have taught the basics of drawing DFDs, have students complete Problems and Exercises 1 through 3 and 8 as in-class exercises that you can then go over in class. 3. Figures 6–4, 6–5, 6–7, 6–8, 6-9 and 6-10 can be used in class to teach decomposition. These can be followed with students completing Problems and Exercises 6-18 and 6-24 in-class. 4. Use Figure 6–11 to illustrate unbalanced DFDs. 5. Supplement the material in this chapter on DFD mechanics, decomposition, and balancing with your own examples, which you can work through together in class. A good source of such examples is written organizational procedure statements. Modified procedure statements also make good homework problems. See Problems and Exercises 6-24 and 6-25 for examples. It is probably best to devote at least one complete class period to working through examples. Students can prepare these diagrams outside of class or try for the first time in class. Many issues arise that are best handled from examples, such as the following difficulties that students often encounter: • identifying when to show a direct data flow between processes and when to decouple these with a data store (emphasize that data stores allow different processes to work at different rates and at different times). • deciding what activities to encompass with each process (emphasize the principle of cohesion and the goal of each process being of roughly equal size and complexity). • distinguishing processes from sinks and sources (emphasize factors such as audience and the ability to change or control in making such distinctions). • logical inconsistencies or ambiguities in narrative descriptions (emphasize that this is the power of DFDs and the typical interaction between requirements structuring and requirements determination necessary to resolve such ambiguities). 6. Use a CASE tool in class to demonstrate other ways to model processes other than DFDs. Have students compare and contrast these alternative methods with DFDs. 7. Using a CASE tool that supports DFDs, show in class how the tool provides for decomposition and balancing and how DFDs are linked to the CASE repository. Later, when teaching Chapter 6, you can show how the repository links DFDs and entity-relationship diagrams. 8. Use a CASE tool in class to show how the tool checks for completeness, consistency, and other elements of analysis as discussed in the chapter. 10. Work through both decision table examples contained in the text, using Figures 6–15 and 6–16, then work through Figures 6–17 and 6–18. Lecture Notes As illustrated in Figure 6–1, requirements structuring is the second of the three primary analysis phases. This chapter introduces students to two methods useful for structuring requirements: process modeling and logic modeling, Process Modeling Process modeling graphically represents the processes that capture, manipulate, store, and distribute data between a system and its environment and among components within a system. The data-flow diagram (DFD) is the type of process model discussed in Chapter 6. During requirements determination, information is collected about the current and new systems. The project team will structure this information into meaningful representations of the current and new systems. The requirements structuring process results in several deliverables, including a context data-flow diagram, DFDs of the current system, DFDs of the new system, and a thorough description of each DFD component. The process modeling deliverables are listed in Table 6–1. CASE tools facilitate the preparation of these diagrams. Data-Flow Diagramming Mechanics Four symbols are used on data-flow diagrams; these symbols represent data flows, data stores, processes, and source/sinks. The Gane and Sarson symbol set is illustrated in Figure 6–3 and is the symbol set used in this textbook. A data flow represents data that are in motion and moving as a unit. A data flow is represented by an arrow on the data-flow diagram. A database query, sales report, or order are examples of data flows. In contrast to a data flow, a data store represents data at rest. On a data-flow diagram, a data store is represented as a rectangle with its right vertical line missing. A notebook, file folder, or customer database are examples of data stores. A process, represented as a rectangle with rounded corners, represents the works or actions performed on data. Sources/sinks are the origin and/or destination of data and are represented on the data-flow diagram as squares or rectangles. Suppliers, customers, and a bank are examples. As it relates to sources/sinks, we are not interested in the interactions that occur between sources and sinks, what a source or sink does with information or how it operates, how to control or redesign a source or sink, and how to provide sources and sinks with direct access to stored data. Figure 6–4 contrasts an incorrectly drawn DFD (a process is shown as a sink) with one that is correctly prepared. The Hoosier Burger case illustrates the DFD development process. The boundary or scope of Hoosier Burger’s food-ordering system is represented by a context diagram; this diagram, illustrated in Figure 6–5, also shows the system’s interactions with its environment. The context diagram contains only one process labeled “0” and no data stores. After the context diagram is prepared, a level-0 diagram is drawn. The food-ordering system’s level-0 diagram is shown in Figure 6–6. The level-0 diagram represents a system’s major processes, data flows, and data stores at a high level of detail. The preparation of data-flow diagrams (DFDs) is governed by a set of rules; these rules are summarized in Table 6–2. Two additional DFD diagramming rules are that the inputs to a process are different from the outputs of that process and DFD objects have unique names. Figure 6–7 shows the incorrect and correct ways to draw data-flow diagrams. The context diagram is functionally decomposed into finer and finer detail, resulting in the preparation of several levels of diagrams. A level-n diagram is a DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram. Functional decomposition will continue until a subprocess cannot be exploded into more detail. Primitive DFDs are the lowest level DFDs. The level-1 diagram appearing in Figure 6–8 is a decomposition of Process 1.0 on the level-0 diagram. Figure 6–9 shows a level 1 diagram. Figure 6–10 shows a level-2 diagram. DFDs should be balanced, meaning that the inputs and outputs to a process are conserved at the next level of decomposition. Figure 6–11 shows a set of unbalanced DFDs. Figure 6–12 provides an example of a data-flow splitting. Table 6–3 summarizes four advanced diagramming rules. These rules address splitting composite data flows into component data flows at the next level, the conservation principle, an exception to balancing, and minimizing clutter on the DFD. Using Data-Flow Diagramming in the Analysis Process Completeness, consistency, timing considerations, the iterative nature of drawing DFDs, and drawing primitive DFDs are five additional data-flow diagramming guidelines. DFD completeness is the extent to which all necessary components on a data-flow diagram have been included and fully described. CASE tools can help identify areas where the diagrams are incomplete. It is important that each DFD element be described in the CASE repository. DFD consistency is the extent to which information contained on one level of a set of nested data-flow diagrams is also included on other levels. Again, CASE tools can be used to detect inconsistencies among diagrams. DFDs do not represent time, thus they do not reflect how often a processing activity occurs. Because diagrams are generally not perfect on the first try, these diagrams are modified, resulting in iterative development. As mentioned previously, primitive DFDs are the lowest level of diagramming. The analyst has probably reached the primitive level when she has reduced each process to a single decision or calculation; each data store represents data about a single entity; the system user does not care to see any more detail; every data flow does not need to be split further to show that different data are handled in various ways; each business form or transaction, computer online display, and report has been shown as a single data flow; and there is a separate process for each choice on all lowest-level menu options. Data-flow diagrams are useful for performing gap analysis and for identifying system inefficiencies. Gap analysis is the process of discovering discrepancies between two or more sets of data-flow diagrams or discrepancies within a single DFD. Gap analysis helps identify redundant data flows, data that are captured and not used by the system, and data that are updated identically in more than one location. CASE tools aid in this analysis. The IBM Credit Corporation is used as an example of how DFDs are useful during business process reengineering. As Figures 6–13 and 6–14 illustrate, data-flow diagrams made visualizing and analyzing the financing process much easier. Logic Modeling Because data-flow diagrams do not show the inner workings of processes, logic models are useful for showing this internal logic. Decision tables are a popular method for modeling system logic. In many instances, decision logic is quite complex, and often, decision tables are best suited for these situations. A decision table is a matrix representation of the logic of a decision, which specifies the possible conditions for the decision and resulting actions. A decision table consists of three parts: condition stubs, action stubs, and rules. A decision table can be simplified by removing indifferent conditions. Figure 6–15 shows a complex decision table; Figure 6–16 shows the simplified version. The basic procedures for decision table construction are: (1) name the conditions and the values each condition can assume; (2) name all possible actions that can occur; (3) list all possible rules; (4) define the actions for each rule; and (5) simplify the decision table. Figure 6–17 shows a decision table for the Hoosier Burger’s inventory reordering system; Figure 6–18 shows the simplified table. PVF WebStore: Process Modeling The authors use Pine Valley’s WebStore to illustrate process modeling for an electronic commerce application. This example shows that process modeling for electronic commerce applications is the same as for more traditional application development projects. Table 6–4 outlines the WebStore’s system structure and corresponding Level-0 processes. Figure 6–19 is a Level-0 DFD for the WebStore. Key Terms Checkpoint Solutions Answers for the Key Terms Checkpoint section are provided below. The number following each key term indicates its location in the key term list. Review Questions Solutions 6-1. What is a data-flow diagram? Why do systems analysts use data-flow diagrams? Answer: 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 system’s 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. 6-2. Explain the rules for drawing good data-flow diagrams. Answer: The rules for DFDs are listed in Table 6–2 and illustrated in Figure 6–6. Processes cannot have only outputs, cannot have only inputs, and must have a verb phrase label. Data can move to a data store from only a process, not from another data store or an outside source. Similarly, data can be moved to only an outside sink or to another data store by a process. Data to and from external sources and sinks can be moved by only processes. Data flows move in one direction only. Both branches of a forked or a joined data flow must represent the same data. A data flow cannot return to the process from which it originated. 6-3. What is decomposition? What is balancing? How can you determine if DFDs are not balanced? Answer: 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. 6-4. Explain the convention for naming different levels of data-flow diagrams. Answer: 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-0, decomposes the one process from the context diagram into between two to nine high-level processes. Each process in a level-0 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 level-2 diagram. Each of these processes would be decomposed on a level-3 diagram, and so on. 6-5. How can data-flow diagrams be used as analysis tools? Answer: DFDs can be used as analysis tools to help determine the completeness of a system model and a model’s 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. 6-6. Explain the guidelines for deciding when to stop decomposing DFDs. Answer: You can stop decomposing a DFD when the following six conditions are satisfied: (1) each process is a single decision or calculation or a single database 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, or when you and other analysts have documented sufficient 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; and (6) you believe there is a separate process for each choice on all lowest–level menu options for the system. 6-7. How do you decide if a system component should be represented as a source/sink or as a process? Answer: Sources and sinks are 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. 6-8. What unique rules apply to drawing context diagrams? Answer: Context diagrams have only one process that represents the entire system being modeled and shows only the data flows into and out of the system. The diagram also includes sources and sinks, which represent the system’s environmental boundaries. There are usually no data stores in a context diagram. 6-9. Explain what the term DFD consistency means and provide an example. Answer: DFD consistency is the extent to which information contained on one level of a set of nested data-flow diagrams is also included on other levels. Balancing errors are one type of consistency violation mentioned in the textbook. For instance, a payment data flow that appears on a level-1 diagram, but not on the level-0 diagram, is a consistency violation. 6-10. Explain what the term DFD completeness means and provide an example. Answer: DFD completeness is the extent to which all necessary components of a data-flow diagram have been included and fully described. A data store that does not have any data flows coming into or out of it is a completeness violation. 6-11. How well do DFDs illustrate timing considerations for systems? Explain your answer. Answer: Timing considerations are not noted on DFDs. For instance indications of whether a process occurs hourly, daily, weekly, monthly, or yearly are not made. 6-12. How can data-flow diagrams be used in business process redesign? Answer: DFDs can graphically illustrate, at varying levels of detail, how a process or processes work. Analysts can study DFDs of the current system and identify areas of inefficiency. Analysts can prepare DFDs for the new system, identifying changes for the new system. 6-13. What are the steps in creating a decision table? How do you reduce the size and complexity of a decision table? Answer: The steps for creating a decision table are: (1) name the conditions and the values each condition can assume; (2) name all possible actions that can occur; (3) list all possible rules; (4) define the actions for each rule; and (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. 6-14. What formula is used to calculate the number of rules a decision table must cover? Answer: 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. Problems and Exercises Solutions 6-15. Using the example of an online cell phone apps store, list relevant data flows, data stores, processes, and sources/sinks. Draw a context diagram and a level-0 diagram that represent the app store. Explain why you chose certain elements as processes versus sources/sinks. Answer: A suggested context diagram and level-0 diagram are provided below. 6-16. Using the example of checking out a book from your university or college library, draw a context diagram and a level-0 diagram. A suggested context diagram and a level-0 diagram are provided below. Answer: 6-17. Evaluate your level-0 DFD from Problem and Exercise 6-16 using the rules for drawing DFDs in this chapter. Edit your DFD so that it does not break any of these rules. Answer: Students should go through the rules discussed in this chapter (and presented in Table 6–2 and Figure 6–7) one at a time and check each of their data-flow diagrams. Alternatively, if the students are using a CASE tool to create their data-flow diagrams, the CASE tool may be used to automatically check for errors in the diagrams. There are no rule violations in the example DFDs, but we cannot verify that there are no logical problems until we decompose the diagrams to a primitive level. One obvious missing system capability is how to handle invalid orders; typically, processes to handle abnormal conditions, like invalid orders, are shown on primitive or at least low-level diagrams. To correct your level-0 DFD: 1. Single Process: Ensure there is only one process. 2. External Entities: Verify all external entities interact with the single process. 3. Data Flows: Check data flows are correctly labeled and connected. 4. Data Stores: Include minimal data stores if necessary and ensure they are linked properly. 5. Clear Labels: Ensure all elements are clearly labeled. Edit the DFD to follow these rules for clarity and compliance. 6-18. Choose an example like that in Problem and Exercise 6-16, and draw a context diagram. Decompose this diagram until it doesn’t make sense to continue. Be sure that your diagrams are balanced, as discussed in this chapter. Answer: Students may choose a variety of situations to use for the nth level data-flow diagrams for this answer. Basically, students should continue the process of decomposition until they have reached the point where no subprocess can logically be broken down further (i.e., each process meets the definition of a primitive process). See the level-1 data-flow diagram for this exercise, which shows a sample decomposition of the process titled Finalize Order from the level-0 data-flow diagram provided for Problem and Exercise 6-16. The (italicized) labels for processes and sources/sinks without borders represent the origin or destination of flows that pass between this subsystem and other system components. Note that the Goods Sold File is a potential black hole or should possibly be treated as a sink. 6-19. Refer to Figure 6-21, which contains a draft of a context and a level-0 DFD for a university class registration system. Identify and explain potential violations of rules and guidelines on these diagrams. Answer: Some errors and peculiarities in these diagrams include: • In the level–0 diagram, the data store, Class Roster, does not have the data flow, Scheduled Classes, flowing into it. Rather, this data flow connects processes 2 and 3; thus, these DFDs are not balanced. • Process 1 appears to accomplish nothing since its inflow and outflow are identical; such processes are uninteresting and probably unnecessary; it is possible that this process will become interesting when it is decomposed, where validation and error handling processes might appear. • Process 2 does not appear to need Course Request as input in order to perform its function, as implied by its name. • Some students may also wonder if process 3 has input sufficient to produce its output; for example, where are prior class registrations kept so that process 3 can determine when a course is full? 6-20. What is the benefit of creating multiple levels of DFDs? Consider the concept of DFD consistency, as described on page 181. Why is consistency important to take advantage of the multiple levels of DFDs that may be created? Answer: Creating multiple levels of DFDs assists in ensuring that sufficient levels of detail can be understood when structuring requirements. By creating multiple levels, those with a need for a broad overview can focus on context and level-0 diagrams. Those with need for more detail can use the more fully decomposed diagrams. These diagrams need to remain consistent as missing sources, sinks, or data flows can cause inconsistency between those referring to higher and lower level diagrams. 6-21. Why do you think analysts have different types of diagrams and other documentation to depict different views (e.g., process, logic, and data) of an information system? Answer: The various views (e.g., process, logic, 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. 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 of 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-22. Consider the DFD in Figure 6–22. List three errors (rule violations) on this DFD. Answer: Three major errors in Figure 6–22 are: • Process 1.0 (P2) has only inputs, making it a “black hole”. • Data flow DF5 should not move directly from source E1 to data store DS1 without first going through a process. • Data flow DF1 should not move directly from source E1 to sink E2 without first going through a process. • Other peculiarities (such as Process 1.0 has label P2 and the data store has only a label, not a number) are only that, not errors. 6-23. Consider the three DFDs in Figure 6–23. List three errors (rule violations) on these DFDs. Answer: These diagrams show the decomposition of process P1 on the level-0 diagram. Three particular logical errors in Figure 6–23 are: • The data store DS1, not DS2, should be represented on the level 1 diagram. • DF6 is an inflow to sub process 1.2 on the level-1 but is an outflow on the context diagram. The arrow is in reverse. • Data flow DF3 should be an outflow on the level-1 diagram, and data flow DF6 should not be on the level-1 diagram. • Process P1.4.2 has no inputs and is thus a “miracle.” 6-24. Starting with a context diagram, draw as many nested DFDs as you consider necessary to represent all of the details of the patient flow management system described in the following narrative. You must draw at least a context diagram and a level-0 diagram. In drawing these diagrams, if you discover that the narrative is incomplete, make up reasonable explanations to complete the story. Provide these extra explanations along with the diagrams. Answer: Dr. Frank’s walk-in clinic has decided to go paperless and will use an information system to help move patient through the clinic as efficiently as possible. Patients enter the system at the front desk by providing demographic information to the personnel. If this is the first time the patient has been seen, insurance and basic demographic information is collected from the patient. If the patient has been seen previously, the patient is asked to verify the information pulled from the patient registry. The front desk person then updates the patient registry and ensures that the patient has a chart in the electronic medical records system; if not, a new medical record is started by placing formatted demographics into a blank medical record. The front desk person then enters the medical record ID into the system. Next, a medical technician collects the patient’s health history, weight, height, temperature, blood pressure, and other medical information, and combines this information with any information from the patient’s medical record, summarizing the information into a health trend. A doctor then sees the patient, prescribes medication or treatment where appropriate based on the medical trend, and sends the patient to checkout. The employee at checkout updates the patient’s electronic medical record and provides prescriptions for medications or treatments and a printed record of the health services received. 6-25. a. Starting with a context diagram, draw as many nested DFDs as you consider necessary to represent all of the details of the engineering document management system described in the following narrative. You must draw at least a context diagram and a level-0 diagram. In drawing these diagrams, if you discover that the narrative is incomplete, make up reasonable explanations to complete the story. Provide these extra explanations along with the diagrams. Answer: Projects, Inc. is an engineering firm with approximately 500 engineers that provide mechanical engineering assistance to organizations, which requires managing many documents. Projects, Inc. is known for its strong emphasis on change management and quality assurance procedures. The customer provides detailed information when requesting a document through a web portal. An engineer is assigned to write the first draft of the requested document. Upon completion, two peer engineers review the document to ensure that it is correct and meets the requirements. These reviewers may require changes or may approve the document as-is. The document is updated until the reviewers are satisfied with the quality of the document. The document is then sent to the customer for approval. The customer can require changes or accept the document. When the customer requires changes, an engineer is assigned to make the changes to the document. When those changes are made, two other engineers must review those changes. When those reviewers are satisfied with the changes, the document is sent back to the customer. This may happen through several iterations until the customer is satisfied with the document. b. Analyze the DFDs you created in Part a. What recommendations for improvements can you make based on this analysis? Draw new logical DFDs that represent the requirements you would suggest for an improved document management system. Remember, these are to be logical DFDs, so consider improvements independent of technology that can be used to support the management of these documents. Answer: The DFDs show an inherent weakness in the processes used for the data to flow. The document may go through several revisions before the customer has seen any information from the document, thereby wasting a massive amount of effort. A better process would seek customer input on the requirements that are used as input into the 2.0 Complete Draft process. This could be done by extending the process using this as the Level-1 diagram. Note that this is not balanced with the context diagram above. 6-26. A company has various rules for how payments to suppliers are to be authorized. Some payments are in response to an approved purchase order. For approved purchase orders under $5,000, the accounting clerk can immediately issue a check against that purchase order and sign the check. For approved purchase orders between $5,000 and $10,000, the accounting clerk can immediately issue a check but must additionally obtain a second signature. Payments for approved purchase orders over $10,000 always require the approval of the accounting manager to issue the check as well as the signature of two accounting clerks. Payments that are not covered by a purchase order that are under $5,000 must be approved by the accounting manager and a departmental manager that will absorb the cost of the payment into that department’s budget. Such checks can be signed by a single accounting clerk. Payments that are not covered by a purchase order that are between $5,000 and $10,000 must be approved by the accounting manager and a departmental manager, and the check must have two signatures. Finally, payments that are not covered by a purchase order that exceed $10,000 must be approved by a department manager, the accounting manager, and the Chief Financial Officer. Such checks require two signatures. Use a decision table to represent the logic in this process. Write down any assumptions you have to make. Answer: Purchase Amount: S = $10,000 6-27. A relatively small company that sells eyeglasses to the public wants to incentivize its sales staff to upsell customers on higher-quality frames, lenses, and options. To do this, the company has decided to pay the sales representatives based on a percentage of the profit earned on the glasses. All sales representatives will earn 15% of the profit on the eyeglasses. However, the owners are concerned that the sales staff will fear earning less than they do now. Therefore, those who were already working at the company are grandfathered into an arrangement where the workers are guaranteed to earn at least their base salary. Newly hired employees, however, are guaranteed only minimum wage based on the hours worked. To ensure only productive employees are retained, employees who are underperforming for 3 months in a row are automatically terminated. For those employees who are grandfathered in, any month where the representative earns only the salary is considered underperforming. For newer employees, the bottom quarter of the employees based on profit earned per hour worked are considered underperforming. Use a decision table to represent the logic in this process. Write down any assumptions you have to make. Answer: Before reducing, we can have a table like this: After reducing, we have a decision table like this: 6-28. A large technology company receives thousands of applications per day from software engineers who hope to work for that company. To help manage the constant flow of applications, a process has been created to streamline identifying applicants for specific openings as they occur. Those applications that are not in an approved file format are discarded and not processed in any way. All applications are first fact-checked automatically by detecting any inconsistencies with the application and the resume, as well as other resume sites available online. For any applications with more than one inconsistency, the application is automatically rejected as untruthful. Next, the application is checked against the database of other applications already in the system. If such an application exists, the older application is purged and the new application continues processing. Any applications that do not contain at least 15 of the top 200 keywords that the company is looking for are rejected. Next, the phone numbers of references are checked to ensure they are a valid, working phone number. These applicants are then retained in a searchable database. When managers send a hiring request, the fifty best applications that most closely match the desired attributes are sent to the manager. That manager selects the top 10 applications, which are then screened for bad credit, with credit scores below 500 eliminated from the hiring process. If there are at least 5 remaining candidates, they are all invited to participate in phone interviews. If there are fewer than 5 remaining candidates, the next 10 best matches are added to the pool and screened for poor credit, and any remaining candidates are invited to participate in phone interviews. Present this logic in a decision table. Write down any assumptions you have to make. Answer: 6-29. A huge retail store must carefully manage its inventory levels. Stock-outs (where there is none of an item on a shelf) can cause missed sales, while too much inventory costs the company money in storage, ties up capital, and carries the risk of the products losing value. To balance these requirements, the store has chosen to use just-in-time ordering. To accomplish this, reorders are automatically generated by an information system (called the reorder system). Each item has a floor value, which is the fewest units of an item that should be in the store at all time, as well as a ceiling value, which is the maximum number of units that can be stored on the allocated shelf space. Vendors are required to commit to delivering product in either two days or one week. For vendors of the two day plan, the reorder system calculates the amount of product purchased by customers in the past week, doubles the quantity, and then adds the inventory floor. The quantity on-hand is then subtracted. This is the desired order quantity. If this quantity added to the current inventory is greater than the ceiling, then the order quantity is reduced to the ceiling value less on-hand quantity. If the desired order quantity is greater than the sales for the previous month, a special report is generated and provided to management and the order must be approved before being sent to the vendor. All other orders are automatically placed with the vendor. However, if a product experiences a stock-out, an emergency order is automatically generated for the ceiling amount or the quantity sold in the last month, whichever is less. For vendors on the one week plan, the reorder system calculates the amount of inventory sold in the last two weeks, doubles the quantity, and then adds the floor to create the desired stock level. If this level is greater than the ceiling, the desired stock level is lowered to the ceiling and a report is generated for management to determine if more space should be allocated. The on-hand stock is subtracted from the desired stock level, yielding the desired order level. If the desired order level is greater than the number of units sold in the last two months, a special report is generated and provided to management and the order must be approved before being sent to the vendor. All other orders are automatically placed with the vendor. However, if a product experiences a stock-out, an emergency order is automatically generated for the ceiling amount or the quantity sold in the last month, whichever is less. Present this logic in a decision table. Write down any assumptions you have to make. Answer: Discussion Questions Solutions 6-30. Discuss the importance of diagramming tools for process modeling. Without such tools, what would an analyst do to model diagrams? Answer: Diagramming tools speed the development of DFDs. Most importantly, CASE tools can aid in the analysis of these diagrams, helping to determine their completeness and consistency. One alternative that analysts have is to generate the diagrams by hand. This, however, is a very inefficient, error-prone alternative. 6-31. Think and write about how data-flow diagrams might be modified to allow for time considerations to be adequately incorporated. Answer: Students should identify several creative, innovative methods. One suggestion is to make notations on the data flows and in the processes to indicate their timing. You might also encourage students to contrast data-flow diagrams with state diagrams (presented in Appendix A). To incorporate time considerations into data-flow diagrams (DFDs), you can integrate the following modifications: 1. Temporal Labels: Add timestamps or time labels to data flows and processes to indicate when data is generated, processed, or consumed. 2. Time-Based Notations: Use different symbols or annotations to represent time constraints or deadlines associated with data flows and processes. 3. Process Timing: Include time estimates or time-based constraints within process descriptions to show expected durations or deadlines. 4. State Diagrams: Complement DFDs with state diagrams that capture the states of data over time, showing how data transitions between different states. 5. Sequence Diagrams: Integrate sequence diagrams to show the order of events and interactions over time, illustrating how data flows through processes in a temporal sequence. These modifications help visualize not just the flow of data but also the timing aspects crucial for time-sensitive systems. 6-32. How would you answer someone who told you that data-flow diagrams were too simple and took too long to draw to be of much use? What if they also said that keeping data-flow diagrams up-to-date took too much effort, compared to the potential benefits? Answer: The simplicity of DFDs is part of their appeal. The information contained in the DFDs is very useful, understandable, and valuable. DFDs can serve as a communication tool between analysts and end users, with the end users easily interpreting the information conveyed in these diagrams. Also, DFDs are very beneficial for performing gap analysis. A strong argument can be made for the use of CASE tools and the ability of these tools to speed DFD development, as well as systems development, and the ease with which CASE tools can update DFDs. 6-33. Find another example of where data-flow diagrams were successfully used to support business process reengineering. Write a report, complete with DFDs, about what you found. Answer: Encourage students to locate case studies of companies that have recently undergone a reengineering process. Case studies are available in trade journals, in the library, and on the Web. Case Problems Solutions 6-34. Pine Valley Case Exercises Solutions a. Construct a context data-flow diagram, illustrating the Customer Tracking System’s scope. Answer: A suggested context diagram is provided below. b. Construct a level-0 diagram for the Customer Tracking System. Answer: While student interpretations will vary, a suggested answer is provided below. c. Using the level-0 diagram that you constructed above, select one of the level-0 processes, and prepare a level-1 diagram. Answer: While student interpretations will vary, a suggested answer is provided below. d. Exchange your diagrams with another class member. Ask your class member to review your diagrams for completeness and consistency. What errors did he or she find? Correct these errors. Answer: Encourage students to review the data-flow diagramming rules presented in Table 6-2. Using these rules as a guide, students should then evaluate their classmates’ diagrams. 6-35. Hoosier Burger Case Exercises Solutions a. Modify the Hoosier Burger context-level data-flow diagram (Figure 6–4) to reflect the changes mentioned in the case. Answer: Student interpretations may vary; a suggested answer follows. b. Modify Hoosier Burger’s level-0 diagram (Figure 6–5) to reflect the changes mentioned in the case. Answer: Although student answers will vary, a suggested answer is provided below. c. Prepare level-1 diagrams to reflect the changes mentioned in the case. Answer: Student answers will vary; to facilitate discussion, a level-1 diagram is provided below. d. Exchange your diagrams with those of another class member. Ask your classmate to review your diagrams for completeness and consistency. What errors did he or she find? Correct these errors. Answer: Encourage students to review the data-flow diagramming rules presented in Table 6–2. Using these rules as a guide, students should then evaluate their classmate’s diagrams. After exchanging diagrams with a classmate, address the following common errors they might find: 1. Missing Processes: Add any omitted core processes. 2. Incorrect Data Flows: Correct any wrong or missing data flow connections. 3. Inconsistent Labels: Standardize and clarify labels for processes, data flows, and entities. Update your diagrams accordingly to ensure they are complete and consistent. 6-36. Evergreen Nurseries Case Exercises Solutions a. Construct a context data-flow diagram, illustrating Evergreen Nurseries’ wholesale system. Answer: Student interpretations will vary. A suggested answer follows. b. Construct a level-0 diagram for Evergreen Nurseries’ wholesale system. Answer: Student interpretations will vary; a suggested answer follows. c. Using the level-0 diagram that you constructed in part b, select one of the level-0 processes, and prepare a level-1 diagram. Answer: A suggested answer is provided below. d. Exchange your diagrams with those of another class member. Ask your classmate to review your diagrams for completeness and consistency. What errors did he or she find? Correct these errors. Answer: Encourage your students to review the data-flow diagramming rules presented in Table 6–2. Using these rules as a guide, your students should then evaluate their classmates’ diagrams. After exchanging diagrams: 1. Review Feedback: Obtain specific errors or issues noted by your classmate. 2. Common Errors: Errors may include missing processes, incorrect data flows, or inconsistent labeling. 3. Correct Issues: Update your diagrams to address the feedback: • Add any missing processes. • Correct data flow connections. • Ensure consistent and clear labeling. 4. Final Check: Verify the revised diagrams for completeness and consistency. Ensure the diagrams now accurately reflect the system requirements and are free of errors. Petrie’s Electronics Case Questions Solutions 6-37. Are the DFDs in Figures 6-1 and 6-2 balanced? Show that they are, or are not. If they are not balanced, how can they be fixed? Answer: They are balanced. On both the Context Diagram and the Level-0 there are 2 inflows to the system from the source customer (purchases and coupons) and three outflows (reports, tailored promotions and coupons) from the system to the sink Customer. 6-38. Decompose each of the core processes in Figure 6-2 and draw a new DFD for each core process. Answer: There will be four parts to this answer, one for each of the core processes in Figure 6-2. The answers will vary with each student. What’s important in each decomposition diagram is that it contains the same inputs and outputs for the diagram as are shown as inputs and outputs to the process in Figure 6-2. For example, for the first process, “Record customer activities,” there will be two inputs coming from outside, coupons and purchases, and one output to the outside, transactions. There may be two or more sub-processes on each decomposition diagram. For example, for the process “Record customer activities,” there may be one sub-process for purchases and another for coupons. If the core process cannot e decomposed, there is no need for decomposition. 6-39. Has the team overlooked any core processes in the system that should be in Table 6-1 and Figure 6-2? What would they be? Add them to Table 6-1 and Figure 6-2. Answer: The answer will vary with the student. The question is intended to generate some creativity on the part of the student. They may also come up with some additional functions (core processes) from further research on loyalty programs and their operations. To identify and add overlooked core processes: 1. Review System Requirements: Cross-check the existing processes against system requirements to ensure all core functions are included. 2. Identify Missing Processes: Look for any key functions or operations not represented in Table 6-1 and Figure 6-2. 3. Update Table 6-1: Add any missing core processes to the table with clear descriptions. 4. Revise Figure 6-2: Incorporate the missing processes into the diagram, ensuring they are correctly connected with data flows and entities. Ensure all core processes necessary for the system's operation are included and accurately depicted. 6-40. Redesign Figures 6-1 and 6-2 so that they are clearer and more efficient and more comprehensive. Answer: To redesign Figures 6-1 and 6-2 for clarity, efficiency, and comprehensiveness: 1. Simplify Processes: Ensure each process is distinct and clearly labeled. Minimize unnecessary complexity. 2. Refine Data Flows: Clearly label all data flows, making sure they are straightforward and easy to follow. 3. Update External Entities: Ensure external entities are correctly represented and connected to the appropriate processes. 4. Use Consistent Symbols: Apply consistent DFD symbols and formatting for better readability. 5. Enhance Data Stores: Clearly label data stores and show their interactions with processes. By focusing on these aspects, the redesigned diagrams will be more intuitive and effective. 6-41. Why is it important for the team to create DFDs if they are not going to write the actual system code themselves? Answer: Creating DFDs force analysts (and students) to think about the core processes in a system, the data they use, the sources of that data, the information the processes generate, and where the information goes. All of this information is essential in design and building of a system, even if all of its components are purchased off-the-shelf. Solution Manual for Essentials of Systems Analysis and Design Joseph S. Valacich, Joey F. George, Jeffrey A. Hoffer 9780133546231
Download
Close
Close
