IE 302 SYSTEMS ANALYSIS AND DESIGN

LECTURE 5_CHAPTER 6
SYSTEMS ANALYSIS: STRUCTURING SYSTEM REQUIREMENTS
PROCESS MODELING
DR. HUSAM KAID
Copyright © 2015 Pearson Education, Inc. Publishing as Prentice Hall
1
 Lesson Overview
▪ Here, our focus is on the systems analysis part
of the SDLC, which is highlighted in the
following Figure.
▪ We focus on methods useful for structuring
requirements :
✓process modeling
✓and logic modeling,
▪ These methods allow you to model how data
flow through an information system, the
relationships among the data flows, and how
data come to be stored at specific locations.
▪ These methods also show the processes that
change or transform data. 2
 Process Modeling
▪ Process modeling graphically represents the Enable analysts to
processes that capture, manipulate, store, and understand current system
distribute data between a system and its Scope of system
environment and among components within a
system.
▪ The data-flow diagram (DFD) is the type of
process model. During requirements
determination, information is collected about
the current and new systems.
▪ The project team will structure this
information into meaningful representations of
the current and new systems.
▪ The requirements structuring process results Show data flows, structure and
functional requirements of new system
in several deliverables, listed in Table 6–1 3
 Data-Flow Diagramming Mechanics (continued)

▪ Data Store ▪ A data flow represents data

• Depicts data at rest that are in motion and moving
• May represent data in as a unit.
✓File folder ▪ A data flow is represented by
✓Computer-based file an arrow on the data-flow
✓Notebook diagram.
• Drawn as a rectangle ▪ Select a meaningful name to
with the right vertical represent the data
line missing
• Label includes name of
the store as well as the
number
 Data-Flow Diagramming Mechanics (continued)

▪ Process ▪ Source/Sink
✓Depicts work or actions ✓Depicts the origin and/or
performed on data so destination of the data
that they are ✓Sometimes referred to as
transformed, stored, or an external entity
distributed ✓Drawn as a square symbol
✓Drawn as a rectangle ✓Name states what the
with rounded corners external agent is
✓Number of process as ✓Suppliers, customers, and
well as names are a bank are examples
recorded
 Data-Flow Diagramming Mechanics (continued)
▪ Figure 6–4 contrasts an incorrectly drawn
DFD (a process is shown as a sink) with
one that is correctly prepared.
 Data-Flow Diagramming Definitions
▪ Context Diagram
✓A data-flow diagram 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 that represents a system’s major processes, data
flows, and data stores at a higher level
 Developing DFDs: An Example

▪ The Hoosier Burger’s Automated Food

Ordering System case illustrates the DFD
development process.

▪ The boundary or scope of Hoosier

Burger’s food-ordering system is
represented by a context diagram; this
diagram, illustrated in Figure 6–5, also
shows the system’s interactions with its
environment.

▪ The context diagram contains only one

process labeled “0” and no data stores.
 Developing DFDs: An Example (continued)

▪ Next step is to expand the context

diagram to show the breakdown of
processes, a level-0 diagram is
drawn

▪ The food-ordering system’s level-0

diagram is shown in Figure 6–6.

▪ The level-0 diagram represents a

system’s major processes, data
flows, and data stores at a high level
of detail.
 Data-Flow Diagramming Rules

▪ Basic rules that apply to all DFDs:

Data-Flow Diagramming Rules (continued)
Data-Flow Diagramming Rules (continued)
Data-Flow Diagramming Rules (continued)
 Decomposition of DFDs
▪ The context diagram is functionally
decomposed into finer and finer detail,
resulting in the preparation of several
levels of diagrams.
▪ A level-n diagram is a DFD that is the
result of n nested decompositions of a
series of subprocesses from a process on a
level-0 diagram.
▪ Functional decomposition will continue
until a subprocess cannot be exploded into
more detail.
▪ Primitive DFDs are the lowest level
DFDs.
▪ Figure 6–6 shows a level 0 diagram for
Hoosier Burger food-ordering system.
 Decomposition of DFDs (continued)
▪ The level-1 diagram
appearing in Figure 6–8
is a decomposition of
Process 1.0 on the level-
0 diagram.
 Decomposition of DFDs (continued)
▪ Figure 6–9 shows the
decomposition of
process 4.0 from the
Level-0 diagram for
Hoosier Burger’s food
ordering system.
 Decomposition of DFDs (continued)
▪ Figure 6–10 shows the
decomposition of
process 4.3 from the
Level-1 diagram for
Hoosier Burger’s food
ordering system.
 Balancing DFDs
▪ When decomposing a DFD, you must conserve
inputs to and outputs from a process at the next
level of decomposition
o This is called balancing
▪ Example: Hoosier Burgers
o In Figure 6-5, notice that there is one input to
the system; the customer order
o Three outputs:
✓Customer receipt
✓Food order
✓Management reports
 Balancing DFDs (continued)
▪ Example (Continued)
o Notice Figure 6-6. We have the
same inputs and outputs
o No new inputs or outputs have
been introduced
o We can say that the context
diagram and level-0 DFD are
balanced
Balancing DFDs: An Unbalanced Example
▪ 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
Balancing DFDs
▪ We can split a data flow into
separate data flows on a lower
level diagram
 Guidelines for Drawing DFDs
1. Completeness
✓DFD must include all components necessary for the system
✓Each component must be fully described in the project dictionary
2. Consistency
✓The extent to which information contained on one level of a set of nested DFDs is also included on
other levels
3. Timing
✓Time is not represented well on DFDs
✓Best to draw DFDs as if the system has never started and will never stop
4. Iterative Development
✓Analyst should expect to redraw diagram several times before reaching the closest approximation to
the system being modeled
5. Primitive DFDs
✓Lowest logical level of decomposition
✓Decision has to be made when to stop decomposition
 Logic Modeling
▪ Because data-flow diagrams do not show the
inner workings of processes, logic models are
useful for showing this internal logic.
▪ Decision tables are a popular method for
modeling system logic.
▪ Best used for complicated decision logic
▪ A decision table consists of three parts:
✓Condition stubs: Lists condition relevant to
decision
✓Action stubs: Actions that result for a given
set of conditions
✓Rules: Specify which actions are to be This figure was uploaded by Felix Loesch

followed for a given set of conditions

▪ Indifferent Condition
✓Condition whose value does not affect which
action is taken for two or more rules
Logic Modeling
▪ Standard procedure for creating decision
tables:
1) Name the conditions and values each
condition can assume
2) Name all possible actions that can occur
3) List all possible rules
4) Define the actions for each
5) Simplify the decision table
▪ The complex decision table in Figure 6-15
models the logic of a generic payroll system.
o Employee type has two values: “S,”
which stands for salaried, and “H,” which
stands for hourly.
▪ Because of the indifferent condition for rules 1,
3, and 5, we can reduce the number of rules by
condensing rules 1, 3, and 5 into one rule, as
shown in Figure 6-16.
Logic Modeling
Logic Modeling
▪ Figure 6–17 shows a decision table for the
Hoosier Burger’s inventory reordering system;
Figure 6–18 shows the simplified table.
Case study -Pine Valley Furniture WebStore: Process Modeling
▪ The authors use Pine
Valley’s WebStore to
illustrate process modeling
for an electronic commerce
application.
▪ This example shows that
process modeling for
electronic commerce
applications is the same as
for more traditional
application development
projects.
▪ Table 6–4 outlines the
WebStore’s system
structure and corresponding
Level-0 processes.
Pine Valley Furniture WebStore:
Process Modeling
▪ Figure 6–19 is a Level-0
DFD for the WebStore.
Pine Valley Furniture WebStore:
Process Modeling
Questions?

30