IS421 07 Class Lecture

Information Systems System Analysis 421 Class Seven Structuring System Requirements: Process Modeling 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 8.2 Learning Objectives  Explain the differences among four types of DFDs: current physical, current logical, new physical and new logical  Discuss the use of data flow diagrams as analysis tools  Compare and contrast data flow diagrams with Oracle’s process modeling tool and with functional hierarchy diagrams  Discuss process modeling for Internet applications 8.3 Data Modeling Entity Relationship Data Flow Diagram Prototypes System Modeling • One way to structure unstructured problems is to draw a model – A model is a representation of reality - picture worth a thousand words – Built to understand the existing system as a way to document business requirements – Data modeling is a technique for defining business requirements • Data is viewed as a resource to be shared by as many processes as possible, data must be organized in a way that is flexible and adaptable to unanticipated business requirements System Modeling • Physical model shows not only what a system does but how the system is physically and technically implemented depicts technical design • Logical models depict business requirements illustrates the essence of the system – Move biases that are the results of the way the current system is implemented – Reduce the risk of missing requirements – Allow us to communicate with end users – Help analysts and users understand business terminology and rules Process Modeling • The simplest process model of a system is based on inputs, outputs, and the system itself – Viewed a process – The process symbol defines the boundary of the system – The system is inside the boundary; the environment is outside that boundary – The system exchanges inputs and outputs with its environment – Process is work performed on, or in response to, incoming data flows or conditions Process Modeling • Graphically represent the processes that capture, manipulate, store and distribute data between a system and its environment and among system components • Data flow diagrams (DFD) – Graphically illustrate movement of data between external entities and the processes and data stores within a system • Modeling a system’s process – Utilize information gathered during requirements determination – Structure of the data is also modeled in addition to the processes 8.8 Process Modeling • Deliverables and Outcomes – Set of coherent, interrelated data flow diagrams – Context data flow diagram (DFD) • Scope of system – DFDs of current system • Enables analysts to understand current system – DFDs of new logical system • Technology independent • Show data flows, structure and functional requirements of new system – Project dictionary and CASE repository 8.9 Data Flow Diagrams • Data modeling is done during the project definition stage and refined in physical design • Similar to ERD Data model - DFD also helps the analyst identify business vocabulary and uncover business requirements • Can be used on current system to understand requirements • Can be fit on several sheets of paper • The level of data flow diagram can be compared to a highway and street maps that you might use - National => State => City Guidelines for Drawing DFDs • Iterative Development – Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled • Primitive DFDs – Lowest logical level of decomposition – Decision has to be made when to stop decomposition • Rules for stopping decomposition – When each process has been reduced to a single decision, calculation or database operation – When each data store represents data about a single entity 8.64 – When the system user does not care to see any more detail Using DFDs as Analysis Tools • Gap Analysis – The process of discovering discrepancies between two or more sets of data flow diagrams or discrepancies within a single DFD • Inefficiencies in a system can often be identified through DFDs 8.65 Oracle’s Process Modeler and Functional Hierarchy Diagrams • Process Modeler – Unique to Oracle – Similar to DFDS but outputs and methods differ in several ways – Table 8-4 illustrates differences • Functional Hierarchy Diagrams – Picture of various tasks performed in a business and how they are related – Tasks are broken down into their various parts – Does not include data flows 8.66 Summary • Data flow diagrams (DFD) – Symbols – Rules for creating – Decomposition – Balancing • Four different kinds of DFDs – Current Physical – Current Logical – New Logical – New Physical 8.67 Summary • DFDs for Analysis • DFDs for Business Process Reengineering (BPR) • Oracle’s Process Modeler • Functional Hierarchy Diagrams 8.68 Process Decomposition  What you when a complex system is too difficult to fully understand when viewed as a whole  We separate a system into its component subsystems, which in turn are decomposed into smaller subsystems, until such a time as we have identified manageable subsets of the overall system • This technique is called decomposition – Decomposition is the act of breaking a system into its component subsystems, processes, and subprocesses Each lower level reveals more or less detail) about the overall system Process Decomposition • A decomposition diagram is a popular tool to illustrate system decomposition - also called a hierarchy chart, shows the top down functional decomposition and structure of a system • A decomposition diagram is essentially a planning tool for more detailed processes models, namely, data flow diagrams • The decomposition diagram rules: – Each process in a decomposition diagram is either a parent process, a child process (of a parent), or both – A parent must have two or more children – a single child does not make sense since that would not reveal any additional detail about the system – In most decomposition diagramming standards, a child may have only one parent – A child of one parent may, of course, be the parent of its own children Process Decomposition The System Another Function A Function 1.1 Activity of the Function 1.2 Another Activity of the Function 2.1 Acivity of this Function 2.2 Another Activity of this Function Task 1.1.1 Task 1.2.1 Task 2.1.1 Task 2.2.1 Task 1.1.2 Task 1.2.2 Task 2.1.2 Task 2.2.2 Task 2.1.3 Task 2.2.3 Task 1.1.3 Task 2.1.4 Process Decomposition How you build the hierarchy • Logical processes are work or actions that must be performed no matter how you implement the system • Naming conventions for logical processes depend on where the process is in the decomposition diagram/data flow diagram and type of process depicted • There are three types of logical processes: functions, events, and elementary processes Process Decomposition • A function is a set of related and on-going activities of the business A function has no start or end – it just continuously performs its work as needed – Each of these functions may consist of dozens, or hundreds of more discrete processes to support specific activities and tasks – Functions serve to group the logically related activities and tasks – Functions are named with nouns that reflect the entire function – Think of some functions - Payroll, Order Management, Travel System Process Decomposition's • An event is a logical unit of work that must be completed as a whole An event is triggered by a discrete input, and is completed when the process has responded with appropriate outputs Events are sometimes called transactions – Functions consist of processes that respond to events – Each of these events has a trigger and response that can be defined by its inputs and outputs – System functions are ultimately decomposed into business events – Each business event is represented by a single process that will respond to that event – Name some events for Payroll, OM and Travel Process Decomposition's • An event process can be further decomposed into elementary processes that illustrate in detail how the system must respond to an event • Elementary processes are discrete, detailed activities or tasks required to complete the response to an event In other words, they are the lowest level of detail depicted in a process model A common synonym is primitive process – Elementary processes should be named with a strong action verb followed by an object clause that describes what the work is performed on (or for) DFD: Exercise Problem Draw both a Context and Level DFD for Order Entry Department work process at Bebop Records Bebop Records is a mail order company that distributes CDs and tapes at discount prices to record club members When an order processing clerk receives an order form, she verifies that the sender is a club member by checking the MEMBER FILE If the sender is not a member, the clerk returns the order along with a membership application form If the customer is a member, the clerk verifies the order item data by checking the ITEM FILE Then the clerk enters the order data and saves it to the DAIILY ORDERS FILE At the same time the clerk also prints an invoice and shipping list for each order, which are forwarded to the ORDER FULFILLMENT DEPARTMENT for processing there DFD: Exercise Problem C u s to m e r In fo r m a tio n F r o m C u s to m e r A ccept C u s to m e r In f o r m a tio n A (5 Points) C u s to m e r D a ta C u s to m e r C u s to m e r O rd e r C u s to m e r D a ta P ro d u c e C u s to m e r In v o ic e Detail Problem D.Create a Context DFD and a level zero logical DFD for the following Order Fulfillment System scenario within the Order Fulfillment Department: A CUSTOMER submits a PURCHASE ORDER The FULFILL ORDER process acts on the PURCHASE ORDER by either sending an ORDER REJECT NOTICE back to the CUSTOMER if the CUSTOMER has bad credit, or sending a FULFILLMENT SLIP to the WAREHOUSE Department When a COMPLETED ORDER NOTICE is received from the WAREHOUSE Department signifying they have shipped the product, the CREATE INVOICE process generates an INVOICE and outputs it to both the CUSTOMER (by mail) and the ACCOUNTS RECEIVABLE data store When a CUSTOMER makes a PAYMENT it is processed by APPLY PAYMENT This requires INVOICE DETAIL input from the ACCOUNTS RECEIVABLE data store along with PAYMENT DOCUMENTATION (from the customer) APPLY PAYMENT outputs PAYMENT DETAIL back into the ACCOUNTS RECEIVABLE store and outputs BANK DEPOSIT SLIP to the BANK, and CASH RECEIPTS ENTRY to the ACCOUNTING Department