IS 421 Information Systems Analysis James Nowotarski 28 October 2002

Practice data flow diagramming Understand requirements for assignment 4 and quiz 3 Today’s Objectives

Course Map Contents 1. Introduction Planning Phase 2. Project Initiation 3. Project Management Analysis Phase 4. Systems Analysis 5. Gathering Information 6. Process Modeling 7. Data Modeling Assignments Quizzes Final Week Core Exam Review

Process Modeling in the Analysis Phase From Planning Phase: System request Feasibility analysis Workplan. Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Develop Data Model Develop Process Model Prepare Proposal To Design Phase: Deliverables: Analysis PlanFunctional Requirements Quality Requirements System Concept Data Model Process Model System Proposal Develop Concept for To-Be System

Topic Duration Grading System Exercise60 minutes *** Break15 minutes DFD60 minutes ATB Homework45 minutes Assignment 4 and Quiz 3 Intro10 minutes Today’s agenda

Topic Duration Grading System Exercise60 minutes *** Break15 minutes DFD60 minutes ATB Homework45 minutes Assignment 4 and Quiz 3 Intro10 minutes Today’s agenda

Grading System Exercise

Grading System ERD

Grading System DFD Context

Grading System DFD Level 0

Problem statement Al Burns is the professor for the class. He manually creates a spreadsheet with all the student information based on a course roster he gets from Campus Connect. He also creates a list of assignments, a description for each assignment, and a grading key for each one. Students complete the assignment and give them to Al Burns. Al Burns collects the assignments and gives them to Ms. Grader for grading. Ms. Grader grades the assignments based on a key provided by Al Burns, and assigns a score (grade) from 0 to 5. She then records the scores for the students on the spreadsheet. Grades are reported back to students via a course web page created from the spreadsheet. Assignment: Draw a context diagram and level 0 diagram for the Grading System.

DFD Step-by-Step (1) Al Burns is the professor for the class.

DFD Step-by-Step (2) He manually creates a spreadsheet with all the student information based on a course roster he gets from Campus Connect. Can’t show it this way, can’t have a data flow going from external entity to external entity

DFD Step-by-Step (2) He manually creates a spreadsheet with all the student information based on a course roster he gets from Campus Connect.

DFD Step-by-Step (3) He also creates a list of assignments, a description for each assignment, and a grading key for each one.

DFD Step-by-Step (4) Students complete the assignment and give them to Al Burns.

DFD Step-by-Step (4) Students complete the assignment and give them to Al Burns. What about distributing the assignment?

DFD Step-by-Step (5) Al Burns collects the assignments and gives them to Ms. Grader for grading.

DFD Step-by-Step (6) Ms. Grader grades the assignments based on a key provided by Al Burns, and assigns a score (grade) from 0 to 5.

DFD Step-by-Step (7) She then records the scores for the students on the spreadsheet.

DFD Step-by-Step (8) Grades are reported back to students via a course web page created from the spreadsheet.

Topic Duration Grading System Exercise60 minutes *** Break15 minutes DFD60 minutes ATB Homework45 minutes Assignment 4 and Quiz 3 Intro10 minutes Today’s agenda

Data Flow Diagrams

DFD Elements

Key Definitions A process model is a formal way of representing business processes –Illustrates processes/activities and how data moves among them Data flow diagramming is a technique for creating a process model. –The primary output of data flow diagramming is a data flow diagram (DFD)

Key Definitions Logical process models describe processes without suggesting how they are conducted Physical models include information about how the processes are implemented

Data vs. Process Which is the best starting point for developing a system: –Data model? –Process model?

Some Rules for External Entities External people, organizations, systems and data stores Reside outside the system, but interact with system Either receive info from system (“sink”) or provide data to the system (“source”) Examples: Customers, managers Not clerks or other staff No relation to entities that are part of ERD -- Unfortunate duplication of terminology External Entities

Some Rules for Data Stores Internal to the system Data at rest Include in system if the system processes transform the data –Create, Update, Delete Every data store on DFD should correspond to an entity on an ERD Must have at least one input data flow (or else they never contain any data) Usually have at least one output data flow Data can only enter a data store from a process and can only leave a data store to a process Data Stores D1

Some Rules for Data Flows Data in motion –From external entity (“source”) to system –From system to external entity (“sink”) –From internal symbol to internal symbol, but always either start or end at a process –Not designed to show materials flow, just data Data Flow

Some Rules for Processes Always internal to system Transforms inputs to outputs Law of conservation of data: #1: Data stays at rest unless moved by a process. #2: Processes cannot consume or manufacture data –Must have at least 1 input data flow (to avoid miracles) –Must have at least 1 output data flow (to avoid black holes) –Should have sufficient inputs to create outputs (to avoid gray holes) 0. Processes

Creating Data Flow Diagrams Creating DFDs is a highly iterative process of gradual refinement. General steps: 1. Create Use Cases/textual requirements descriptions 2. Create a Context diagram 3. Create DFD fragments for each use case/requirement 4. Create a Level 0 diagram from fragments 5. Decompose to Level 1,2,… 6. Go to step 1 and revise as necessary 7. Validate DFDs with users.

Creating Use Cases

Step 1. Use Cases Use case=Set of activities that the system performs to produce some output result “Means to an end” - Use case is a more user- friendly way to start working with users to define process model –Use case info is transformed to DFD later Use case is a tool for end users, not programmers Creating use cases is an iterative process

Process modeling Prepare use cases use case reports Create DFDs Users data flow diagrams business process info Easier for users to work with than DFDs Info gathered through interviews, JAD, etc. To Design

Step 1. Use Cases Anatomy of a use case (see pp.155, 162): –Name –Short description –Triggers (system is at rest until trigger event occurs) External (e.g., customer calls) Temporal (e.g., payment is overdue) –Inputs –Outputs –Steps

Step 1. Use Cases Use case name becomes a process name on the level 0 DFD Major inputs become data flows Major outputs become data flows Major steps performed become process names on the level 1 DFD Destination corresponds to data store or external entity Transforming use case to DFD

Creating Data Flow Diagrams

Steps in Building DFDs 2. Create the context diagram 3. Create DFD fragments for each use case 4. Organize DFD fragments into level 0 diagram 5. Decompose level 0 DFDs as needed 6. Go to step 1 and revise as necessary 7. Validate DFDs with users.

Step 2. Context Diagram Shows the context into which the business process fits Shows the overall business process as just one process Shows all the external entities and the data flows into and out of the system from them

Step 2. Context Diagram Draw the overall system as a process. –Number the process 0. –Label the process as the name of the system. Draw and label all external entities. No data stores, unless external. Draw data flows for all possible data coming from or going to external entities –Bundle data flows as you deem necessary

Context Diagram Example

Step 3. Create DFD Fragments For each use case, create a DFD fragment. One process (verb phrase) per fragment Maintain organization’s viewpoint in naming processes Layouts often place: –Process in the center –Inputs from the left –Outputs to the right –Add data stores beneath the processes

DFD Fragment Example

Step 4. Level 0 Diagram Integrate DFD fragments to a Level 0 DFD There will be one Level 0 diagram, –Shows all the processes that comprise the overall system –A decomposition of the process on the context diagram Shows how information moves from and to each process

Level 0 Tips Generally move from top to bottom, left to right Minimize crossed lines Iterate as needed –The DFD is often drawn many times before it is finished, even with very experienced systems analysts Data stores are not usually included

DFD Example Patient Find patient 1 Update patient 3 Add new patient 4 Delete patient 2 New patient information Changes to patient information Patient name D1 Patient Information Patient information Patient information to delete Patient info to be updated Updated patient information Patient information Deleted patient

Some Data Flow Rules A process moves data from place to place in the system. On a data flow diagram, processes may move data between certain symbols (data stores, external entities, and other processes). However, data may not be moved without a process. To help you understand and appreciate this, fill in the empty cells in the following table. The cell entries should either be 1) An example of how data could be moved; 2) N/A to indicate this cannot be done. In this example, “customer information” may be moved from an external entity to a process (e.g., a customer gives their address and credit card information to a sales agent). The “N/A” suggests data cannot be moved from a data store directly to an external entity, which is true (you need a process in between them).

Relationship Among DFD levels

Step 5. Level 1 Diagrams A major step on the use case is usually a process on the Level 1 DFD Level 1 DFD shows all the processes that comprise a single process on the level 0 diagram Inputs to step are input data flows to process Outputs to step are output data flows from process In general, # level 1 DFDs = # of processes on level 0 DFD

Key Definition Decomposition is the process of modeling the system and its components in increasing levels of detail. –Ideally 3-9 processes per DFD Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

Are these in balance? Context Level 0

Hierarchical Consistency Balancing Data Flows –An input (output) data flow on a PARENT diagram must appear on a CHILD diagram as input (output). –Conversely, an input (output) data flow on a CHILD diagram must appear on a PARENT diagram as input (output). –A set of data flows on a child diagram that were split from a data flow on a parent diagram must match the parent data flow's composition.

Data Flow Splits and Joins A data flow split shows where a flow is broken into its component parts for use in separate processes Data flow splits need not be mutually exclusive nor use all the data from the parent flow As we move to lower levels we become more precise about the data flows A data flow join shows where components are merged to describe a more comprehensive flow

Alternative Data Flows Where a process can produce different data given different conditions We show both data flows and use the process description to explain why they are alternatives, e.g. –Process credit card rejections –Process credit card approvals Tip -- alternative data flows often accompany processes with IF statements

Tips for Level 1 and Below Sources for inputs and outputs listed at higher level List source and destination of data flows to processes and stores within each DFD Depth of DFD depends on overall system complexity –Two processes generally don’t need lower level (move to higher level) –More than seven processes become overly complex and difficult to read

Step 7. Validating the DFD Syntax errors –Assure correct DFD structure Semantics errors –Assure accuracy of DFD relative to actual/desired business processes User walkthroughs Role-play processes Examine lowest level DFDs Examine names carefully

Summary The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes and data flows. Use cases record the input, transformation, and output of business processes. Eliciting scenario descriptions and modeling business processes are critically important skills for the systems analyst to master.

Which is best? Customer Change address 1 Address change info D1 Customer Information Address change info Customer Change address 1 Address change info D1 Customer Information Address change info Customer Change address 1 Address info D1 Customer Information Address change info Scenario: A customer notifies a magazine publisher of a change of address. “For clarity, it is better practice to draw two separate data flows” (p. 149)

Topic Duration Grading System Exercise60 minutes *** Break15 minutes DFD60 minutes ATB Homework45 minutes Assignment 4 and Quiz 3 Intro10 minutes Today’s agenda

ATB Homework

ATB ERD

ATB DFD Context

Topic Duration Grading System Exercise60 minutes *** Break15 minutes DFD60 minutes ATB Homework45 minutes Assignment 4 and Quiz 3 Intro10 minutes Today’s agenda