1. Copyright 2002 Prentice-Hall, Inc. Chapter 7 Structuring System Requirements: Process Modeling

2. Learning Objectives Understand the logical modeling of processes through studying data flow diagrams How to draw data flow diagrams using rules and guidelines How to decompose data flow diagrams into lower-level diagrams Balancing of data flow diagrams

3. Structuring System Requirements Modeling a system’s process  The two sub-phases of the analysis phase of the SDLC Requirement determination Requirements structuring In the requirement structuring phase, the SA must organize and utilize the information gathered during requirements determination into a meaningful representation of the IS that exists (Process Modeling) Model the processing logic and the timing of the events (logic Modeling). Structure of the data within the system (Data Modeling)

5. Process Modeling Graphically represent the functions or processes that capture, manipulate, store and distribute data between a system and its environment and among system components A common form of process model is Data flow diagram (DFD)

6. Process Modeling Data flow diagrams enable us to model  how data flows through an information system (i.e. between external entities and the processes and data stores within a system),  the relationship among data flows, and  how data is stored at specific locations.  the processes that change or transform data.

7. Process Modeling As data flow diagrams concentrate on the movement of data between processes, these diagrams are called process models.

8. Process Modeling Deliverables and Outcomes  Set of coherent, interrelated data flow diagrams  Context data flow diagram (DFD) Scope of the system, indicating which elements are inside and outside the system.  DFDs of current logical system Technology-independent DFD Shows what data processing functions are performed by the current information system. Enables analysts to understand current system 8.8

9. Process Modeling Deliverables and outcomes (continued)  DFDs of new logical system Technology independent Show data flows, structure and functional requirements of new system 8.9

10. Data Flow Diagramming Mechanics DFDs are versatile diagramming tools. Four symbols are used to represent both physical and logical IS. See Figure 8-2  Two different standard sets can be used DeMarco and Yourdan Gane and Sarson 8.10

11. Figure 8-2 Comparison of DeMarco & Yourdan and Gane & Sarson DFD symbol sets 8.11

12. Data Flow Diagramming Mechanics Data Flow  Depicts data in motion and moving from one place to another in the system.  A data flow is data that move together. It can be composed of many individual pieces of data that are generated at the same time and flow together to common destinations.  Drawn as an arrow  Select a meaningful name to represent the data  Example: Data on a customer order form or a payroll check. The results of a query to a database. The contents of a printed report Data on a data entry computer display form. 8.12

13. Data Flow Diagramming Mechanics Data Store  Depicts data at rest  May represent one or many different physical locations for data e.g. File folder Computer-based file(s) Notebook  Represented by a rectangle with a vertical line on the left side. At the left end, the number for the data store is written. At the right side, a meaningful label for the data store is written.  Examples : Data about the customers, students, customer orders, or suppliers invoices, roster of classes 8.13

14. Data Flow Diagramming Mechanics Process  Depicts work or action performed on data so that they are transformed, stored or distributed  Represented by a rectangle with rounded corners, and a line drawn through the top. The upper portion is used to indicate the number of process, and the lower portion indicates the name for the process.  When modeling data processing of a system, it doesn’t matter whether a process is performed manually or by a computer.  Examples: Generate paycheck Calculate overtime pay Compute grade point average (gpa) 8.14

15. Data Flow Diagramming Mechanics Source/Sink  Depicts the origin and/or destination of the data i.e. Source which produces data or Sink which consumes or accepts data. Sometimes referred to as an external entity, as they are outside the system.  Drawn as a square symbol  Name states what the external agent is 8.15

16. Data Flow Diagramming Mechanics  Because they are external to the Information system, many characteristics are not of interest to us  Examples of sources or sinks are as: A person inside or outside the business units supported by the system the SA is analyzing and who interacts with the system e.g. customer Another information system with which the system (the SA is analyzing) exchanges information e.g. instructor information system and student information system Another Organization that sends data to or receives information from the system ( the SA is analyzing) e.g. book supplier and the university.

17. Do not consider the following characteristics of sources and sinks When drawing Data Flow Diagrams, do not show Direct Interactions that occur between source and sinks. How information is used in the Source or Sink ( i.e. show a source or sink a black box) How to control or redesigning a source or sink from the perspective of the information system. Sources or Sink directly accessing stored data since external agents cannot directly manipulate data stored within the system i.e. processes within the system must receive or distribute data between the system and its environment.

18. Example : Hoosier Burger’s Customer Order System Hoosier Burger uses an information system known as customer order information system which is used to  take Customer order from the Customer. and gives  the Food order to the kitchen,  the Receipt is to the Customer  Management Reports to the Restaurant Manager Draw the highest level Data flow Diagram i.e. context diagram

19. Data Flow Diagramming Definitions Context Diagram  A data flow diagram (DFD) of the scope of an Information system that shows the Whole system boundaries, external entities that interact with the system and major data flows between the external entities and the system  Highest level view of the system  The context diagram contains only one process labeled as “0” representing the entire system.  The data stores of the system are conceptually inside the one process, no data stores appear on a context diagram.  The sources/sinks represent its environment 8.19

20. Figure 8-4 Context diagram of Hoosier Burger’s automated food ordering system 8.20

21. Data Flow Diagramming Definitions Level-0 Diagram (Diagram after the Context diagram) Next step is to expand the context diagram shown in fig 8-4 to show the breakdown of processes  A data flow diagram (DFD) that represents a system’s major individual processes (functions), data flows and data stores at a high level of detail  Each process has a number that ends in.0  Capturing data from different sources  Maintaining data stores  Producing and distributing data to different sinks  High level descriptions of data transformation operations.

22. Developing DFDs: An Example  The system begins by receiving and transform the customer order ( name the process as 1.0) and outputs four data flows. 1. Food order send to the kitchen. 2. goods sold data. 3. inventory data 4. a receipt given to the customer. 8.22

23. Developing DFDs: An Example Goods sold data obtained from process 1.0 is used to update the Goods Sold File by adding the new good sold data obtained in process 1.0 (Name the process as P2.0 and the data file as D2). Inventory data obtained from process 1.0 is used to update the Inventory File by deducting the inventory data (no. of items from the item stock) from the inventory file( Name the process as P3.0 and the data store as D1) The Management reports are produced by reading the information from the updated D1 and D2 i.e. daily goods amount sold file and inventory data file ( Name the process as P4.0). These Management reports are given to the Restaurant Manager 8.23

24. Figure 8-5 Level-0 DFD of Hoosier Burger’s food ordering system 8.24

25. Functional decomposition The act of going from a single system to component processes is called functional decomposition Functional decomposition is an iterative process of breaking the description or perspective of an system down into finer and finer details. For Hoosier Burger system, the larger system is broken into four processes. Each of the processes ( or subsystems) are also candidates for decomposition. Each process may consist of several sub-processes. Decomposition continues until no sub-process can logically be broken down any further. The lowest level of DFDs is called a primitive DFD.

26. Decomposition of level-0 DFD of Hoosier Burger System Level -1 Data flow Diagram The first process 1.0 called Receive and Transform Customer Food order is decomposed into five 5 logically separate processes or functions. They are  Receive customer order ( P 1.1)  Transform the order into a kitchen format used for the kitchen (P1.2)  Transform the order into a printed receipt for the customer ( P1.3)  Transform the order into goods sold data ( P1.4)  Transform the order into inventory data ( P1.5) No source and sinks are represented are not shown in level -1 DFD. Decomposing Process 1.0, 2.0 or 3.0 or 4.0 would create level-1 diagram.

27. Level - 1

28. Decomposition of level-0 DFD of Hoosier Burger System Process 2.0 and Process 3.0 use data input to update data stores. Since updating a data store is a singular logical function, neither of the processes need to be decomposed further. Each level-1, -2 or –n DFD represents one process on a level-(n-1) DFD. Each DFD should be on a separate page. Process 4.0 (Produce Management reports) can be decomposed into three sub-processes.  Access Goods Sold and Inventory data (P 4.1)  Aggregate Goods Sold Inventory Data ( P 4.2)  Prepare Management Reports ( P 4.3)

29. Level -1

30. Decomposition of level-1 DFD of Hoosier Burger System Process 4.3 should be further decomposed into sub processes  Format Management Reports (P 4.3.1)  Print Management Reports ( P 4.3.2)

31. Level 2

32. Data Flow Diagramming Rules Basic rules that apply to all DFDs  Inputs to a process are always different than outputs. The processes transforms inputs into outputs, rather than simply pass the data through without some manipulation. Sometimes process produces same input data and at the same time new data flows  Objects on a DFD always have a unique name In order to keep the diagram uncluttered, you can repeat data stores and sources/sinks on a diagram. 8.32

33. Data Flow Diagramming Rules Process  No process can have only outputs (a miracle)  No process can have only inputs (black hole)  A process has a verb phrase label Data Store  Data cannot be moved directly from one store to another.  Data cannot move directly from an outside source to a data store  Data cannot move directly from a data store to a data sink  Data store has a noun phrase label 8.33

34. Data Flow Diagramming Rules Source/Sink  Data cannot move directly from a source to a sink  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 direction  A fork means that exactly the same data goes from a common location to two or more processes, data stores or sources/sinks 8.34

35. Data Flow Diagramming Rules Data Flow (Continued) L. A join means that exactly the same data comes from any two or more different processes, data stores or sources/sinks to a common location M. 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. N. A data flow to a data store means update O. A data flow from a data store means retrieve or use P. A data flow has a noun phrase label 8.35

36. Balancing DFDs When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition This is called balancing Example: Hoosier Burgers  In Figure 8-4, notice that there is one input to the system, the customer order  Three outputs: Customer receipt Food order Management reports 8.36

37. Balancing DFDs Example (Continued)  Notice Figure 8-5. We have the same inputs and outputs  No new inputs or outputs have been introduced  We can say that the context diagram and level-0 DFD are balanced 8.37

38. Balancing DFDs Notice Fig 8-7, where Process 1.0 from the level-0 DFD has been decomposed. Process 1.0 has one input and four outputs. The inputs and outputs in level-1 diagram are the same. No new inputs and outputs have been added. Compare Process 4.0 in fig 8-5 to its decomposition in fig 8-8, the inputs and outputs are the same.

39. Balancing DFDs An unbalanced example  Figure 8-10  In context diagram, we have one input to the system, A and one output, B  Level-0 diagram has one additional data flow, C  These DFDs are not balanced 8.39

40. Figure 8-10 An unbalanced set of data flow diagrams (a) Context diagram (b) Level-0 diagram 8.40

41. Balancing DFDs The DFDs are balanced when we split a data flow going to a process into separate data flows going to two processes (see Figure 8-11). These diagrams are still balanced since exactly the same data are included in each diagram. Balancing leads to four additional advanced rules (See Table 8-3) 8.41

42. Advanced Rules governing data flow diagrams A composite data flow on one level can be split into component data flows at the next level, but no new data can be added. The inputs to a process must be sufficient to produce the output from the process. To avoid having data flow lines cross each other, repeat data stores or source/sinks on a DFD. Use an additional symbol, like a double line on the middle vertical line of a data store symbol, or a diagonal line in a corner of a sink/source square

45. Guidelines for Drawing DFDs Completeness  DFD must include all components necessary for system  Each component must be fully described in the project dictionary or CASE repository Consistency  The extent to which information contained on one level of a set of nested DFDs is also included on other levels 8.45

46. Guidelines for Drawing DFDs Timing  Time is not represented well on DFDs  Best to draw DFDs as if the system has never started and will never stop. Iterative Development  Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled 8.46

47. Guidelines for Drawing DFDs Primitive DFDs  Lowest logical level of decomposition  Decision has to be made when to stop decomposition 8.47

48. Guidelines for Drawing DFDs Rules for stopping decomposition  When each process has been reduced to a single decision, single calculation or single database operation  When each data store represents data about a single entity, such as a customer, employee, product or order.  When the system user does not care to see any more detail 8.48

49. Guidelines for Drawing DFDs Rules for stopping decomposition (continued)  When the analyst have documented sufficient detail to do subsequent systems development task.  When every data flow does not need to be split further to show that data are handled in various ways  When you believe that you have shown each business form or transaction, on-line display and report as a single data flow  When you believe that there is a separate process for each choice on all lowest-level menu options 8.49

50. Using DFDs as Analysis Tools Gap Analysis  The process of discovering discrepancies between two or more sets of data flow diagrams, representing two or more states of an IS or discrepancies within a single DFD Inefficiencies in a system can often be identified through DFDs 8.50