IS 341
Business Systems Analysis
Chapter 6 - Notes
Structuring System Requirements: Process Modeling
*****Introduction
to Modeling Not in Text
A.
Models a representation of some aspect of reality; not reality itself,
but a representation (an approximation) of some part of reality that we want to
study; the more closely the model approaches reality, the greater the
complexity (usually).
B.
Why use models? because Reality is Too Complex for the mind to
understand as a whole without help (reducing the amount of available
information to something we can handle).
C.
Basic Model Types
1. Logical shows What a system does (not how
it works) independently of any application or technological implementation;
also called an Essential model or Business model
a. Types of Logical Models
1. Graphical easier to understand than the
underlying mathematical/numerical concepts
2. Pictorial a picture is worth a thousand
words
3. Narrative lots of words, descriptions
4. Mathematical most difficult to understand;
know your audience!
b. Benefits of Logical models
1. Logical models Remove Biases resulting from
current implementations and encourage creativity by overcoming the weve
always done it that way syndrome.
2. Logical models reduce risk of missing
business requirements while preoccupied with technical details; *****separating
What from How allows better Analysis, Completeness, Accuracy, Consistency.
3. Logical models allow communication with
end-users in non-technical or less technical language; we do not lose them in
the jargon.
2. Physical shows WHAT a system does and HOW the
system is physically implemented.
Implementation dependent because they reflect technological choices and
limitations; also called Implementation model or Technical model.
*****Structured
Tools Constraints through Limited Symbols, Limited Vocabulary; two most
popular are Data Flow Diagrams (DFDs - Process models, chapter 6) and Entity
Relationship Diagrams (ERDs Data models, chapter 7);
*****NOTE: VISIO and Flow-Charts are NOT structured
tools!
The
Second sub-phase of the Analysis Phase is Requirements Structuring, which is
itself broken down into two parts:
Process Modeling (chap.6) and Conceptual Data Modeling (chap. 7). Process flows, decision logic, and data model
descriptions of a system must be consistent and complete because each describes
different but complementary views of the same system. This chapter deals with Process Modeling.
I. Process Modeling graphically representing
the processes that capture, manipulate, store, and distribute data between a
system and its environment, and among components within a system.
Data Flow Diagram (DFD) a
graphic that illustrates the movement of data between external entities and the
processes and data stores within a system.
A.
Modeling a Systems processes Processes are the Transformations
of the data into information that occur in a system
B.
Deliverables and Outcomes a set of coherent, integrated data flow
diagrams
1. Context Level DFD shows the scope of the
system and its connection to elements in the environment
2. Leveled DFDs of Current systems showing both
people and technologies used currently (Physical model - both What and How of
current system)
3. Technology Independent Leveled DFDs
showing Logical/conceptual model of new system
*****NOTE
students should read this section of the text about firms that do/do not use
DFDs!!***
II. Data Flow Diagramming Mechanics
A.
Definitions and Symbols
1. Data Flow (arrow) movement f data between
external entities, processes, and data stores
2. Data Store (open-ended box) data at rest
3. Process (box with rounded corners, or circle)
work or action performed on data so that it is transformed/stored/distributed
4. External Entity/Terminator or Source/Sink
(box) entity outside the system which delivers or receives data/information
to/from the system; origin or destination of data
B.
Developing DFDs: An Example
C.
Data Flow Diagramming Rules (*****READ Table 6-2, p.160, and
Figure 6-6, p.161 IMPORTANT!*****)
*****NOTE
- All names must be unique (except diverging and converging data flows)
1. Data Flows
a. Names should be Nouns/Noun-Phrases (nouns and
adjectives &/or adverbs)
b. Data coming out of a process must be
different from the data going in (a change to the data must occur in a Process)
c. Converging and Diverging Data Flows
2. Processes
a. Names should be Verb-Phrases (verb-noun do
something to something)
b.
Miracles/Immaculate Conceptions
c. Black Holes
d. Gray/Grey Holes (spelling depends on the
author, both are acceptable in the literature)
3. Data Stores
a. Names should be
Noun-Phrase name of the data/file being stored
b. Data cannot move directly between data
stores, must go thru a process
c. Data cannot move directly between a
terminator and a data stores, must go thru a process
4. Terminators -
a. Names should be Noun-Phrases the name of
the source/sink
b. Data must go to/from a Process, not a data
store
c. Data cannot be moved directly between
terminators this is outside the control of the system
5. Inputs to a system must be different from the
outputs the processes must have a purpose!
D.
Decomposition of DFDs
1. Functional Decomposition breaking down the
function of a system into finer and finer detail until the level of
Elementary/Primary Processes is reached
2. Elementary/Primary Processes the lowest
level of detail in breaking down a system where a process does ONLY ONE (1)
SPECIFIC ACTION
E.
Balancing DFDs idea of conservation of inputs and outputs; no new
inputs/outputs may show at a lower level DFD than occur at a higher level
III. Using Data Flow Diagramming in the Analysis Process
you must consider how to use DFDs as a tool for analysis; also DFDs must be:
1. Mechanically correct
2. Complete
3. Consistent across all levels
A.
Guidelines for Drawing DFDs
1. Completeness the extent to which all
necessary components have been included and fully described
2. Consistency the extent to which information
contained in one level of a set of nested DFDs is included on other levels
3. Timing a DFD has no way to indicate timing
of processes, flows, or stores (when they happen or how often)
4. Iterative Development the first attempt at
drawing a DFD is rarely the correct description; plan on revising the diagrams
a number of times, getting closer (better) as you progress in the development
of the DFDs; Iterative DFD development recognizes that Requirements
Determination and Requirements Structuring are NOT Sequential, but interacting
sub-phases of Analysis
5. Primitive DFDs (the lowest level of
decomposition fro a DFD) When to stop decomposing processes? When you have reached the lowest (most
Primitive) level; e.g.,
a. when a process has become an Elementary
Process (only a single calculation or operation)
b. when a data flow does not need to be split
further
c. when you and other analysts agree that the
DFD is primitive enough
d. (others, see p. 170)
B.
Using DFDs as Analysis Tools DFDs can be used for both Logical and
Physical models; if the DFDs correctly
depict the system, you can see redundancies, discrepancies, inefficiencies, and
errors in the system by examining the DFDs
Gap Analysis the process of
discovering discrepancies between two or more sets of DFDs, or within a single
DFD
C.
Using DFDs in Business Process Reengineering since a Logical DFD show
What, not How, it can be used to spur creativity in coming up with a totally
new way of accomplishing the same goal (What), but in a different way (How)
IV. Logic Modeling
A.
Modeling with Structured English a modified form of English used to
specify the logic of information system processes; no set standards for S.E.,
but usually uses action verbs and noun phrases, but no adjectives or adverbs
B.
Modeling with Decision Tables a matrix representation of the logic of
a decision; specifies the possible conditions and the resulting actions
1. Condition Stubs part of the decision table
that lists conditions relevant to the decision
2. Action Stubs - part of the decision table
that lists the actions that result from a set of conditions
3. Rules - part of the decision table that
specifies which actions are to be followed for a given set of conditions
4. Indifferent Condition a condition whose
value does not affect which actions are taken for two or more rules
V. Pine Valley Furniture WebStore: Process Modeling
Process Modeling for Pine Valley
Furnitures WebStore