Business Systems Analysis
Chapter 5 - Notes
Structuring System Requirements: Process Modeling
*****Introduction to Modeling
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
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 “we’ve 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 5) and Entity Relationship Diagrams (ERDs – Data models, chapter 6); VISIO and Flow-Charts are NOT structured tools!
The Second section of the Analysis Phase is Requirements Structuring, which is itself broken down into two parts: Process Modeling and Conceptual Data Modeling. 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 System’s 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 – have student 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 (see Table 5-2, p.162 – IMPORTANT!)
*****NOTE - All names must be unique
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
a. Names should be Verb-Phrases (verb-noun – do something to something)
b. Miracles/Immaculate Conceptions
c. Black Holes
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
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. Electronic Commerce Application: Process Modeling
A. Process Modeling for Pine Valley Furniture’s WebStore
B. Logic Modeling for Pine Valley Furniture’s WebStore