Presentation on theme: "Chapter 5 Structuring System Requirements: Process Modeling"— Presentation transcript:
1Chapter 5 Structuring System Requirements: Process Modeling Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. HofferChapter 5Structuring System Requirements:Process Modeling5.1Copyright 2006 Prentice-Hall, Inc.
2Copyright 2006 Prentice-Hall, Inc. Learning ObjectivesUnderstand the logical modeling of processes through studying data-flow diagramsHow to draw data-flow diagrams using rules and guidelinesHow to decompose data-flow diagrams into lower-level diagramsBalancing of data-flow diagrams5.2Copyright 2006 Prentice-Hall, Inc.
3Learning Objectives (continued) Discuss the use of data-flow diagrams as analysis toolsRepresent processing logic using Structured English and decision tables5.3Copyright 2006 Prentice-Hall, Inc.
4Copyright 2006 Prentice-Hall, Inc. Process ModelingGraphically represents the processes that capture, manipulate, store and distribute data between a system and its environment and among system componentsData-flow Diagrams (DFD)Graphically illustrate movement of data between external entities and the processes and data stores within a system5.4Copyright 2006 Prentice-Hall, Inc.
5Process Modeling (continued) Modeling a System’s ProcessUtilize information gathered during requirements determinationStructure of the data is also modeled in addition to the processesDeliverables and OutcomesSet of coherent, interrelated data-flow diagrams5.5Copyright 2006 Prentice-Hall, Inc.
6Process Modeling (continued) Deliverables and Outcomes (continued)Context data-flow diagram (DFD)Scope of systemDFDs of current systemEnable analysts to understand current systemDFDs of new logical systemTechnology independentShow data flows, structure and functional requirements of new system5.6Copyright 2006 Prentice-Hall, Inc.
7Process Modeling (continued) Deliverables and Outcomes (continued)Project dictionary and CASE repositoryData-flow Diagramming MechanicsFour symbols are usedSee Figure 5-2Developed by Gane and Sarson5.7Copyright 2006 Prentice-Hall, Inc.
8Copyright 2006 Prentice-Hall, Inc. 5.8Copyright 2006 Prentice-Hall, Inc.
9Data-Flow Diagramming Mechanics Depicts data that are in motion and moving as a unit from one place to another in the systemDrawn as an arrowSelect a meaningful name to represent the data5.9Copyright 2006 Prentice-Hall, Inc.
10Data-Flow Diagramming Mechanics (continued) Data StoreDepicts data at restMay represent data inFile folderComputer-based fileNotebookDrawn as a rectangle with the right vertical line missingLabel includes name of the store as well as the number5.10Copyright 2006 Prentice-Hall, Inc.
11Data-Flow Diagramming Mechanics (continued) ProcessDepicts work or actions performed on data so that they are transformed, stored, or distributedDrawn as a rectangle with rounded cornersNumber of process as well as name are recorded5.11Copyright 2006 Prentice-Hall, Inc.
12Data-Flow Diagramming Mechanics (continued) Source/SinkDepicts the origin and/or destination of the dataSometimes referred to as an external entityDrawn as a square symbolName states what the external agent isBecause they are external, many characteristics are not of interest to us5.12Copyright 2006 Prentice-Hall, Inc.
13Copyright 2006 Prentice-Hall, Inc. 5.13Copyright 2006 Prentice-Hall, Inc.
14Copyright 2006 Prentice-Hall, Inc. 5.14Copyright 2006 Prentice-Hall, Inc.
15Data-Flow Diagramming Definitions Context DiagramA data-flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the systemLevel-O DiagramA data-flow diagram (DFD) that represents a system’s major processes, data flows, and data stores at a higher level5.15Copyright 2006 Prentice-Hall, Inc.
16Developing DFDs: An Example Hoosier Burger’s Automated Food Ordering SystemContext Diagram (Figure 5-4) contains no data stores5.16Copyright 2006 Prentice-Hall, Inc.
17Copyright 2006 Prentice-Hall, Inc. 5.17Copyright 2006 Prentice-Hall, Inc.
18Developing DFDs: An Example (continued) Next step is to expand the context diagram to show the breakdown of processes (Figure 5-5)Copyright 2006 Prentice-Hall, Inc.
19Copyright 2006 Prentice-Hall, Inc. 5.19Copyright 2006 Prentice-Hall, Inc.
20Data-Flow Diagramming Rules Basic rules that apply to all DFDs:Inputs to a process are always different than outputsObjects always have a unique nameIn order to keep the diagram uncluttered, you can repeat data stores and data flows on a diagram5.20Copyright 2006 Prentice-Hall, Inc.
21Data-Flow Diagramming Rules (continued) ProcessNo process can have only outputs (a miracle)No process can have only inputs (black hole)A process has a verb phrase labelData StoreData cannot be moved from one store to anotherData cannot move from an outside source to a data storeData cannot move directly from a data store to a data sinkData store has a noun phrase label5.21Copyright 2006 Prentice-Hall, Inc.
22Data-Flow Diagramming Rules (continued) Source/SinkData cannot move directly from a source to a sinkA source/sink has a noun phrase labelData FlowA data flow has only one direction of flow between symbolsA fork means that exactly the same data go from a common location to two or more processes, data stores, or sources/sinks5.22Copyright 2006 Prentice-Hall, Inc.
23Data-Flow Diagramming Rules (continued) Data Flow (Continued)A join means that exactly the same data come from any two or more different processes, data stores or sources/sinks to a common locationA data flow cannot go directly back to the same process it leavesA data flow to a data store means updateA data flow from a data store means retrieve or useA data flow has a noun phrase label5.23Copyright 2006 Prentice-Hall, Inc.
24Copyright 2006 Prentice-Hall, Inc. Decomposition of DFDsFunctional DecompositionAct of going from one single system to many component processesRepetitive procedureLowest level is called a primitive DFDLevel-n DiagramsA DFD that is the result of n nested decompositions of a series of subprocesses from a process on a level-0 diagram5.24Copyright 2006 Prentice-Hall, Inc.
25Copyright 2006 Prentice-Hall, Inc. Balancing DFDsWhen decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decompositionThis is called balancingExample: Hoosier BurgersIn Figure 5-4, notice that there is one input to the system, the customer orderThree outputs:Customer receiptFood orderManagement reports5.25Copyright 2006 Prentice-Hall, Inc.
26Balancing DFDs (continued) Example (Continued)Notice Figure We have the same inputs and outputsNo new inputs or outputs have been introducedWe can say that the context diagram and level-0 DFD are balanced5.26Copyright 2006 Prentice-Hall, Inc.
27Balancing DFDs An Unbalanced Example In context diagram, we have one input to the system, A and one output, BLevel-0 diagram has one additional data flow, CThese DFDs are not balanced5.27Copyright 2006 Prentice-Hall, Inc.
28Copyright 2006 Prentice-Hall, Inc. Balancing DFDsWe can split a data flow into separate data flows on a lower level diagram5.28Copyright 2006 Prentice-Hall, Inc.
29Balancing DFDs Four Additional Advanced Rules 5.29Copyright 2006 Prentice-Hall, Inc.
30Guidelines for Drawing DFDs CompletenessDFD must include all components necessary for systemEach component must be fully described in the project dictionary or CASE repositoryConsistencyThe extent to which information contained on one level of a set of nested DFDs is also included on other levels5.30Copyright 2006 Prentice-Hall, Inc.
31Guidelines for Drawing DFDs (continued) TimingTime is not represented well on DFDsBest to draw DFDs as if the system has never started and will never stop.Iterative DevelopmentAnalyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled5.31Copyright 2006 Prentice-Hall, Inc.
32Guidelines for Drawing DFDs (continued) Primitive DFDsLowest logical level of decompositionDecision has to be made when to stop decomposition5.32Copyright 2006 Prentice-Hall, Inc.
33Guidelines for Drawing DFDs (continued) Rules for stopping decomposition:When each process has been reduced to a single decision, calculation or database operationWhen each data store represents data about a single entityWhen the system user does not care to see any more detail5.33Copyright 2006 Prentice-Hall, Inc.
34Guidelines for Drawing DFDs (continued) Rules for stopping decomposition: (continued)When every data flow does not need to be split further to show that data are handled in various waysWhen you believe that you have shown each business form or transaction, online display and report as a single data flowWhen you believe that there is a separate process for each choice on all lowest-level menu options5.34Copyright 2006 Prentice-Hall, Inc.
35Using DFDs as Analysis Tools Gap AnalysisThe process of discovering discrepancies between two or more sets of data-flow diagrams or discrepancies within a single DFDInefficiencies in a system can often be identified through DFDs5.35Copyright 2006 Prentice-Hall, Inc.
36Using DFDs in Business Process Reengineering Example: IBM CreditCredit approval process is required six days before Business Process Reengineering (see Fig 5-12)5.36Copyright 2006 Prentice-Hall, Inc.
37Using DFDs in Business Process Reengineering (continued) After Business Reprocess Engineering, IBM was able to process 100 times the number of transactions in the same amount of time5.37Copyright 2006 Prentice-Hall, Inc.
38Copyright 2006 Prentice-Hall, Inc. Logic ModelingData-flow diagrams do not show the logic inside the processesLogic modeling involves representing internal structure and functionality of processes depicted on a DFDTwo methods:Structured EnglishDecision Tables5.38Copyright 2006 Prentice-Hall, Inc.
39Modeling Logic with Structured English Modified form of English used to specify the logic of information processesUses a subset of EnglishAction verbsNoun phrasesNo adjectives or adverbsNo specific standards5.39Copyright 2006 Prentice-Hall, Inc.
40Modeling Logic with Structured English (continued) Similar to programming languageIf conditionsCase statementsFigure 5-15 shows structured English representation for Hoosier Burger5.40Copyright 2006 Prentice-Hall, Inc.
41Copyright 2006 Prentice-Hall, Inc. 5.41Copyright 2006 Prentice-Hall, Inc.
42Modeling Logic with Decision Tables A matrix representation of the logic of a decisionSpecifies the possible conditions and the resulting actionsBest used for complicated decision logic5.42Copyright 2006 Prentice-Hall, Inc.
43Modeling Logic with Decision Tables (continued) Consists of three parts:Condition stubsLists condition relevant to decisionAction stubsActions that result for a given set of conditionsRulesSpecify which actions are to be followed for a given set of conditions5.43Copyright 2006 Prentice-Hall, Inc.
44Modeling Logic with Decision Tables (continued) Indifferent ConditionCondition whose value does not affect which action is taken for two or more rulesStandard procedure for creating decision tables:Name the conditions and values each condition can assumeName all possible actions that can occurList all possible rulesDefine the actions for each rule (See Figure 5-18)Simplify the decision table (See Figure 5-19)5.44Copyright 2006 Prentice-Hall, Inc.
45Copyright 2006 Prentice-Hall, Inc. 5.45Copyright 2006 Prentice-Hall, Inc.
46Copyright 2006 Prentice-Hall, Inc. 5.46Copyright 2006 Prentice-Hall, Inc.
47Process Modeling for Electronic Commerce Application Process modeling for electronic commerce projects is no different than other projectsSee Pine Valley Furniture example; Table 5-45.47Copyright 2006 Prentice-Hall, Inc.
48Copyright 2006 Prentice-Hall, Inc. 5.48Copyright 2006 Prentice-Hall, Inc.
49Copyright 2006 Prentice-Hall, Inc. SummaryData-flow Diagrams (DFD)SymbolsRules for creatingDecompositionBalancingDFDs for AnalysisDFDs for Business Process Reengineering (BPR)5.49Copyright 2006 Prentice-Hall, Inc.
50Copyright 2006 Prentice-Hall, Inc. Summary (continued)Logic ModelingStructured EnglishDecision TablesInternet Development Process Modeling5.50Copyright 2006 Prentice-Hall, Inc.