Model – representation of reality
Logical and Physical
Process Modelling – technique for organising & documenting the structure and flow of data through a system.
Data Flow Diagram (DFD) – tool that depicts the flow of data through a system and the work or processing performed by that system.
A model is a representation of reality. Just as a picture is worth a thousand words, most models are pictorial representations of reality
Logical models show what a system is or does. They are implementation independent; that is, they depict the system independent of any technical implementation.
Physical models show not only what a system is or does, but also how the system is (to be) physically and technically implemented. They are implementation dependent because they reflect technology choices.
Logical models remove biases that are the result of the way
the system is currently implemented, or the way that any one person thinks the
system might be implemented.
Logical models reduce the risk of missing business requirements because we are too preoccupied with technical results.
Logical models allow us to communicate with end-users in nontechnical or less technical languages.
Strategic systems planning
Enterprise process models illustrate important business functions.
Business process redesign
“As is” process models facilitate critical analysis.
“To be” process models facilitate improvement.
Systems analysis (primary focus of this course)
Model the existing system including its limitations
Model the target system’s logical requirements (meaning processes and data flows needed regardless of how the system will be implemented)
Model candidate technical solutions (physical DFDs only)
Model the target technical solution (physical DFDs only)
Processes on DFDs can operate in parallel (at-the-same-time)
Processes on flowcharts execute one at a time
DFDs show the flow of data through a system
Flowcharts show the flow of control (sequence and transfer of control)
Processes on one DFD can have dramatically different timing
Processes on flowcharts are part of a single program with consistent timing
Process modelling is a technique for organizing and documenting the structure and flow of data through a system’s processes, and/or the logic, policies, and procedures to be implemented by a system’s processes.
A data flow diagram (DFD) is a tool (and type of process
model) that depicts the flow of data through a system and the work or processing
performed by that system.
DFDs have become a popular tool for business process redesign.
Systems thinking is the application of formal
systems theory and concepts to systems problem solving.
DFDs are a tool that supports systems thinking.
Problems typically solved in university are much smaller and simpler than those encountered in the real world.
Systems thinking is a technique that will pay off as problem size and complexity grow.
A process is work performed on, or in response to, incoming data flows or conditions.
A System is a Process!
Decomposition is the act of breaking a system into its component subsystems, processes, and sub-processes. Each level of abstraction reveals more or less detail.
A decomposition diagram or hierarchy chart shows the top-down, functional decomposition of a system.
A function is set of related and ongoing activities of a
An event (or transaction) is a logical unit of work that must be completed as a whole (as part of a function).
An elementary process (or primitive process) is a discrete, detailed activity or task required to respond to an event. Usually, several such tasks must be completed to respond to an event.
Whitten & Bentley (2006)
A data flow represents an input of data to a
process, or the output of data from a process.
A data flow may also be used to represent the creation, reading, deletion, or updating of data in a file or database (called a data store).
A composite data flow is a data flow that consists of other data flows.
A control flow represents a condition or non-data event that triggers a process.
Used sparingly on DFDs.
Basically, we try to summarise the data flows.
Whitten & Bentley (2006)
An external agent defines a person,
organization unit, or other organization that lies outside of the scope of the
project but that interacts with the system being studied.
External agents define the “boundary” or scope of a system being modelled.
As scope changes, external agents can become processes, and vice versa.
Almost always one of the following:
Office, department, division inside the business but outside the system scope.
An external organization or agency.
Another business or another information system.
One of your system’s end-users or managers
A data store is an inventory of data.
Frequently implemented as a file or database.
A data store is “data at rest” compared to a data flow that is “data in motion.”
Almost always one of the following:
Persons (or groups of persons)
Events (about which data is captured)
Concepts (about which data is important)
Data stores depicted on a DFD store all instances of data entities (depicted on an ERD)
Draw a context DFD to establish initial
Draw a functional decomposition diagram to partition the system into subsystems.
Create an event-response or use-case list for the system to define events for which the system must have a response.
Draw an event DFD (or event handler) for each event.
Merge event DFDs into a system diagram (or, for larger systems, subsystem diagrams).
Draw detailed, primitive DFDs for the more complex event handlers.
Document data flows and processes in the data dictionary.
THE ABOVE METHODOLOGY, BASED ON EVENT PARTITIONING, IS MORE COMMONLY PRACTICED.
Many of us do not write well, and we also tend not to question our writing abilities.
Many of us are too educated! It’s often difficult for a highly educated person to communicate with an audience that may not have had the same educational opportunities. For example, the average college graduate (including most analysts) has a working vocabulary of 10,000 to 20,000 words; on the other hand, the average non-college graduate has a working vocabulary of around 5,000 words.
Some of us write everything like it was a program. If business procedures required such precision, we’d write everything in a programming language.
Too often, we allow the jargon and acronyms of computing to dominate our language.
English statements frequently have an excessive or confusing scope. How would you carry out this procedure: “If customers walk in the door and they do not want to withdraw money from their account or deposit money to their account or make a loan payment, send them to the trust department.” Does this mean that the only time you should not send the customer to the trust department is when he or she wishes to do all three of the transactions? Or does it mean that if a customer does not wish to perform at least one of the three transactions, that customer should not be sent to the trust department?
We overuse compound sentences Consider the
following procedure: “Remove the screws that hold the outlet cover to the wall.
Remove the outlet cover. Disconnect each wire from the plug, but first make sure
the power to the outlet has been turned off.” An unwary person might try to
disconnect the wires prior to turning off the power!
Too many words have multiple definitions.
Too many statements use imprecise adjectives.
For example, an loan officer asks a teacher to certify that a student is in good
academic standing. What is good?
Conditional instructions can be imprecise. For example, if we state that “all applicants under the age of 19 must secure parental permission,” do we mean less than 19, or less than or equal to 19?
Compound conditions tend to show up in natural English. For example, if credit approval is a function of several conditions: credit rating, credit ceiling, annual dollar sales for the customer in question, then different combinations of these factors can result in different decisions. As the number of conditions and possible combinations increases, the procedure becomes more and more tedious and difficult to write.
Structured English is a language and syntax, based on the relative strengths of structured programming and natural English, for specifying the underlying logic of elementary processes on DFDs.
Sample of Structured English
A policy is a set of rules that governs some
process of the business.
A decision table is a tabular form of presentation that specifies a set of conditions and their corresponding actions (as required to implement a policy).
< Return to the Main Page :: BIS Website :: UCC Website