0% found this document useful (0 votes)
29 views

Chapter 7 - Req Modeling (DFD)

Uploaded by

XXX XXX
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views

Chapter 7 - Req Modeling (DFD)

Uploaded by

XXX XXX
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Chapter 7

● Requirements Modeling: Flow, Behavior,


Patterns, and WebApps
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only


May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
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.

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
The Flow Model
Every computer-based system is an
information transform ....

compute
input r outpu
based
system t

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
What is a Data Flow Diagram?
● A data flow diagram (DFD) is a graphical
tool that allows system analysts (and
system users) to depict the flow of data in
an information system.

● The DFD is one of the methods that


system analysts use to collect information
necessary to determine information
system requirements.
Why Data Flow Diagram?
A Data Flow Diagram is intended to
serve as a communication tool
among:
● systems analysts
● end users
● database designers
● system programmers
● other members of the project team
DFD Symbols and Definitions
• Process - performs some action on
data, such as creates, modifies,
Proce
stores, delete, etc. Can be manual
ss or supported by computer.

• Data store - information that is


Data
kept and accessed. May be in
store paper file folder or a database.

Externa • External entity - is the origin or


l destination of data. Entities are
Entity external to the system.
Data • Data flow - the flow of data into or
flow out of a process, datastore or entity
Rules for Drawing DFD’s
A minimum of one data flow
in and one data flow out of
a process
A datastore must
be
connected to a
process
(either in, out,
An external or
entity
both)
must
be connected to a
process
A singlein,
(either data
out,flow
or both)
must
only flow one way
DFD: Common Mistakes
• Process has no data flowing
into it, but has data flowing
out.

• Data store is hooked to


external entity. This means
external entity can read and
write to your data file
without auditing!!

• The data flow goes in two


directions at once. Two or
more arrows should be used
to show the flow to and
from each process.
External Entity
A producer (Source) or consumer (Sink) of data

Examples: a person, a device, a sensor

Data must always originate somewhere


and must always be sent to something

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Process
A data transformer (changes input to output)

Examples: compute taxes, determine area,


format report, display graph

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Types of Diagrams
● Context Diagram
● A data flow diagram (DFD) 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-0 Diagram
● A data flow diagram (DFD) that represents
a system’s major processes, data flows
and data stores at a high level of detail
Example
Context diagram for Food ordering system
Example – Cont.
Level-0 DFD for food ordering system
The Data Flow Hierarchy
a b
x P y level 0

c p2
a f
p1

p4 b
d 5
p3 e g
level 1

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
DFD: Numbering Levels
In a DFD with many levels it’s easy to forget which
level you are on. That’s why each level has different
numbering for the processes on the diagram. The
‘level’ corresponds to the number of decimal places
required to define a process in it. Here’s how it
works:
● Context Diagram Process labeled “0”
● Level 0 Processes labeled 1.0, 2.0, 3.0, .
● Level 1 Processes labeled 1.1, 1.2, 1.3, .
● Level 2 Processes labeled 1.11, 1.12,...
DFDs: A Look Ahead

analysis model

Maps into
design model

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0
Writing the Software Specification

Everyone knew exactly


what had to be done
until someone wrote it
down!

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman. 0

You might also like