9
Process Modeling
Overview
Chapter 9 is a “technique” chapter that teaches the still important skill of process modeling. The focus is on drawing logical data flow diagrams. After teaching system and process modeling concepts to introduce DFD constructs, the
chapter presents a contemporary approach to structured analysis based upon
event partitioning.
Chapter to Course Sequencing
Students are encouraged to read Chapter 5 to provide perspective for logical
system modeling. Adopters wishing to focus on object-oriented analysis techniques may want to skip this chapter in favor of Chapter 10. However, DFDs
will not go away overnight. This is especially true given that DFDs have enjoyed
something of a renaissance in new forms directed to business process redesign.
For the time being, we recommend that this chapter be at least surveyed prior
to introducing our object-oriented analysis coverage.
Given non-object-oriented analysis, there has always been disagreement concerning the sequencing of the modeling chapters. Classical structured analysis
always sequenced process modeling before data modeling. Information engineering and modern structured analysis reversed that trend—data models were
drawn first and their existence drove process modeling. Although we prefer the
latter more contemporary approach, the chapters were designed to be covered
in either sequence at the instructor’s preference.
What’s Different Here and Why?
This chapter did not necessitate many content changes from the sixth edition, but significant changes were made in the order in which that content is
presented. The following changes have been made to this chapter in the seventh edition:
1.
As with all chapters, we have streamlined the SoundStage episode into a
quick narrative introduction to the concepts presented the chapter.
2.
Several topics were rearranged in the chapter for better flow. This was
based on actual field experience in teaching the concepts to students.
•
We begin with an introduction to process modeling.
9-2
Chapter Nine
•
We next discuss system concepts for processing modeling, which
quickly introduces the external agent, data stores, and processes.
Processes are saved to last so that we can move into process concepts,
such as decomposition, functions, events, etc. without students forgetting the overall relationship of processes to agents and data stores.
•
Data flow concepts are discussed next, which finishes laying the
groundwork for drawing DFDs.
•
We next discuss the process of logical process modeling, including
strategic systems planning, process modeling for BPR, and process
modeling for systems analysis. We lay out the sets of the various systems analysis DFDs: context, decomposition, event-response list and
event handlers, event diagram, system diagram, primitive diagrams.
We also discuss fact-finding for process modeling and the role of
CASE.
•
Next we walk through the process of constructing process models.
•
Now that the students have seen a completed DFD and know what it
can tell them and what it cannot, then they are ready to learn about
specifying process logic with structured English or decision tables.
•
The last topic, as in earlier editions, is synchronizing process models
with data models and locations.
Lesson Planning Notes for Slides
The following instructor notes, keyed to slide images from the PowerPoint repository, are intended to help instructors integrate the slides into their individual lesson plans for this chapter.
Slide 1
Chapter 9
Process Modeling
McGraw-Hill/Irwin
Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
slide appearance after initial mouse click
in slide show mode
This repository of slides is intended to support the
named chapter. The slide repository should be
used as follows:
Copy the file to a unique name for your course
and unit.
Edit the file by deleting those slides you don’t
want to cover, editing other slides as appropriate
to your course, and adding slides as desired.
Print the slides to produce transparency masters
or print directly to film or present the slides using
a computer image projector.
Each slide includes instructor notes. To view
those notes in PowerPoint, click-left on the View
Menu; then click left on Notes View sub-menu.
You may need to scroll down to see the instructor
notes.
The instructor notes are also available in hardcopy as the Instructor Guide to Accompany Systems Analysis and Design Methods, 6/ed.
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Process Modeling
9-3
Slide 2
Chapter 9 objectives.
Objectives
•
•
•
•
•
•
•
•
•
•
•
•
Define systems modeling and differentiate logical and physical
models.
Define process modeling and explain its benefits.
Recognize and understand basic concepts and constructs of a
process model.
Read and interpret a data flow diagram.
Explain when to construct process models and where to store
them.
Construct a context diagram to illustrate a system’s interfaces with
its environment.
Identify use cases, external and temporal business events.
Perform event partitioning and organize events in a functional
decomposition diagram.
Draw event diagrams and merge them into a system diagram.
Draw primitive data flow diagrams and describe the elementary
data flows in terms of data structures and procedural logic.
Document the distribution of processes to locations.
Synchronize data and process models using a CRUD matrix.
Teaching Notes
This slide shows the how this chapter's content
fits with the building blocks framework used
throughout the textbook. The emphasis of this
chapter is upon PROCESSES. It also reflects the
fact that process modeling may be performed
during certain analysis phases and involves not
only systems analysts…but owners and users.
Slide 3
9-3
Slide 4
Models: Logical and Physical
Model – a pictorial representation of reality.
Just as a picture is worth a thousand words, most
models are pictorial representations of reality.
Logical model – a
nontechnical pictorial
representation that depicts
what a system is or does.
Synonyms or essential
model, conceptual model,
and business model.
9-4
Physical model – a
technical pictorial
representation that depicts
what a system is or does and
how the system is
implemented. Synonyms are
implementation model and
technical model.
Teaching Notes
In some books, the term logical is called a conceptual or essential. The term essential comes
from the notion that the model represents the
“essence” of the system.
For database-oriented instructors, the term logical in the world of systems analysis is NOT
equivalent to the term logical in the world of database. In the database world, a “logical schema” is
already constrained by the choice of a database
technology, which runs contrary to the systems
analysis expectation that a logical model is technology-independent.
In some books, the term physical is called implementation or technical.
Emphasize that there are nearly always multiple
technical solutions for any given set of business
requirements. In most projects, there is one logical model that represents the mandatory and
desirable business requirements, regardless of
how those requirements might be implemented.
On the other hand, given that one logical model,
there are multiple candidate physical models that
could represent alternative, technical implementations that could fulfill the business requirements
(although analysts rarely draw more than one or
two of those physical models).
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-4
Chapter Nine
Slide 5
Why Logical System Models
No additional notes
• 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.
9-5
Slide 6
Process Modeling and DFDs
Process modeling – a technique used to organize and
document a system’s processes.
•
•
•
•
Flow of data through processes
Logic
Policies
Procedures
Data flow diagram (DFD) – a process model used to
depict the flow of data through a system and the work or
processing performed by the system. Synonyms are
bubble chart, transformation graph, and process model.
Teaching Notes
Many, if not most students have drawn or seen
process models in the form of program flowcharts.
Unfortunately, flowcharts are control-flow process
models as opposed to data flow process models.
This can cause some students trouble because
they want to illustrate structured flow of control
(nonparallel processing) in their early DFDs.
Most introductory information systems books at
least introduce, with one or two examples, DFDs.
• The DFD has also become a popular tool for business
process redesign.
9-6
Slide 7
Simple Data Flow Diagram
9-7
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Teaching Notes
We have found it useful to walk through this first
DFD. Don’t be alarmed if students take exception to some of the oversimplification of the illustrated problem—it can actually contribute to the
learning experience.
Process Modeling
9-5
Slide 8
No additional notes
Differences Between DFDs
and Flowcharts
• Processes on DFDs can operate in parallel (atthe-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 a DFD can have dramatically
different timing (daily, weekly, on demand)
• Processes on flowcharts are part of a single program
with consistent timing
9-8
Slide 9
External Agents
External agent – an outside person, unit,
system, or organization that interacts with a
system. Also called an external entity.
• External agents define the “boundary” or
scope of a system being modeled.
• As scope changes, external agents can
become processes, and vice versa.
• Almost always one of the following:
• Office, department, division.
• An external organization or agency.
• Another business or another
information system.
• One of system’s end-users or managers
9-9
Slide 10
• Named with descriptive, singular noun
Gane and Sarson shape
DeMarco/Yourdon shape
Data Stores
Data store – stored data intended for later
use. Synonyms are file and database.
• 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)
Places
Objects
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)
• Named with plural noun
9-10
Gane and Sarson shape
DeMarco/Yourdon shape
Teaching Notes
It is very important to emphasize the external
agents on DFDs are not the same as entities on
ERDs (from Chapter 7)—especially if the instructor prefers the more traditional term “external
entity.”
This is true even though you could have both an
entity (on an ERD) with the same name as an
external agent/entity on a DFD. Consider the
entity CUSTOMER and the external agent CUSTOMER:
The entity CUSTOMER indicates the requirement
to store data about customers.
The external agent CUSTOMER indicates the
requirement for an interaction (inputs and/or outputs) with customers.
It is very important for students to understand that
external agents are “processes” outside of the
scope of the system or business. As such, as
scope “increases,” external agents can become
processes. Conversely, if scope “decreases,”
processes can become external agents.
Teaching Notes
Emphasize that a data store contains all instances of a data entity (from the data model).
That is why data store names are plurals (as
contrasted to data entity names that are singular).
Although we don’t prefer it, some analysts designate a data store to contain all instances of several entities and relationships from a data model.
For example, an ORDERS data store might include all instances of the data entities ORDER
and ORDERED PRODUCT, and all instances of
the relationship between ORDER and ORDERED
PRODUCT—We prefer the simplicity of representing each data entity from the data model as
its own data store on the process models.
Emphasize that because data stores are shared
resources available to many processes, it is acceptable to duplicate them on several DFDs—
The duplication does NOT indicate redundant
storage (on logical DFDs); it merely represents
the sharing of the data store by several processes.
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-6
Chapter Nine
Slide 11
Process Concepts
No additional notes
Process – work performed by a system in
response to incoming data flows or
conditions. A synonym is transform.
• All information systems include
processes - usually many of them
• Processes respond to business
events and conditions and transform Gane and Sarson shape
data into useful information
• Modeling processes helps us to understand the
interactions with the system's environment, other
systems, and other processes.
• Named with a strong action verb followed by object
clause describing what the work is performed on/for .
9-11
Slide 12
The System is Itself a Process
No additional notes.
9-12
Slide 13
Process Decomposition
Decomposition – the act of breaking a system
into sub-components. Each level of abstraction
reveals more or less detail.
9-13
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
No additional notes.
Process Modeling
9-7
Slide 14
Teaching Notes
Decomposition is a top-down problem-solving
approach.
It might be useful to point out the numbering
scheme. This scheme is common, but we do not
like it because if the system is restructured, it
forces renumbering all processes.
Some instructors like to do a quick example using
a small but realistic problem.
Decomposition Diagrams
Decomposition
diagram – a tool
used to depict the
decomposition of a
system. Also
called hierarchy
chart.
9-14
Slide 15
No additional notes
Types of Logical Processes
Function – a set of related and ongoing activities of a
business.
• A function has no start or end.
Event – a logical unit of work that must be completed as
a whole. Sometimes called a transaction.
• Triggered by a discrete input and is completed when process
has responded with appropriate outputs.
• Functions consist of processes that respond to events.
Elementary process – a discrete, detailed activity or
task required to complete the response to an event.
Also called a primitive process.
• The lowest level of detail depicted in a process model.
9-15
Slide 16
Common Process Errors on
DFDs
9-16
Teaching Notes
Idea: Correct this diagram as an in-class exercise.
3.1.1: To correct the diagram, a data flow, ACCOUNTING DATA, should be added from the
data store, MEMBER ACCOUNTS, to process
3.1.1.
3.1.2: To fix the black hole, we might add an
output data flow called NEW MEMBER ACCOUNT from process 3.1.2 to the data store
MEMBER ACCOUNTS.
3.1.3: To fix the miracle, you would need to at
least add a data flow such as ACCOUNTING
DATA from the data store, MEMBER ACCOUNTS, to process 3.1.3. In all likelihood, you
also need some type of triggering data flow, such
as ACCOUNT FREEZE AUTHORIZATION, from
a new external agent, such ACCOUNTING DEPARTMENT, to process 3.1 3.
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-8
Chapter Nine
Slide 17
Data Flows & Control Flows
Data flow – data that is input to or
output from a process.
• A data flow is data in motion
• 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).
Composite data flow – a data flow
that consists of other data flows.
Control flow – a condition or
nondata event that triggers a
process.
Data flow name
Control flow name
• Used sparingly on DFDs.
9-17
Slide 18
Data Flow Packet Concept
• Data that should travel together should be
shown as a single data flow, no matter how
many physical documents might be included.
9-18
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Teaching Notes
Most books do not teach “control flows.” The
were initially proposed by Paul Ward in his books
that extended structured analysis techniques to
cover real-time systems. They are especially
useful in contemporary information systems
analysis because they are as close as structured
analysis gets to illustrating “messages” in an
object-oriented world.
Make sure students do not confuse data flows
with flowchart arrows. Flowchart arrows are not
named because they merely indicate “the next
step.” Data flows pass actual data attributes to
and from processes.
CRUD is a useful acronym from the database
world to remember the basic data flows as they
relate to data stores: Create, Read, Update (or
change), and Delete.
One of the most common uses of composite data
flows is to combine many reports into a single
data flow on a high-level DFD. They can also be
used to combine similar transactions on a higher
level DFD before differentiating between those
flows on lower-level DFDs.
Use case diagrams, an object-oriented analysis
tool that also describes interfaces are taught in
Chapter 7.
No additional notes.
Process Modeling
9-9
Slide 19
Composite and Elementary
Data Flows
No additional notes.
Composite
flow
Elementary
flows
Junction indicates that
any given order is an
instance of only one of
the order types.
9-19
Slide 20
Composite and Elementary
Data Flows
Composite
flow
Elementary
flows
Junction indicates that
any given order is an
instance of only one of
the order types.
9-19
Slide 21
Rules for Data Flows
•
•
•
Teaching Notes
Some DFD methodologies suggest that data
flows to and from data stores not be named. We
think this confuses the end-users when they try to
read the diagrams. Also, we believe that it is
easier to have DFD errors of omission if the rules
state that some flows are named while others are
not.
Some DFD notations actually use the CRUD
letters only to name flows to and from data
stores. We consider this an acceptable alternative. CRUD is a useful acronym from the database world to remember the basic data flows as
they relate to data stores: Create, Read, Update
(or change), and Delete.
No additional notes.
A data flow
should never go
unnamed.
In logical
modeling, data
flow names
should describe
the data flow
without
describing the
implementation
All data flows
must begin
and/or end at a
process.
9-21
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-10
Chapter Nine
Slide 22
No additional notes.
Data Conservation
Data conservation – the practice of
ensuring that a data flow contains only
data needed by the receiving process.
9-22
Slide 23
• Sometimes called starving the processes.
• New emphasis on business process
redesign to identify and eliminate
inefficiencies.
• Simplifies the interface between those
processes.
• Must precisely define the data composition
of each data flow, expressed in the form of
data structures.
Data Structures
Data attribute – the smallest piece of data that
has meaning to the users and the business.
Data structure – a specific arrangement of data
attributes that defines an instance of a data flow.
• The data attributes that comprise a data flow are
organized into data structures.
• Data flows can be described in terms of the following
types of data structures:
9-23
Slide 24
• A sequence or group of data attributes that occur one after
another.
• The selection of one or more attributes from a set of attributes.
• The repetition of one or more attributes.
Data Structure for a Data Flow
DATA STRUCTURE
ENGLISH ENTERPRETATION
ORDER=
ORDER NUMBER +
ORDER DATE+
[ PERSONAL CUSTOMER NUMBER,
CORPORATE ACCOUNT
NUMBER]+
SHIPPING ADDRESS=ADDRESS+
(BILLING ADDRESS=ADDRESS)+
1 {PRODUCT NUMBER+
PRODUCT DESCRIPTION+
QUANTITY ORDERED+
PRODUCT PRICE+
PRODUCT PRICE SOURCE+
EXTENDED PRICE } N+
SUM OF EXTENDED PRICES+
PREPAID AMOUNT+
(CREDIT CARD
NUMBER+EXPIRATION DATE)
(QUOTE NUMBER)
An instance of ORDER consists of:
ORDER NUMBER and
ORDER DATE and
Either PERSONAL CUSTOMER NUMBER
or CORPORATE ACCOUNT
NUMBER
and SHIPPING ADDRESS (which is
equivalent
to ADDRESS)
and optionally: BILLING ADDRESS
(which is
equivalent to
ADDRESS)
and one or more instances of:
PRODUCT NUMBER and
PRODUCT DESCRIPTION and
QUANTITY ORDERED and
PRODUCT PRICE and
PRODUCT PRICE SOURCE and
EXTENDED PRICE
and SUM OF EXTENDED PRICES and
PREPAID AMOUNT and
optionally: both CREDIT CARD NUMBER
and EXPIRATION DATE
ADDRESS=
(POST OFFICE BOX NUMBER)+
STREET ADDRESS+
CITY+
[STATE, MUNICIPALITY]+
(COUNTRY)+
9-24
POSTAL CODE
An instance of ADDRESS consists of:
optionally: POST OFFICE BOX NUMBER
and
STREET ADDRESS and
CITY and
Either STATE or MUNICIPALITY
and optionally: COUNTRY
and POSTAL CODE
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Conversion Notes
Many structured analysis books do not specifically use the term data structure, but the relational algebraic notation is very common in both
books and CASE tools.
Some books refer to data attributes as data elements. Some also call them data fields, but
some would argue that field is a very technical-,
implementation-, or physical-oriented term (that is
not consistent with our emphasis on logical
DFDs).
Teaching Notes
Bring several “physical” business forms to class.
Transform one form into its relational algebraic
data structure. Then, divide students into teams
and ask them to perform the same exercise on a
form and present their solutions to the class.
Process Modeling
9-11
Slide 25
Data Structure Constructs
Data Structure
Format by Example
(relevant portion is boldfaced
English Interpretation
(relevant portion is boldfaced)
Sequence of Attributes - The
WAGE AND TAX STATEMENT=
sequence data structure
TAXPAYER IDENTIFICATION
indicates one or more attributes NUMBER+
that may (or must) be included in
TAXPAYER NAME+
a data flow.
TAXPAYER ADDRESS+
WAGES, TIPS, AND
COMPENSATION+
FEDERAL TAX
WITHHELD+…
An instance of WAGE AND TAX
STATEMENTS consists of:
TAXPAYER IDENTIFICATION
NUMBER and
TAXPAYER NAME and
TAXPAYER ADDRESS and
WAGES, TIPS AND
COMPENSATION and
FEDERAL TAX WITHHELD
and…
Selection of Attributes - The
selection data structure allows
you to show situations where
different sets of attributes
describe different instances of
the data flow.
An instance or ORDER consists
of:
Either PERSONAL
CUSTOMER NUMBER or
CORPORATE
ACCOUNT NUMBER; and
ORDER DATE and…
ORDER=
(PERSONAL CUSTOMER
NUMBER,
CORPORATE ACCOUNT
NUMBER)+
ORDER DATE+…
9-25
Slide 26
Data Structure Constructs
(continued)
Data Structure
Format by Example
(relevant portion is boldfaced
Repetition of Attributes - The
POLICY NUMBER+
repetition data structure is used
POLICYHOLDER NAME+
to set off a data attribute or
POLICY HOLDER
group of data attributes that may ADDRESS+
(or must) repeat themselves a
0 {DEPENDENT NAME+
specific number of time for a
DEPENDENT’S
single instance of the data flow. RELATIONSHIP} N+
The minimum number of
1 {EXPENSE DESCRIPTION+
repetitions is usually zero or
SERVICE PROVIDER+
one.
EXPENSE AMOUNT} N
The maximum number of
repetitions may be specified as
“n” meaning “many” where the
actual number of instances
varies for each instance of the
data flow.
English Interpretation
(relevant portion is boldfaced)
An instance of CLAIM consists
of:
POLICY NUMBER and
POLICYHOLDER NAME and
POLICYHOLDER ADDRESS
and
zero or more instance of:
DEPENDENT NAME and
DEPENDENT’S
RELATIONSHIP and
one or more instances of:
EXPENSE DESCRIPTION
and
SERVICE PROVIDER and
EXPENSE ACCOUNT
Teaching Notes
Point out that the same basic structures of sequence, selection, and iteration—that we applied
to procedures using Structured English—are
being applied here to describe data structures.
We have never found any form or file structure
that could not be described using this notation!
Teaching Notes
Point out that the same basic structures of sequence, selection, and iteration—that we applied
to procedures using Structured English—are
being applied here to describe data structures.
We have never found any form or file structure
that could not be described using this notation!
9-26
Slide 27
Data Structure Constructs
(concluded)
Data Structure
Optional Attributes - The
optional notation indicates that
an attribute, or group of
attributes in a sequence or
selection date structure may not
be included in all instances of a
data flow.
Note: For the repetition data
structure, a minimum of “zero” is
the same as making the entire
repeating group “optional.”
Reusable Attributes - For
groups of attributes that are
contained in many data flows, it
is desirable to create a separate
data structure that can be
reused in other data structures.
9-27
Format by Example
(relevant portion is boldfaced
CLAIM=
POLICY NUMBER+
POLICYHOLDER NAME+
POLICYHOLDER ADDRESS+
( SPOUSE NAME+
DATE OF BIRTH)+…
English Interpretation
(relevant portion is boldfaced)
An instance of CLAIM consists
of:
POLICY NUMBER and
POLICYHOLDER NAME and
POLICYHOLDER ADDRESS
and
optionally, SPOUSE NAME
and
DATE OF BIRTH and…
DATE=
MONTH+
DAY+
YEAR+
Then, the reusable structures
can be included in other data
flow structures as follows:
ORDER=ORDER
NUMBER…+DATE
INVOICE=INVOICE
NUMBER…+DATE
PAYMENT=CUSTOMER
NUMBER…+DATE
Teaching Notes
Point out that the same basic structures of sequence, selection, and iteration—that we applied
to procedures using Structured English—are
being applied here to describe data structures.
We have never found any form or file structure
that could not be described using this notation!
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-12
Chapter Nine
Slide 28
Data Types and Domains
Teaching Notes
The same concepts with the same names were
used in chapter 8.
Data attributes should be defined by data
types and domains.
Data type - a class of data that be stored
in an attribute.
• Character, integers, real numbers, dates,
pictures, etc.
Domain – the legitimate values for an
attribute.
9-28
Slide 29
Diverging and Converging
Data Flows
No additional notes.
Diverging data flow – a data flow that splits
into multiple data flows.
• Indicates data that starts out naturally as one flow,
but is routed to different destinations.
• Also useful to indicate multiple copies of the same
output going to different destinations.
Converging data flow – the merger of multiple
data flows into a single packet.
• Indicates data from multiple sources that can (must)
come together as a single packet for subsequent
processing.
9-29
Slide 30
Diverging and Converging
Data Flows
9-30
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Teaching Notes
Different CASE tools use different notations to
illustrate converging and diverging data flows. In
fact, some CASE tools do not even support this
concept.
Process Modeling
9-13
Slide 31
When to Draw Process Models
• Strategic systems planning
• Enterprise process models illustrate important
business functions.
Teaching Notes
This is a context slide only. In this chapter,
our demonstration of DFDs is exclusively for
“systems analysis,” specifically “requirements modeling.”
• Business process redesign
• “As is” process models facilitate critical analysis.
• “To be” process models facilitate improvement.
• Systems analysis (primary focus of this
course)
9-31
Slide 32
•
•
•
•
Model existing system including its limitations
Model target system’s logical requirements
Model candidate technical solutions
Model the target technical solution
Classical Structured Analysis
Rarely practiced anymore because cumbersome & time-consuming
9-32
Slide 33
1. Draw top-down physical DFDs that represent current
physical implementation of the system.
2. Convert physical DFDs to logical equivalents.
3. Draw top-down logical DFDs that represent improved
system.
4. Describe all data flows, data stores, policies, and
procedures in data dictionary or encyclopedia.
5. Optionally, mark up copies of the logical DFDs to
represent alternative physical solutions.
6. Draw top-down physical DFDs representing target
solution.
Modern Structured Analysis
(More Commonly Practiced)
1. Draw context DFD to establish initial project scope.
2. Draw functional decomposition diagram to partition the
system into subsystems.
3. Create event-response or use-case list for the system
to define events for which the system must have a
response.
4. Draw an event DFD (or event handler) for each event.
5. Merge event DFDs into a system diagram (or, for larger
systems, subsystem diagrams).
6. Draw detailed, primitive DFDs for the more complex
event handlers.
7. Document data flows and processes in data dictionary.
Teaching Notes
It might be best NOT to show this slide to
students. It is primarily intended to help instructors understand the differences between
original structured analysis and contemporary structured analysis (the latter is shown
on the next slide).
This approach to systems analysis is rarely
practiced and is no longer recommended
even by its original evangelists, Tom DeMarco
and Ed Yourdon. Yourdon officially updated
the methodology based on the seminal work,
Essential Systems Analysis, by McMenamin
and Palmer. The revised approach is shown
on the next slide.
Teaching Notes
Although this process may not be as familiar
to some adopters as the top-down, fully leveled, classical “physical-logical-logicalphysical” approach in the 1976 DeMarco
methodology, this is the more contemporary
approach and is taught in our book. The
original approach is rarely, if ever, practiced
because it is so labor intensive and time consuming.
9-33
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-14
Chapter Nine
Slide 34
Structured Analysis Diagram
Progression (1 of 3)
Teaching Notes
The numbers in red correspond to the numbers on the previous slide.
Structured Analysis Diagram
Progression (2 of 3)
Teaching Notes
The numbers in red correspond to the numbers on the slide 33.
Structured Analysis Diagram
Progression (3 of 3)
Teaching Notes
The numbers in red correspond to the numbers on the slide 33.
9-34
Slide 35
9-35
Slide 36
9-36
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Process Modeling
9-15
Slide 37
No additional notes.
CASE for Process Modeling
9-37
Slide 38
Teaching Notes
This may be review from chapter 5.
Context Data Flow Diagram
•
9-38
Slide 39
Context data flow diagram - a process model
used to document the scope for a system. Also
called the environmental model.
1. Think of the system as a "black box."
2. Ask users what business transactions the system
must respond to. These are inputs, and the sources
are external agents.
3. Ask users what responses must be produced by the
system. These are outputs, and the destinations are
external agents.
4. Identify any external data stores, if any.
5. Draw a context diagram.
SoundStage Context DFD
9-39
Teaching Notes
Emphasize that a context DFD does not have
to show every net data flow. For most systems, that would overwhelm the reader. Trivial or less common flows can be omitted until
later diagrams, and composite data flows can
be created to combine multiple flows. As a
result, and in the strictest sense, not all primitive data flows may “balance” up to the context DFD, but we sacrifice that balancing to
improve readability and validation. All data
flows on the context DFD will balance down to
the lower-level DFDs (although composite
data flows will be replaced by their separate
component data flows).
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-16
Chapter Nine
Slide 40
No additional notes.
SoundStage Functional
Decomposition Diagram
• Break system into
sub-components
to reveal more
detail.
• Every process to
be factored
should be
factored into at
least two child
processes.
• Larger systems
might be factored
into subsystems
and functions.
9-40
Slide 41
Events and Use Cases
• External events are initiated by external agents. They
result in an input transaction or data flow.
• Temporal events are triggered on the basis of time,
or something that merely happens. They are indicated
by a control flow.
Teaching Notes
Events are very similar to use cases in objectoriented analysis.
Events are represented on DFDs as data flows
(for external events) or control flows (for temporal and state events).
• State events trigger processes based on a system’s
change from one state or condition to another. They
are indicated by a control flow.
• Use case – an analysis tool for finding and identifying
business events and responses.
9-41
Slide 42
• Actor – anything that interacts with a system.
SoundStage Partial Use Case
List
Actor/
External Agent
Trigger
Establishes a new
membership
subscription plan to
entice new members.
New Member
Subscription
Program
Marketing
Establishes a new
membership
resubscription plan to
lure back former
members.
A subscription plan
expires.
Past Member
Resubscription
Program
Joins club by
subscribing.
New
Subscription
(time)
Member
9-42
Event
(or Use Case)
Marketing
(current date)
Response
Generate Subscription Plan
Confirmation.
Create Agreement in the
database.
Generate Subscription Plan
Confirmation.
Create Agreement in the
database.
Generate Agreement Change
Confirmation.
Logically delete Agreement in
database.
Generate Member Directory
Update Confirmation.
Create Member in database.
Create first Member Order and
Member Ordered Products in
database.
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Teaching Notes
Walk through this so that students understand what goes in a use case list for DFDs.
This is an abbreviated list from what is shown
in the text.
Process Modeling
9-17
Slide 43
SoundStage Partial
Event Decomposition Diagram
Teaching Notes
Most event decomposition diagrams will require multiple pages (or one very large plotter-style page) because most systems are
required to respond to many events (possibly
dozens or hundreds).
9-43
Slide 44
No additional notes.
Event Diagrams
Event diagram – data flow diagram that
depicts the context for a single event.
• One diagram for each event process
• Depicts
• Inputs from external agents
• Outputs to external agents
• Data stores from which records must be "read."
Data flows should be added and named to
reflect the data that is read.
• Data stores in which records must be created,
deleted, or updated. Data flows should be
named to reflect the update.
9-44
Slide 45
Simple Event Diagram
No additional notes.
9-45
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-18
Chapter Nine
Slide 46
Event Diagram (more complex)
No additional notes.
9-46
Slide 47
Temporal Event Diagram
No additional notes.
9-47
Slide 48
System DFD
9-48
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Teaching Notes
Most system DFDs will not fit on one or two
pages—too many event processes. Instead
they must be illustrated in a series of system
diagrams that correspond to the structure
originally depicted in the functional decomposition diagram.
Process Modeling
9-19
Slide 49
No additional notes.
System DFD (concluded)
9-49
Slide 50
Balancing
Balancing - a concept that requires that
data flow diagrams at different levels of
detail reflect consistency and completeness
Teaching Notes
Discuss balancing with the class, the concept
that requires that data flow diagrams at different levels of detail reflect consistency and
completeness.
• Quality assurance technique
• Requires that if you explode a process to
another DFD to reveal more detail, you must
include the same dta flows and data stores
9-50
Slide 51
Primitive Diagrams
• Some (not necessarily all) event
processes may be exploded into primitive
diagrams to reveal more detail.
• Complex business transaction processes
• Process decomposed into multiple
elementary processes
• Each elementary process is cohesive - it
does only one thing
• Flow similar to computer program structure
Teaching Notes
It is important to recognize that not all events
require a primitive DFD to be drawn. This is
especially true of most report-writing and
inquiry response event processes. Drawing
detailed DFDs for such processes is usually
little more than “busy work.”
9-51
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-20
Chapter Nine
Slide 52
Primitive DFD
No additional notes.
(see book for more readable copy)
9-52
Specifying a Data Flow
Using a CASE Tool
Slide 53
Teaching Notes
The screen capture demonstrates the dialogue box used to insert the data structure for
a data flow on a DFD. Each data flow would
require a similar data structure to be specified.
9-53
Slide 54
Process Logic
• Data Flow Diagrams good for identifying and
describing processes
• Not good at showing logic inside processes
• Need to specify detailed instructions for
elementary processes
• How to do it?
• Flowcharts & Pseudocode - most end users do not
understand them
• Natural English - imprecise and subject to
interpretation
9-54
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
No additional notes.
Process Modeling
9-21
Slide 55
Problems with Natural English
9-55
Slide 56
•Many do not write well and do not
question writing abilities.
•Many too educated to communicate
with general audience
•Some write everything like it was a
program.
•Can allow computing jargon,
acronyms to dominate language.
•Statements frequently have
Conversion Notes
The text on this slide has been shortened for
the sake of readability. Refer to Figure 9-6 in
the text for fuller explanations and examples.
Source: Adapted from Matthies, Leslie, The New Playscript Procedure,
(Stamford, CT: Office Publications, Inc. 1977)
Structured English
Structured English – a language syntax
for specifying the logic of a process.
• Based on the relative strengths of structured
programming and natural English.
Teaching Notes
On the diagram, we recorded the Structured
English inside the process box to reinforce
the fact that the Structured English specifies
the underlying procedure being executed by
the process. In practice, the procedural
specification is recorded in a data dictionary/encyclopedia that is separate from the
actual diagram (but linked to/associated with
the process “name” on the DFD).
If students are familiar with pseudocode,
point out the similarities and differences between Structured English and pseudocode.
9-56
Slide 57
Structured English Constructs
(Part 1)
No additional notes.
9-57
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-22
Chapter Nine
Slide 58
Structured English Constructs
(Part 2)
Teaching Notes
Decision tables are useful for simplifying very
complex combinations of conditions. They
replace complex, nested if-then-else selection
structures.
Structured English Restrictions
on Process Logic
No additional notes.
9-58
Slide 59
9-59
Slide 60
• Only strong, imperative verbs may be used.
• Only names that have been defined in project
dictionary may be used.
• Formulas should be stated clearly using
appropriate mathematical notations.
• Undefined adjectives and adverbs are not
permitted.
• Blocking and indentation are used to set off the
beginning and ending of constructs.
• User readability should always take priority.
Policies and Decision Tables
Policy – a set of rules that govern show a
process is to be completed.
Decision table – a tabular form of
presentation that specifies a set of
conditions and their corresponding actions.
• As required to implement a policy.
9-60
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
No additional notes.
Process Modeling
9-23
Slide 61
A Simple Decision Table
No additional notes.
9-61
Slide 62
Describing an Elementary
Process Using a CASE Tool
No additional notes.
Data & Process Model
Synchronization CRUD Matrix
No additional notes.
9-62
Slide 63
9-63
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-24
Chapter Nine
Slide 62
Process Distribution
9-64
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
No additional notes.
Process Modeling
9-25
Answers to End of Chapter Questions and Exercises
Review Questions
1. A logical model is a non-technical design shows what a system is and/or
what it does. Logical models are independent of any technical implementation issues and do not show how the system will do something, only what it
will do. Common synonyms for logical model are essential model, conceptual model, and business model.
2. Logical models help encourage creativity and reduce stakeholder biases by
focusing only on business issues, not technical implementation concerns.
As a result, there is less risk that stakeholders will lose sight of the core
business issues and miss critical business requirements. Logical models,
because they are not technical in nature, also provide an excellent method
for systems analysts to communicate with system owners and users in a
language they are comfortable with.
3. A data flow diagram is a graphic tool that illustrates how data moves
through a system, and what processing is performed by the system as the
data flows through it. Common synonyms include bubble chart, transformation graph, and process model.
4. There are three major differences between data flow diagrams and flowcharts.
1) On a data flow diagram, multiple processes can operate concurrently.
On a flowchart, only one process at a time can execute.
2) Data flow diagrams show the paths through which data moves through
the system; and looping and/or branching are typically not shown.
Flowcharts show the sequence of processes through the system, and include looping and branching.
3) Data flow diagrams are time-independent; the processes shown on data
flow diagrams can occur at widely different times. Flowcharts are the
opposite, i.e., they are time-dependent.
5. A system is considered to be process because it performs work on or in response to inputs from the environment, and has a feedback and control loop
6. Decomposition is the technique of breaking a system into subsystems and
subprocesses, which in turn are broken down into smaller subsystems and
subprocesses, until a manageable subset is achieved. Because an entire
system is usually too complex or large to view and understand as a single
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-26
Chapter Nine
process, the purpose of decomposition is to promote understanding by being
able to view a process as a whole.
The tool used to show the decomposition of a system is a decomposition
diagram, also called hierarchy chart.
7. a. Function: a set of related and ongoing activities of a business which have
no beginning or end, but which operate continuously as needed.
For example, an accounting system may have functions such as account receivable systems, account payable systems, and payroll systems,
etc.
b. Event: a logical unit of work that is triggered by a specific, separate input, and which must by completed as a whole with appropriate outputs.
For example, for the payroll function, there may be events such as
print checks, calculate salary, and calculate tax withheld.
c. Elementary process: Also called a primitive process, it is the specific lowest level of activity or task needed to complete the response to an.
For example, in the calculate tax withheld event, there may be processes such as validate salary input and update employees’ information.
8. a. A process that has inputs but no outputs (often called a black hole).
b. A process whose inputs are not able to produce the output shown, because the inputs and/or outputs are misnamed, or because the facts are
not complete. (often called a gray hole)
c. A process that has outputs, but no inputs.
9. Structured English is a language syntax based upon a combination of structured programming and natural English that is used to specify process logic
in data flow diagrams and other process models. Structured English is an
effective method of communicating in a consistent and coherent manner
with both non-technical end-users, who must be able to understand
whether the logic is correct, and with technical developers, who must build
and implement the business logic in the system
10. The convention for data flow names is to use nouns and noun phrases that
are singular, descriptive and unique. Adjectives and adverbs can be used to
help describe how a data flow has been changed or transformed by processing.
For example, for data flow concerning checking out a product, it should
be named CHECKOUT, which is singular. Also, in order to make it unique,
it could add adjectives or adverbs to the data flow name. In this case,
CHECKOUT can be changed to VALIDATE CHECKOUT, SUCCESSFUL
CHECKOUT, or CHECKOUT FAILED.
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Process Modeling
9-27
11. Data conservation is a technique that ensures a data flow does not contain
excess data, but only the data actually needed by the process receiving the
input. Data conservation is used to simplify the interfaces between different processes and to eliminate inefficiencies in processing data.
12. External agents or external entities are people, organizations, units of an
organization and systems outside the system boundary that that interact
with the system inside the boundary. External agents can change because
as project scope and goals change, the boundaries of the information system can grow or shrink. External agents formerly outside the boundary
may now be inside the boundary, and vice versa
13. Context data flow diagram: this is used in the very beginning of the analysis to set up the initial scope of the project. This diagram is often about
one page in length, and it shows the major interaction between the system
and its environment.
Functional decomposition diagram: this diagram is used to divide the system into smaller logical functions. If the system is small, this diagram can
be omitted.
Event-Response or Use case list: either one of the list will be constructed to
make sure the business events that the system must respond.
Event decomposition diagram: event handlers may be added to the decomposition diagram for each of the event. Until now, the outline of the system
is established.
Event diagram: this is an optional diagram used to validate for each of the
event.
System diagram: this diagram is used to combine all the event diagrams.
Primitive diagram: this is used specially for event processes that need additional processing details. It will show all the elementary processes, data
stores, and data flows for an event.
14. A context data flow diagram, also called an environmental model, is used.
(Add an explanation of what is depicted.)
15. Even though data and process models are showing different perspectives of
the system, they are closely related. Therefore, we should make sure both
kinds of models are synchronized so that consistency and completeness
can be achieved for the system.
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-28
Chapter Nine
Problems and Exercises
1. Your responses may vary, but a basic response should include the following
logical processes and data flows:
Entities:
Employee
Employee’s Supervisor
Employer’s Bank
Payroll Department
Data Stores:
Payroll Transactions
Employer bank account
Employee bank account
Logical Processes:
Prepare time sheet
Review and approve time sheet
Prepare bi-weekly payroll
Authorize and disburse funds
Deposit funds
Data Flows:
Time sheet
Approved time sheet
Bi-weekly payroll list
Electronic fund transfer
E-mail notifications
2. 1F, 2J, 3G, 4K, 5L, 6H, 7C, 8A, 9B, 10M, 11D, 12, 13E
3. In a decomposition diagram, there is no such thing as a single child, because it would not show any additional detail. A parent must always have
two or more children.
For different reasons, a child may have only one parent – it cannot be a decomposition of more than one process.
Arrowheads are not shown on the connections of a decomposition diagram
because the diagram shows structure, not flow.
The connections are not named because they implicitly all have the same
name – CONSISTS OF. If all the child processes were added together, the
sum would be the parent process.
4.
Conditions
and Actions
C1: Type of
Vehicle
C2: At least
Rule 1
Passenger
Vehicle
Yes
Car Pool Lane Policy Decision Table
Rule 2
Rule 3
Rule 4 Rule 5
Passenger
Vehicle
No
Passenger
Vehicle
No
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Motorcycle
Hybrid
Rule 6
Rule 7
All
Others
All
Others
Doesn’t Doesn’t Doesn’t Doesn’t
matter matter matter matter
Process Modeling
2 people
C3: During
carpool restricted
times
and days
A1: Let vehicle pass
A2: Stop
vehicle and
write ticket
9-29
Doesn’t
matter
Yes
X
Doesn’t Doesn’t
matter matter Yes
No
X
X
X
X
No
X
X
5. a. Use the “black box” approach, i.e., visualize the system you are building
as a container. At this point, it doesn’t matter how things that are inside
work, you just want to identify what is out and what is in.
b. Determine your net inputs, i.e., the business events your system must
respond to. The sources of these net inputs are external agents.
c. Determine your net outputs, i.e., the responses that your system must
produce to the business events. The destination of each of these net
outputs is also an external agent.
d. Identify each data store your system uses. Can your system change the
database or file structure? If the answer is no, the database or file is an
external data store and outside the project scope.
6. a. Net inputs: Request For Investigation form, Completed Investigation Report
b. Net outputs: New Case Folder, Completed Investigation Report,
Open/Close/In Progress Case Listing Report, Closed Investigation Report
c. External agents: Other Divisions, Field Offices
d. External data stores: State Criminal Justice Database, Federal Criminal
Justice Database
7. Your context diagram should have:
a. One and only one process, labeled “HQ Case Tracking System” or something similar.
b. Two Net Inputs from two sources (external agents):
a. Request for Investigation Form from Other Divisions
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-30
Chapter Nine
b. Completed Investigation Report from Field Office
c. Three Net Outputs to two destinations (external agents)
a. New Case Folder to Field Offices
b. Closed Investigation Report to Other Divisions
c. Open/Closed/In Progress Case Listing Report to Field Offices
d. Two external agents (Other Divisions, Field Offices)
e. Two external data stores: Federal Criminal Justice Database, State
Criminal Justice Database
8. The Structured English should look something like this:
1. For each INVESTIGATION CASE NUMBER in the data store CASES
a. For each FIELD OFFICE in the data store FIELD OFFICES that
matches the above INVESTIGATION CASE
1) Keep a running total of CASES OPENED DURING PAST WEEK for
the FIELD OFFICE
2) Keep a running total of CASES COMPLETED DURING PAST WEEK
for the FIELD OFFICE
3) Keep a running total of CASES IN PROGRESS for the FIELD OFFICE
4) Keep a running total of CASES IN PROGRESS OVER 6 MONTHS for
the FIELD OFFICE
9. The root process is the entire system – the Case Tracking System
The subsystems and their processes may vary. One basic example might be
as follows:
1.0
1.1
1.2
1.3
Operations Subsystem
Process incoming Requests for Service
Process incoming Completed Investigation Reports
Process outgoing Closed Investigation Reports
2.0 Reports Subsystem
2.1 Generate Opened/Closed/In Progress Case Listing Report
2.2 Generate New Case Folder
3.0
3.1
3.2
3.3
Table Maintenance Subsystem
Update Division Office Table
Update Field Office Table
Update Investigator Table
10. The partial use-case table should look something like this:
Actor
Event (or Use Case)
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Trigger
Responses
Process Modeling
Other Division
Field Office
(time)
9-31
Requests that an investigation be initiated
REQUEST FOR
INVESTIGATION
form
Notifies headquarters
office that an investigation has been completed and the case can
be closed
COMPLETED INVESTIGATION
REPORT
New work week begins
(current date)
Generate NEW
CASE FOLDER
Create INVESTIGATION in the database
Generate CLOSED
INVESTIGATION
REPORT
Update INVESTIGATION in the database
Generate
OPEN/CLOSED/IN
PROGRESS CASE
LISTING REPORT
11. The diagram for the selected event should depict one process. The input
sources and output destinations should be shown as external agents. If a
data store record is read as part of the event, the data store and data flow
should be shown in the diagram. The data flow should be appropriately
named re the data that is read. Any other data stores in which CRUD activity takes place should also be included in the diagram, along with named
data flows.
12. A8, B5, C7, D6, E1, F9, G10, H12, I11, J3, K2, L13, M4
13. Your matrix should resemble the one used in Figure 9-30. Every entry
should have at least one Create, Read, Update or Delete entry.
Project and Research
1. Response is open-ended, but should reference points made in this chapter
and Chapter 5 as to the value of design modeling. For example, would expect to see references made to the value of data flow diagrams in business
process redesign, the value of Structured English in helping users and developers come to a common understanding, etc.
2. Depending on the methodologies chosen, response may indicate the differences are mainly cosmetic or may find significant differences. Response
should examine not only notation methods, but also high-level approaches,
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
9-32
Chapter Nine
conceptual bases, modeling processes and sequences, modeling diagrams
used, and related tools and techniques.
3. Response should show data flow diagrams that are consistent with the textbook templates. Data flow diagrams for the two methods of renewing a subscription should be roughly similar, but the DFD for the digital version
should have fewer tasks since it does not require manual key data entry by
the publishing company, nor does it require any manual handling or delivery of the hardcopy versions. For the publisher, the online renewal and
digital format would probably be preferred since it is far less costly. Advantages from the perspective of the subscriber should include quicker delivery
and no physical storage problem for old issues. Disadvantages should include that even with current technology, readability is less than with a
printed version, and portability is inherently limited!
4. Response is open-ended, but should be insightful and well-reasoned. Further, response should indicate that all these authors have and/or are very
visionary, and are still highly respected by their peers as leading thinkers,
(although they are sharing the field with more competitors than in years
past).
5. Open-ended as to choice of system, but response should be complete and
thorough. Further, should use the data flow diagrams, data structures, and
other tools and techniques described in the textbook to produce a cohesive
and convincing set of documentation diagrams.
6. Open-ended, with a wide variety of viewpoints, depending upon currency
and position of articles that referenced in the response. But in general,
would expect a response to the effect that many leaders in systems design
feel that data and process modeling are being absorbed into and/or integrated with OOA and modeling, rather than being replaced.
Mini-Cases
1. Note to professor: This task and the open-ended ones like it can be a great
learning tool. Focus students on determining what the current system particulars are rather than what students want them to be. Encourage students to document existing business processes without judgment. As for
the actual diagrams: students usually are able to get the majority of processes in the systems level diagram. They do usually miss an external input/output or data stores (internal and external) – so keep your eye out.
2. Note to professor: Have students be aware of scope creep. Are they adding
functionality that they think is “cool,” or are they creating a system that has
a richness of functionality for the business? Remind students that these
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.
Process Modeling
9-33
are very different things. Also, be careful to make sure that students
streamline the use of information and the input of said information – their
goal should be for input to happen one time only.
3. Note to professor: Most probably, the students will not have gotten enough
information from their initial interview to complete this task. Remind them
that this is an iterative process. I.e. as system analysts, they will be returning to their customer many times to fully understand the customer’s needs
for a new system.
4. Note to professor: They will probably state that there is a large difference
between what they think the system should have and do, and what it actually does. Many departments have cumbersome and somewhat outdated
business processes that are not efficient. Why is that?
Team and Individual Exercises
There are no answers to this section.
Copyright © 2007 by McGraw-Hill Companies, Inc. All rights reserved.