◼ 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