◼ Requirements Modeling
1
Requirements Modeling Strategies
◼ One view of requirements modeling, called structured
analysis, considers data and the processes that transform
the data as separate entities.
◼ Data objects are modeled in a way that defines their
attributes and relationships.
◼ Processes that manipulate data objects are modeled in a
manner that shows how they transform data as data
objects flow through the system.
◼ A second approach to analysis modeled, called object-
oriented analysis, focuses on
◼ the definition of classes and
◼ the manner in which they collaborate with one another to
effect customer requirements.
2
Flow-Oriented Modeling
◼ Represents how data objects are transformed at they
move through the system
◼ data flow diagram (DFD) is the diagrammatic form that
is used
◼ Considered by many to be an “old school” approach, but
continues to provide a view of the system that is
unique—it should be used to supplement other analysis
model elements
3
The Flow Model
Every computer-based system is an
information transform ....
computer
input based output
system
4
Flow Modeling Notation
external entity
process
data flow
data store
5
External Entity
A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based
system
Data must always originate somewhere
and must always be sent to something
6
Process
A data transformer (changes input
to output)
Examples: compute taxes, determine area,
format report, display graph
Data must always be processed in some
way to achieve system function
7
Data Flow
Data flows through a system, beginning
as input and transformed into output.
base
compute
triangle area
height area
8
Data Stores
Data is often stored for later use.
sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number
sensor data
9
Data Flow Diagramming: Guidelines
◼ all icons must be labeled with meaningful
names
◼ the DFD evolves through a number of levels
of detail
◼ always begin with a context level diagram
(also called level 0)
◼ always show external entities at level 0
◼ always label data flow arrows
◼ do not represent procedural logic
10
Constructing a DFD—I
◼ review user scenarios and/or the data
model to isolate data objects and use a
grammatical parse to determine
“operations”
◼ determine external entities (producers
and consumers of data)
◼ create a level 0 DFD
11
Level 0 DFD Example
processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal
12
Constructing a DFD—II
◼ write a narrative describing the transform
◼ parse to determine next level transforms
◼ “balance” the flow to maintain data flow
continuity
◼ develop a level 1 DFD
◼ use a 1:5 (approx.) expansion ratio
13
The Data Flow Hierarchy
a b
x P y level 0
a c p2
p1
f
p4 b
d 5
p3 e g
level 1
14
Flow Modeling Notes
◼ each bubble is refined until it does just
one thing
◼ the expansion ratio decreases as the
number of levels increase
◼ most systems require between 3 and 7
levels for an adequate flow model
◼ a single data flow item (arrow) may be
expanded as levels increase (data
dictionary provides information)
15
DFDs: A Look Ahead
analysis model
Maps into
design model
16
Patterns for Requirements Modeling
◼ Software patterns are a mechanism for capturing domain
knowledge in a way that allows it to be reapplied when
a new problem is encountered
◼ domain knowledge can be applied to a new problem
within the same application domain
◼ the domain knowledge captured by a pattern can be
applied by analogy to a completely different application
domain.
◼ The original author of an analysis pattern does not
“create” the pattern, but rather, discovers it as
requirements engineering work is being conducted.
◼ Once the pattern has been discovered, it is documented
17
