BDIT 124/DCIS 104

Systems Analysis and Design

Structuring System Requirements:Process Modeling

Key Definitions

• Process model – A formal way of representing how a business

operates– Illustrates the activities that are performed and

how data moves among them• Data flow diagramming

– A popular technique for creating process models

Key Definitions

• Logical process models describe processes without suggesting how they are conducted

• Physical process models include process implementation information

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

– They allow us to model how data flow through an information system, the relationships among the data flows, and how data come to be stored at specific locations.

Process Modeling

• Modeling a system’s process– Utilize information gathered during

requirements determination– Structure of the data is also modeled in addition

to the processes• Deliverables and Outcomes

– Set of coherent, interrelated data flow diagrams

Process Modeling

• Deliverables and outcomes (continued)– Context data flow diagram (DFD)

• Show the scope of system, indicating which elements are inside and outside the system.

– DFDs of current system• Enables analysts to understand current system.• Specify which people and technologies are used in which

processes to move and transform data, accepting inputs and producing outputs.

– DFDs of new logical system• Technology independent or logical• Show data flows, structure and functional requirements of new

system

Process Modeling

• Deliverables and outcomes (continued)– Project dictionary and CASE repository

• Includes a thorough description of each DFD component– Requirements determination and structuring are often

parallel steps, thus data flow diagrams evolve from more general to the more detailed as current and replacement systems are better understood.

• Data flow diagramming mechanics– Four symbols are used

• See Figure in next slide– Developed by Gane and Sarson– Mainly referred to as DFD

Reading a DFD

DFD Elements

• Process– An activity or function performed for a specific

business reason– Manual or computerized

• Data flow– A single piece of data or a logical collection of

data– Always starts or ends at a process

DFD Elements

• Data Store– A collection of data that is stored in some way– Data flowing out is retrieved from the data

store– Data flowing in updates or is added to the data

store

DFD Elements

• External entity/sink– A person, organization, or system that is external to the

system but interacts with it and Depicts the origin and/or destination of the data

– Because they are external, many characteristics are not of interest to us:

• Interaction that occur between sources and sinks• What a source or sink does with the information and how it

operates (source/sink is a black box)• How to control or redesign a source/sink• How to provide sources and sinks direct access to stored data,

because, as external agents, they cannot directly access or manipulate data stored within the system

DFD Elements

• External entity/sink– Many times, we get confused about whether a

person or activity is a source/sink or a process within a system.

– This dilemma occurs most often when the data flows in a system cross office or departmental boundaries. Example of such confusion is shown in the next slide

Naming and Drawing DFD Elements

Process

Data flow

Data store

Externalentity

Depicting Business Processes with DFDs

• Business processes are too complex to be shown on a single DFD

• Decomposition is the process of representing the system in a hierarchy of DFD diagrams– Child diagrams show a portion of the parent

diagram in greater detail

Key Definitions

• Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD.

• Context Diagram– A 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 system

• Level-O Diagram– A data flow diagrams (DFD) that represents a system’s major

processes, data flows and data stores at a higher level

Context Diagram Example

Relationship Among DFD levels

Context diagram

Level 0 diagram

Level 1 diagram

Level 2 diagram

Context Diagram

• First DFD in every business process• Shows the context into which the business process

fits• Shows the overall business process as just one

process (process 0)• Shows all the external entities that receive

information from or contribute information to the system

Level 0 Diagram

• Shows all the major processes that comprise the overall system – the internal components of process 0

• Shows how the major processes are interrelated by data flows

• Shows external entities and the major processes with which they interact

• Adds data stores

Level 1 Diagrams

• Generally, one level 1 diagram is created for every major process on the level 0 diagram

• Shows all the internal processes that comprise a single process on the level 0 diagram

• Shows how information moves from and to each of these processes

• If a parent process is decomposed into, for example, three child processes, these three child processes wholly and completely make up the parent process

Level 2 Diagrams

• Shows all processes that comprise a single process on the level 1 diagram

• Shows how information moves from and to each of these processes

• Level 2 diagrams may not be needed for all level 1 processes

• Correctly numbering each process helps the user understand where the process fits into the overall system

Data Flow Splits and Joins/merge

• 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

Data Flow Splits and Joins/Merge

If the outgoing flows of a splitting node or the incoming flows of a merging node are unnamed then this means that identical copies are split or merged respectively .

Split Merged

Alternative Data Flows

• Where a process can produce different data flows given different conditions

• We show both data flows and use the process description to explain why they are alternatives

• Tip -- alternative data flows often accompany processes with IF statements

Assignment 1

• At this point in the process it is easy to lose track of the “big picture”.

• Describe the difference between data flows, data stores, and processes.

• Describe in your own words the relationship between the DFD and the ultimate new application being developed.

Logic Modeling/ Process Descriptions

• Data flow diagrams do not show the logic inside the processes

• Logic modeling involves representing internal structure and functionality of processes depicted on a DFD

• If the logic underlying the process is quite complex, more detail may be needed in the form of

• The following methods – Structured English– Decision Tables– Decision Trees

Structured EnglishCommon Statements Example

Action Statement Profits = Revenues - Expenses Generate Inventory Report Add Product record to Product Data Store

If Statement IF Customer Not in Customer Data Store THEN Add Customer record to Customer Data Store ELSE Add Current Sale to Customer’s Total Sales Update Customer record in Customer Data Store

For Statement FOR all Customers in Customer Data Store, do Generate a new line in the Customer Report Add Customer’s Total Sales to Report Total

Case Statement CASEIf Income < 10,000: Marginal tax rate = 10%If Income < 20,000: Marginal tax rate = 20%If Income < 30,000: Marginal tax rate = 31%If Income < 40,000: Marginal tax rate = 35%ELSE Marginal tax rate = 38%

ENDCASE

Decision Trees

• Graphical way of depicting if-then-else logic

Modeling Logic with Decision Tables

• Represent very complex processes with multiple decision rules

• A matrix representation of the logic of a decision

• Specifies the possible conditions and the resulting actions

• Best used for complicated decision logic

Modeling Logic with Decision Tables

• Consists of three parts– Condition stubs

• Lists condition relevant to decision– Action stubs

• Actions that result for a given set of conditions– Rules

• Specify which actions are to be followed for a given set of conditions

Modeling Logic with Decision Tables

• Indifferent Condition– Condition whose value does not affect which action is

taken for two or more rules• Standard procedure for creating decision tables

– Name the condition and values each condition can assume

– Name all possible actions that can occur– List all rules– Define the actions for each rule (See Figure 5-18)– Simplify the table (See Figure 5-19)

CREATING DATA FLOW DIAGRAMS

Integrating Scenario Descriptions

• DFDs start with the use cases and requirements definition

• Generally, the DFDs integrate the use cases• Names of use cases become processes• Inputs and outputs become data flows• “Small” data inputs and outputs are combined into

a single flow

Steps in Building DFDs

• Build the context diagram• Create DFD fragments for each use case• Organize DFD fragments into level 0 diagram• Decompose level 0 processes into level 1

diagrams as needed; decompose level 1 processes into level 2 diagrams as needed; etc.

• Validate DFDs with user to ensure completeness and correctness

Build the Context Diagram

• Draw one process representing the entire system (process 0)

• Find all inputs and outputs listed at the top of the use cases that come from or go to external entities; draw as data flows

• Draw in external entities as the source or destination of the data flows

A Context Diagram Example

Creating DFD Fragments

• Each use case is converted into one DFD fragment

• Number the process the same as the use case number

• Change process name into verb phrase• Design the processes from the viewpoint of

the organization running the system

Creating DFD Fragments

• Add data flows to show use to data stores as sources and destinations of data

• Layouts typically place– processes in the center– inputs from the left– outputs to the right– stores beneath the processes

A DFD Fragment Example

Creating the Level 0 Diagram

• Combine the set of DFD fragments into one diagram

• Generally move from top to bottom, left to right• Minimize crossed lines• Iterate as needed

– DFDs are often drawn many times before being finished, even with very experienced systems analysts

A Level 0 DFD Example

Creating Level 1 Diagrams (and Below)

• Each use case is turned into its own DFD• Take the steps listed on the use case and depict

each as a process on the level 1 DFD• Inputs and outputs listed on use case become data

flows on DFD• Include sources and destinations of data flows to

processes and stores within the DFD• May also include external entities for clarity

Creating Level 1 Diagrams (and Below)

• Input data flows shown on a parent DFD are often unbundled on the child diagram using splits

• Output data flows shown on a child DFD are often bundled using joins and shown as a larger data flow on the parent diagram

• When to stop decomposing DFDs?– Ideally, a DFD has at least 3 processes and no more

than 7-9.

Validating the DFD

• Syntax errors – diagram follows the rules– Assure correct DFD structure

For each DFD:Check each process for:

A unique name: action verb phrase; number; descriptionAt least one input data flowAt least one output data flowOutput data flow names usually different than input data flow namesBetween 3 and 7 processes per DFD

Validating the DFDFor each DFD:Check each data flow for:A unique name: noun; descriptionConnects to at least one processShown in only one direction (no two-headed arrows)A minimum number of crossed lines

Check each data store for:A unique name: noun; descriptionAt least one input data flowAt least one output data flow

Check each external entity for:A unique name: noun; descriptionAt least one input or output data flow

Validating the DFDAcross DFDs:Context Diagram:Every set of DFDs must have one Context DiagramViewpoint:

There is a consistent viewpoint for the entire set of DFDsDecomposition:

Every process is wholly and complete described by the processes onits children DFDsBalance:

Every data flow, data store, and external entity on a higher level DFD is shown on the lower level DFD that decomposes itNo data stores or data flows appear on lower-lever DFDs that do not appear on their parent DFD

Validating the DFD

• Semantics errors – diagram conveys correct meaning– Assure accuracy of DFD relative to actual/desired

business processes• To verify correct representation, use

– User walkthroughs– Role-play processes

• Examine lowest level DFDs to ensure consistent decomposition

• Examine names carefully to ensure consistent use of terms

Data Flow Diagramming Rules

• Basic rules that apply to all DFDs– Inputs to a process are always different from

the outputs of that process: The reason is that processes, to have a purpose, typically transform inputs into outputs, rather than simply passing the data through without some manipulation.

– Objects always have a unique name• In order to keep the diagram uncluttered, you can

repeat data stores and data flows on a diagram

Data Flow Diagramming Rules

• ProcessA. No process can have only

outputs (a miracle). If an object has only outputs, then it must be a source.

B. No process can have only inputs (black hole). If an object has only inputs, then it must be a sink.

C. A process has a verb phrase label.

• Data StoreD. Data cannot be moved

from one store to another. Data must be moved by a process.

E. Data cannot move from an outside source to a data store. It must be received by a process.

F. Data cannot move directly from a data store to a data sink.

G. Data store has a noun phrase label

Data Flow Diagramming Rules

• Source/SinkH. Data cannot move

directly from a source to a sink. They must be moved by a process if the data are of concern to our system.

I. A source/sink has a noun phrase label

• Data FlowJ. A data flow has only

one direction of flow between symbols

K. A fork means that exactly the same data go from a common location to two or more processes, data stores or sources/sinks

Data Flow Diagramming Rules

• Data Flow (Continued)L. A join means that exactly the same data come 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 (delete or change)O. A data flow from a data store means retrieve or useP. A data flow has a noun phrase label

Summary

• The Data Flow Diagram (DFD) is an essential tool for creating formal descriptions of business processes.

• Use cases record the input, transformation, and output of business processes and are the basis for process models.

• Eliciting use cases and modeling business processes are critically important skills for the systems analyst to master.