“Systems Analysis and Design, I”

LECTURE 6:
Traditional Approach to Requirements

1
Lecture Outline

Traditional Approach vs. OOA

Data Flow Diagrams (DFDs)
DFD and Levels of Abstraction
Context Diagrams
DFD Fragments
Physical and Logical DFDs
Evaluating DFD Quality
Documentation of DFD Components
Locations and Communication
Through Networks
2
Traditional Approach vs. OOA

Two approaches differ in the way the system is modeled and

implemented:
• Traditional approach:
– views a system as a collection of processes (like computer
programs, a set of instructions that execute in sequence)
– when the process executes it interacts with data (reads data
values and then writes data values back to the data file
– emphasizes processes, data, inputs/outputs
• Object Oriented approach (OO):
– views a system as a collection of interacting objects which are
capable of their own behavior (called methods) which allow the
objects to interact with each other and with people using the
system
– there are NO conventional processes and data files per se, just
interacting objects

3
Traditional Approach vs. OO
Approach

4
Requirements for the Traditional
and OO Approaches

5
Data Flow Diagrams (DFDs)

 Graphical system model that shows all main requirements

for an IS in one diagram

Inputs/outputs

Processes

Data storage

 Easy to read and understand with minimal training (only 5

symbols used)

 DFD integrates processing triggered by events (event

table) with the data entities modeled by ERD
6
DFD Symbols

 The square is an external agent (a person or

organization, outside the boundary of a system that
provides data inputs or accepts data outputs)
 The rectangle with rounded corners is a process (named
“Look up item available” and can be referred to by its
number, 1)
 A process defines rules (algorithms or procedures) for
transforming inputs into outputs
 The lines with arrows are data flows (represents
movement of data). Slide shows two data flows between
Customer and process 1: a process input “Item inquiry”
and process output named “Item availability details”
 The flat three-sided rectangle is a data store (a file or
part of a database that stores information about data
entity)

7
Data
Flow
Diagram
Symbols

8
DFD Fragment Showing Use Case
Look Up Item Availability from the
RMO

9
DFD Integrates Event Table and
ERD

10
DFD and Levels of Abstraction

 DFD is a modeling technique that breaks the system into a hierarchical set
of increasingly more detailed models

 DFD may reflect the processing at either a higher level (more general view of
the system) or at lower level (a more detailed view of one process)

 These different views of the system (higher level versus low level) creates
the levels of abstraction

 DFDs are decomposed into additional diagrams to provide multiple levels of

detail

 Higher-level diagrams provide general views of system

 Lower-level diagrams provide detailed views of system 11

Layers of DFD
Abstraction
for Course
Registration
System

12
Context Diagrams

 DFD that summarizes all processing

activity for the system or subsystem
 Highest level (most abstract) view of
system
 Shows system boundaries
 System scope is represented by a single
process, external agents, and all data flows
into and out of the system
13
Context Diagrams for a Course
Registration System

14
Notes on Context Diagrams

• Useful for showing system boundaries

(represents the system scope within the single
process plus external agents)
• External agents that supply or receive data from
the system are outside the system scope
• Data stores are not usually shown in the context
diagram since they are considered to be within the
system scope
• It is the highest level of DFD
• Context diagram does not show any details of what
takes place within the system
15
Context Diagrams for RMO CSS

16
DFD Fragments

 Created for each use case in the event table

 Represent system response to one event within a

single process symbol

 Self-contained models

 Focus attention on single part of system

 Show only data stores required in the use case

17
Three Separate DFD Fragments
for Course Registration System

18
Event-Partitioned System Model

 DFD to model system requirements using single process for each

use case/activity in system or subsystem

 Combines all DFD fragments together to show decomposition of the

context-level diagram

 Shows the entire system on a single DFD (in greater detail

than on the context diagram)

 Sometimes called “diagram 0”

 Used primarily as a presentation tool

 Decomposed into more detailed DFD fragments

19
Combining
DFD
Fragments to
Create
Event-
Partitioned
System
Model

20
Layers of
DFD
Abstraction

21
RMO Subsystems and Use
Cases/Activities from Event Table

22
Context Diagram for RMO
Order-Entry Subsystem

23
Five Separate DFD Fragments for
RMO Order-Entry Subsystem

24
The event-
partitioned
model of the
Order-Entry
subsystem
(diagram 0)

25
Decomposing DFD Fragments

 Most DFD fragments can be further described

using structured English
 Sometimes DFD fragments need to be
diagrammed in more detail
 Decomposed into subprocesses in a detailed DFD
 DFD numbering scheme
 Hierarchical decomposition

• DFD Fragment 2 is decomposed into Diagram 2

• Diagram 2 has processes 2.1, 2.2, 2.3, 2.4 –four steps to

complete the activity 26
Detailed DFD
for Create
new order
DFD fragment

27
Hierarchy of the DFDs

• The top most - context diagram (entire system as

one process), which breaks down to the subsystem
diagram (one process per subsystem)
• The subsystem diagram is, in turn, decomposed
into a set of the event-partitioned subsystem
diagrams
• There is no single diagram 0. Instead, there is an
event-partitioned DFD for each of the subsystems
• Each event-partitioned DFD is a diagram 0 for a
single subsystem
28
Hierarchy of the DFDs

29
FIGURE 6-20 Incorrect and correct
way to draw DFD. 30
Physical and Logical DFDs

 Logical model

 Assumes implementation in perfect technology

 Does not tell how system is implemented

 Physical model

 Describes assumptions about implementation technology

 Developed in last stages of analysis or in early design

 E.g., the technology assumption is embedded in the name of

process 1.1 “Making copies for department chairs” – it is a
manual task, which implies that the data store “Old schedule”
and the data flows into and out of process 1.1 are papers, etc. 31
Physical
DFD for
Scheduling
Courses

32
Evaluating DFD Quality

 Readable
 Internally consistent and balanced
 Accurately represents system requirements
 Reduces information overload – rule of 7
+/- 2
 Single DFD should not have more than 7 +/-2
processes
 No more than 7 +/- 2 data flows should enter or
leave a process or data store in a single DFD
 Minimizes required number of interfaces
33
Data Flow Consistency Problems

 Differences in data flow content between a

process and its decomposition

 Data outflows without corresponding

inflows

 Data inflows without corresponding

outflows

 Results in unbalanced DFDs

34
Black Hole and Miracle
black hole, i.e. a process with a data input that is
never used to produce a data input. The following
rules help to avoid the black holes:
- All data that flow into a process must flow out
of the process or be used to generated data that
flow out of the process
- All data that flow out of a process must have
flowed into the process or have been generated
from data that flowed into the process
Miracle - a process with a data output that is
created out of nothing ( “miraculously appears”)

35
Unnecessary Data Input: Black
Hole

36
Process with Impossible Data
Output: a Miracle

37
Process with Unnecessary Data
Input

38
Process with Impossible Data
Output

39
Documentation of DFD
Components

 DFDs show three types of internal system component:

processes, data flows and data stores

 The details of each component need to be described

 Lowest-level processes need to be described in detail

 Data flow contents need to be described

 Data stores need to be described in terms of data elements

 Each data element needs to be described

40
Process Descriptions

• Each process on a DFD must be formally defined

• There are several options for process definition including
decomposition. In a process of decomposition, a higher-
level process is formally defined by a DFD that contains
lover-level processes, which, in turn, may be further
decomposed into even lower-level DFDs. Eventually a point
will be reached when a process becomes so simple that it
can adequately be described by another process
description method, i.e. without next lower-level DFD.
• These description methods include:
- Structured English
- Decision tables
- Decision trees
• These models describe the process as an algorithm.
41
Structured English

 Method of writing process specifications

 Combines structured programming techniques

with narrative English

 Well-suited for lengthy sequential processes or

simple control logic (single loop or if-then-else)

 Ill-suited for complex decision logic or few (or no)

sequential processing steps

42
Structured English Example

43
Process 2.1 and Structured
English Process Description

44
A structured English
process description for
calculating shipping
charges

45
Decision Tables and Decision Trees
 Can summarize complex decision
logic better than structured English
 Incorporate logic into the table or
tree structure to make descriptions
more readable

46
Decision Table for Calculating
Shipping Charges

47
Decision Tree for Calculating
Shipping Charges

48
A Decision Table with Multiple Action
Rows

49
Data Flow Definitions
 Data flow is a collection of data elements
 Data flow definition is a textual description of data
flow’s content and internal structure
 Lists all the elements, e.g. a “New Order” data flow
consists of Customer–Name, Customer-Address, Credit-
Card-Information, Item-Number and Quantity
 Often coincide with attributes of data entities included in
ERD plus computed values
 Algebraic notion is alternative to the list
 Describes data elements on data flow plus data structure

50
List and Algebraic Notation for
Data Flow Definition

51
RMO Products
and Items
Report

52
Data Flow Definition for RMO
Products and Items Control Break
Report

53
Data Element Definitions

 Data type description

 String, integer, floating point, Boolean

 Sometimes very specific written description e.g., special codes

(e.g. code A means ship immediately, code B – hold for one day
and code C – hold shipment pending confirmation)

 Length of element (usually for strings)

 Maximum and minimum values (for numeric values)

 Data dictionary – repository for definitions of data flows,

data stores, and data elements
54
Data Element Definition Examples

55
Data Store Definitions
 A data store on the DFD represents
a data entity on the ERD (so, no
separate definition is needed, just a
note referring to the ERD for details)
 If a data store are not linked to an
ERD, a definition is provided as a
collection of elements (like did for
data flows)
56
Components of a Traditional
Analysis Model
 Four components of a traditional analysis model are
– Data flow diagrams
– Entity-relationship diagram
– Process definitions
– Data definitions
 They form an interlocking set of specifications for
system requirements
 DFD shows highest-level view of the system
 Other components describe some aspect of DFD
 These models were created in the 1970’s and
1980’s as a part of the structured analysis
methodology

57
Components of a Traditional
Analysis Model

58
Locations and Communication
Through Networks
 Physical information needed during analysis
 Number of user locations
 Processing and data access requirements at
various locations
 Volume and timing of processing and data
access requests
 Needed to make initial design decisions
such as
 Distribution of computer systems, application
software, database components, network
capacity
59
Gathering Location Information

 Identify locations where work is to be performed

 Draw location diagram – a map that identifies all of the
processing locations of a system (business offices, warehouses,
manufacturing facilities)
 List functions performed by users at each location
 Build activity-location matrix - a table that describes the
relationship between processes and the locations where they are
performed
Rows are system activities from event table
Columns are physical locations
 Build activity-data (CRUD) matrixis a table that describes stored
data entities, the locations from which they are accessed and the
nature of the access (i.e. which activities require access to the
data). Source of this information is:
- the DFD fragments (traditional approach) and
- sequence diagrams (OO approach)
CRUD – create, read, update, and delete 60
RMO Location
diagram

61
RMO Activity-Location Matrix

62
RMO Activity-Data Matrix (CRUD)

63
 Readings

Today’s lecture: Chapter 6 – “The Traditional

Approach to Requirements”

!!!
u
For next lecture: Chapter 7 – “The Object-
yo
Oriented Approach to Requirements”
nk
a
Th

64