Information Systems System Analysis 421 Class Seven

1
Information Systems System Analysis 421Class
Seven
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

8.2
3
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
  Oracles process modeling tool and with
  functional hierarchy diagrams
• Discuss process modeling for Internet
  applications

8.3
4
Data Modeling
5
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

6
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

7
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.

8
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 systems process
• Utilize information gathered during requirements
  determination
• Structure of the data is also modeled in addition
  to the processes

8.8
9
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
10
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 gt State gt City

11
Data Flow Diagrams

• Tool that depicts the flow of data through a
  system and the work or processing performed by
  that system
• Graphical tool used to describe and analyze the
  movement of data through a system manual or
  automated
• Central tool in which other components are
  developed
• A data flow diagram (DFD) is a tool that depicts
  the flow of data through a system and the work or
  processing performed by that system. Synonyms
  include bubble chart, transformation graph, and
  process model

12
DFD Symbols
13
DFD Symbols

• Named vector or arrow
• Called a data flow
• Portrays a data path
• Bubble
• Called a process
• Portrays transformation of data
• Narrow open rectangle
• Called a data store
• Portrays a file or data base
• Box
• Called a source or sink
• Portrays an internal or external agent
• Used to define a systems boundaries

14
DFD Symbols

• Data flow - data move in a specific direction
• Processes - people, procedures or device that
  transforms data - work to be done
• Source or destination - external source or
  destination of data which may be people, program,
  organization or other entities - The squares
  represent external agents the boundary of the
  system.
• Data Store - where data is house

Customer
Good Sold File
15
DFD Symbols
1
Accepted Orders
Orders
Customer
Verify Credit
2
Ship Order
Data Flow
Credit History
External Entity
Process
Customer File
Data Store
16
DFD Symbols
17
Data Flow

• A data flow is data in motion.
• The flow of data between a system and its
  environment, or between two processes inside a
  system an relationship between a system and its
  environment, or between two processes is
  communication.
• A data flow represents an input of data to a
  process, or the output of data (or information)
  from a process. A data flow is also used to
  represent the creation, deletion, or update of
  data in a file or database (called a data store
  on the DFD).
• A data flow is depicted as a solid-line with
  arrow.

18
Data Flow
19
Data Flow

• No data flow should ever go completely unnamed.
• Data flow names should describe the data flow
  without describing how the flow is or could be
  implemented.
• All data flows must begin or end at a process,
  because data flows are the inputs and outputs of
  a process.
• Naming Convention - Should be descriptive nouns
  and noun phrases that are singular, as opposed to
  plural.
• Should be unique.
• Use adjectives and adverbs to help to describe
  how processing has changed a data flow.

20
Data Flow
21
Data Flow Packet Concept

• Data is seen as a package of information

22
Data Store

• Data Store
• Depicts data at rest
• May represent data in
• File folder
• Computer-based file
• Notebook
• The name of the store as well as the number are
  recorded in between lines

8.22
23
Data Stores

• Most information systems capture data for later
  use.
• The data is kept in a data store.
• A data store is an inventory of data.
  Synonyms include file and database (although
  those terms are too implementation-oriented for
  essential process modeling).
• A data store is represented by the open-end box.
• If data flows are data in motion, think of data
  stores as data at rest.
• Data stores should describe things about
  which the business wants to store data.
• It is permissible to duplicate data stores on a
  DFD to avoid crossing data flow lines.

24
Data Stores

• Data cannot be moved from one data store to
  another data stored it must be moved by a process
• Data cannot be moved from an outside source to a
  data store it must be moved by a process
• Data Stores should have noun phrase labels
• Data Stores can be labeled
• Data flow to a data store means new/update
• Data flow from a data store means retrieve

Good Sold File
A
25
DFD Rules - Data Stores
Whats valid !
Good Sold File
Management Reports
26
DFD Rules - Data Stores
Whats valid !
Sold data
Sold data
Inventory Data
Student Data
Good Sold File
Management Reports
27
Process

• Process names should be descriptive.
• Processes should have a single Action Verb and a
  Singular Object.
• Process numbers strictly used for identification
• All Processes are connected to something.
• All Processes have both Inputs and Outputs.
• No Process has only outputs or only inputs.
• Processes may connect to anything other
  processes, data stores or entities.
• Each Process has a unique name and number.
• A Process number is used only once in a diagram
  set.

28
Process

• Black Holes and Miracles

1
1
Process 1
Process 1
Entity
Entity
y
x
x
y
Data Store
Data Store
29
Process Example
1.0
1.0
Process Customer Food Order
Process Customer Food Order
Which ones are correct and incorrect?
30
External Entities

• Source/Sink
• Depicts the origin and/or destination of the data
• Sometimes referred to as an external entity
• Drawn as a square symbol
• Name states what the external agent is
• Because they are external, many characteristics
  are not of interest to us

8.30
31
External Entities

• All information systems respond to events and
  conditions in the environment.
• The environment of an information system
  includes external entities that form the
  boundary of the system, and define places where
  the system interfaces with its environment.
• A external entity defines an a person,
  organization unit, other system, or other
  organization that lies outside of the scope of
  the project, but which interacts with the system
  being studied.
• External agents provide the net inputs into a
  system, and receive net outputs from a system.
• Common synonyms include external agents

32
External Entities

• The term external means external to the system
  being analyzed or designed.
• An external agent is represented by a square on
  the data flow diagram.
• External agents on a logical data flow diagram
  may include people, business units, other
  internal systems with which your system must
  interact, and external organizations.
• External agents should be named with descriptive,
  singular nouns.
• As a general rule, external agents should be
  located on the perimeters of the page, consistent
  with their definition as a system boundary.

33
Data Flow Diagramming Definitions

• 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 diagram (DFD) that represents a
  systems major processes, data flows and data
  stores at a high level of detail

8.33
34
Fast Food Restaurant

• Context diagram an overview of an organization
  system that shows
• the system boundaries
• sources that interact with the system
• major information flow between the entities

35
Fast Food Restaurant

• The Context Diagram
• The context diagram contains one and only one
  process.
• External entities are drawn around the perimeter.
• Data flows define the interactions of your system
  with the boundaries and with the external data
  stores.
• Refer as Level Zero
• Lets draw a context diagram
• What does a restaurant do - think McDonalds or
  Hoosier
• What are the boundaries
• Who does it interact with

36
Developing DFDs An Example

• Hoosier Burgers automated food ordering system
• Context Diagram (Figure 8-4) contains no data
  stores
• Next step is to expand the context diagram to
  show the breakdown of processes (Figure 8-5)

8.36
37
Figure 8-4Context diagram of Hoosier Burgers
food ordering system
8.37
38
Figure 8-5Level-0 DFD of Hoosier Burgers food
ordering system
8.38
39
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
• A fork means that exactly the same data goes from
  a common location to two or more processes, data
  stores or sources/sinks

8.39
40
Data Flow Diagramming Rules

• Data Flow (Continued)
• 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
• A data flow cannot go directly back to the same
  process it leaves
• A data flow to a data store means update
• A data flow from a data store means retrieve or
  use
• A data flow has a noun phrase label

8.40
41
Data Flow Example
Incorrect Correct
42
DFD Rules -- Data Flow
Incorrect Correct
43
(No Transcript)
44
What are the rules violations?
Dataflow 2
Entity A
Dataflow 5
Dataflow 3
Dataflow 6
Dataflow 7
Dataflow 1
Dataflow 4
Entity B
Dataflow 2
Dataflow 8
45
What are the rules violations?
Dataflow 2
Entity A
Dataflow 5
Dataflow 3
Dataflow 6
Dataflow 7
Dataflow 1
Dataflow 4
Entity B
Dataflow 2
Dataflow 8
Thats All
46
Decomposition of DFDs

• Functional decomposition
• Act of going from one single system to many
  component processes
• Repetitive procedure
• Lowest level is called a primitive DFD
• Level-N Diagrams
• A DFD that is the result of n nested
  decompositions of a series of subprocesses from a
  process on a level-0 diagram

8.46
47
Relationship Among DFD levels
48
Level 0 Diagram

• Shows all the processes that comprise the overall
  system
• Shows how information moves from and to each
  process
• Adds data stores

49
Level 1 Diagrams

• Shows all the processes that comprise a single
  process on the level 0 diagram
• Shows how information moves from and to each of
  these processes
• Shows in more detail the content of higher level
  process
• Level 1 diagrams may not be needed for all level
  0 processes

50
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
• 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.

51
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.51
52
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.52
53
Figure 8-4Context diagram of Hoosier Burgers
food ordering system
8.53
54
Figure 8-5Level-0 DFD of Hoosier Burgers food
ordering system
8.54
55
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.55
56
Figure 8-10An unbalanced set of data flow
diagrams(a) Context diagram(b) Level-0 diagram
8.56
57
DFD Balancing and Leveling

• When Zooming In, Do Not forget the Parent!
• Parent Process
• Child Diagram

P1.1
P1.2
Is this Child Diagram Balanced?
P1
P1.3
58
DFD Exercise Problem Level 0
DF6
E1
E2
DF2
P1
P2
DF1
DF4
DF3
DF5
P3
DS1
DF3
59
DFD Exercise Problem Level 1
DF6
E2
P1.1
P1.2
DF1
P1.4
DF7
DF9
DF2
DF8
P1.3
60
DFD Exercise Problem Level 2
E2
P1.4.2
P1.4.3
DF11
DF12
DF2
DF10
P1.4.1
DF8
DF9
61
Four Different Types of DFDS

• Current Physical
• Process label includes an identification of the
  technology (people or systems) used to process
  the data
• Data flows and data stores are labeled with the
  actual name of the physical media on which data
  flow or in which data are stored

8.61
62
Four Different Types of DFDS

• Current Logical
• Physical aspects of system are removed as much as
  possible
• Current system is reduced to data and processes
  that transform them
• New Logical
• Includes additional functions
• Obsolete functions are removed
• Inefficient data flows are reorganized
• New Physical
• Represents the physical implementation of the new
  system

8.62
63
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
• Timing
• Time is not represented well on DFDs
• Best to draw DFDs as if the system has never
  started and will never stop.

8.63
64
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
• When the system user does not care to see any
  more detail

8.64
65
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
66
Oracles 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
67
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
68
Summary

• DFDs for Analysis
• DFDs for Business Process Reengineering (BPR)
• Oracles Process Modeler
• Functional Hierarchy Diagrams

8.68
69
Process Decomposition

• What do you do 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

70
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.

71
Process Decomposition
72
Process Decomposition

• How do 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

73
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 do 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

74
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

75
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).

76
DFD Exercise Problem
Draw both a Context and Level 1 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.
77
DFD Exercise Problem
78
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.