Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 50

The Traditional Approach

to Requirements
Online Chapter B (Chapter 6, 5th ed.)

Systems Analysis and Design


in a Changing World 6th Ed

Satzinger, Jackson & Burd


Online Chapter B Outline
 Traditional and Object-Oriented Views of
Activities and Use Cases
 Data Flow Diagrams
 Documentation of DFD Components

Systems Analysis and Design in a Changing World, 6th Edition 2


Learning Objectives
 Explain how the traditional approach and the object-
oriented approach differ when modeling the details of
a use case
 List the components of a traditional system and the
symbols representing them on a data flow diagram
 Describe how data flow diagrams can show the
system at various levels of abstraction
 Develop data flow diagrams, data element definitions,
data store definitions, and process descriptions

Systems Analysis and Design in a Changing World, 6th Edition 3


Overview
 Chapters 3, 4, and 5 described two key concepts
associated with modeling functional requirements
in the newer (OO) approaches to information
systems development: the use cases and the
domain classes involved in users’ work

 This chapter describes an older and more


traditional approach to representing requirements

Systems Analysis and Design in a Changing World, 6th Edition 4


Traditional vs. OO Approach

Fig 6-1 Traditional versus OO approaches

Systems Analysis and Design in a Changing World, 6th Edition 5


Requirements Models for
Traditional vs. OO Approach

Fig 6-2 Requirements models for the traditional and OO approaches


Systems Analysis and Design in a Changing World, 6th Edition 6
Data Flow Diagrams
 A diagram that represents system
requirements as processes, external agents,
data flows and data stores.
 Easy to read and learn with minimal training.
 Symbols used:
 External agent
 Process
 Data flow
 Data store
Systems Analysis and Design in a Changing World, 6th Edition 7
Data Flow
Diagram
Symbols
(Gane and
Sarson’s
version)

Fig 6-3 Data flow diagram


symbols

Systems Analysis and Design in a Changing World, 6th Edition 8


DFD Symbols (Yourdon’s version)
Entity

 Also known as external


sources/destination
 Can be a person, a department, a
machine, or another system
 Provider of data or receiver of information
 Outside scope of study
 Labeling is always a noun
Systems Analysis and Design in a Changing World, 6th Edition 9
DFD Symbols (Yourdon’s version)
Data Flow

 A directed line showing the flow of


information or objects
 Can be curved as well
 The arrow indicates direction of the data
movement
 Labelling is commonly a noun with an
adjective
 Each data flows labeling must be unique
Systems Analysis and Design in a Changing World, 6th Edition 10
DFD Symbols (Yourdon’s version)
Process

 Also known as a bubble


 Denotes a change in or transformation of
input data flows into output data flows
 Labeling uses action verbs e.g. update,
prepare, etc.

Systems Analysis and Design in a Changing World, 6th Edition 11


DFD Symbols (Yourdon’s version)
Input Output
1.1
Process

 All processes must have at least one input


data flow and one output data flow
 All processes should be numbered

Systems Analysis and Design in a Changing World, 6th Edition 12


DFD Symbols (Yourdon’s version)

Data Store

 A depository of data for future retrieval and


updating
 Labelling is always a noun
 DFDs do not show the physical storage
medium

Systems Analysis and Design in a Changing World, 6th Edition 13


DFD Symbols (Yourdon’s version) –
other conventions
Entity

Data Store *

 All data flows must be labeled, except


flows going in or out of data stores
 Use a slash in the right-bottom corner of
an external entity to indicate a duplicate
entity
 Use an asterisk in the right corner of a
data store to indicate a duplicate data
store 14
Systems Analysis and Design in a Changing World, 6th Edition
DFD Symbols (Yourdon’s version) – other
conventions
 Can have bi-directional arrow.
Update
General
Receiv-
Ledger
ables

 If two data elements flow together, then the use


of one data flow line is appropriate.

Cash Rec’d & Remittance Slip


Process
Customer
Payment

Copyright © 2012 3-15


Pearson
Education
DFD Symbols (Yourdon’s version) -
other conventions

 Use a "hoop" to illustrate that data flow


lines cross but do not intersect
 Usage is however discouraged as
crossings clutter the diagram

Systems Analysis and Design in a Changing World, 6th Edition 16


DFD Don’ts
Library card
Member Librarian

 No data flow is to be linked between external entities

New book catalogue


Librarian

Books Catalogue File

 No data flow is to be linked between an external entity


and a data store
Systems Analysis and Design in a Changing World, 6th Edition 17
DFD Don’ts

Members Backup File

Duplicated Members Master File


records

 No data flow is to be linked between data stores

Systems Analysis and Design in a Changing World, 6th Edition 18


DFD Don’ts
Overdue
Members Master File member
details 4.1
Print overdue
Get next
reminder
member
letter
Overdue
reminder letter

 No control information (i.e. Get next member data


flow) should be reflected

Systems Analysis and Design in a Changing World, 6th Edition 19


DFD Labeling
 Data flows that you are unable to name
tend to be either your misconception of the
system or the partitioning was poor
 Avoid vague labeling like "data" and
"information"
 Do not group disparate items together into
one data flow when they have no business
being treated as a whole

Systems Analysis and Design in a Changing World, 6th Edition 20


Summary of correspondences
 DFD integrates processing triggered by events with data
entities modeled using the ERD

Fig 6-5 The DFD integrates events and the ERD

Systems Analysis and Design in a Changing World, 6th Edition 21


DFDs and Levels of Abstraction
 Level of abstraction
 Any modeling technique that breaks the system
into a hierarchical set of increasingly more
detailed models
 DFDs can show either higher-level (general view
of the system) or lower-level (more detailed view
of one process) views of the system
 Higher-level => Context diagram
 Lower-level => Diagram 0, 1, 2, etc.

Systems Analysis and Design in a Changing World, 6th Edition 22


DFD
Decomposes

To show different
levels of
abstraction

Context Diagram
Diagram 0
Diagram 1

Fig 6-6 Layers of DFD abstraction


for a course registration system

Systems Analysis and Design in a Changing World, 6th Edition 23


Context Diagram
 Summarizes all processing activity within the system in a
single symbol
 Show inputs and outputs into a system
 Characteristics: one process symbol only, no data
stores, sources of its input, destinations of its output
 Each trigger for external event becomes input data flow;
source becomes an external agent
 Each response becomes output data flow; destination
becomes an external agent
 Triggers for temporal events are NOT data flows => no
input data flows
Systems Analysis and Design in a Changing World, 6th Edition 24
Context Diagram
 Steps to prepare context diagram:
 Identify the system of interest. Draw a bubble and
label it to represent the system of interest.
 Identify the external agents. Draw and label a
rectangle for each external agent.
 Identify any data flows between the external agents
and the system of interest.
 Draw in the data flows connecting the external agents
and system of interest and label them accordingly.

Systems Analysis and Design in a Changing World, 6th Edition 25


Context Diagram
 General rule to determine external agent:
 An agent merely send and receive items to/from the
system and do not process them in anyway.
 If the agent actually involves in the processing
activities in the system, then it will not appear in the
context diagram.

Systems Analysis and Design in a Changing World, 6th Edition 26


DFD Fragments
 Represents the system response to one
event within a single process symbol
 Created for each use case triggered by an
event
 Each fragment shows only those data stores
that are needed to respond to the event

Systems Analysis and Design in a Changing World, 6th Edition 27


DFD Fragments
One for each use case

Fig 6-7 Three DFD fragments for the course registration system

Systems Analysis and Design in a Changing World, 6th Edition 28


Event-Partitioned System Model
 Also known as diagram 0
 Combines all of the DFD fragments for a
system or subsystem into a single DFD
 Show all major activity steps of a system
 Characteristics: processes are labeled 1.0
(1), 2.0 (2), 3.0 (3), etc.

Systems Analysis and Design in a Changing World, 6th Edition 29


Combine
DFD
Fragments

To Create
Diagram 0

Fig 6-8 Combining DFD fragments


to create the event-partitioned
system model for the course
registration system

Systems Analysis and Design in a Changing World, 6th Edition 30


Drawing DFD Guidelines
 Define the scope of the system
 Work your way from inputs to outputs,
backwards from outputs to inputs, or from the
middle out
 Label all the interface data flows concisely and
meaningfully
 Data flows that always flow together should be
grouped together; those that do not flow
together should be shown on separate lines
Systems Analysis and Design in a Changing World, 6th Edition 31
Drawing DFD Guidelines
 Label the bubbles in terms of their inputs and
outputs
 Ignore control processes and control actions
(e.g. error corrections)
 Be prepared to start over

Systems Analysis and Design in a Changing World, 6th Edition 32


Physical and Logical DFDs
 Physical DFD
 An implementation-dependent view of the current
system, showing what tasks are carried out and how
they are perform
 Physical characteristics include:
 Names of people
 Form and document names or numbers
 Names of departments
 Master and transaction files
 Equipment and devices used
 Locations
 Names of procedures
Systems Analysis and Design in a Changing World, 6th Edition 33
Physical
DFDs

Sometimes
useful for
modeling
processes

Fig 6-15 Physical DFD for


scheduling courses

Systems Analysis and Design in a Changing World, 6th Edition 34


Physical and Logical DFDs
 Logical DFD
 An implementation-independent view of a system,
focusing on the flow of data between processes
without regard for the specific devices, storage
locations, or people in the system.
 Will not specify the physical characteristics listed
above for physical data flow diagrams

Systems Analysis and Design in a Changing World, 6th Edition 35


Evaluating DFD Quality
 Ensuring Data Flow Consistency
 Balancing – equivalence of data content between data
flows entering and leaving a process and data flows
entering and leaving a process decomposition DFD

Systems Analysis and Design in a Changing World, 6th Edition 36


Documentation of DFD Components

 Additional details about each component needs to be


described:
 Process
 Data flow
 Data stores
 Data elements

Systems Analysis and Design in a Changing World, 6th Edition 37


Documentation of DFD Components –
Process descriptions
 Each process on DFD must be defined formally =>
process decomposition
 Eventually, a point is reached at which a process does
not need to be defined further
 Described with other methods
 structured English,
 decision tables, or
 decision trees

Systems Analysis and Design in a Changing World, 6th Edition 38


Documentation of DFD Components –
Process descriptions
 Structured English
 A method of writing process specifications that combines
structured programming techniques with narrative English
 Well suited to describe processes with many sequential
processing step and relatively simple control logic (e.g. single
loop or an if-then-else statement
 Not suitable for:
 Complex decision logic
 Few (or no) sequential processing steps

Systems Analysis and Design in a Changing World, 6th Edition 39


Structured English Example

Fig 6-20 A structured English example

Systems Analysis and Design in a Changing World, 6th Edition 40


Documentation of DFD Components
 Decision table
 A tabular representation of processing logic containing
decision variables, decision variable values, and actions or
formulas

Fig 6-23 A decision table for calculating shipping charges

Systems Analysis and Design in a Changing World, 6th Edition 41


Documentation of DFD Components
 Decision tree
 A graphical description of process logic that uses lines
organized like branches of a tree

Fig 6-24 A decision tree for calculating shipping charges

Systems Analysis and Design in a Changing World, 6th Edition 42


Documentation of DFD Components – Data
Flow Definitions
 A textual description of a data flow’s content and
internal structure
 Can be simple list of data elements that make up the
data flow. For new order:

Fig 6-26 Data flow definitions simply using elements

 Can use an algebraic notation to indicate elements and


structure

Fig 6-27 Algebraic notation for data flow definition

Systems Analysis and Design in a Changing World, 6th Edition 43


Data Flow Definitions

Fig 6-29 A data flow definition example

Systems Analysis and Design in a Changing World, 6th Edition 44


Documentation of DFD
Components – Data Stores
 Data store on the DFD = data entity on the
ERD
 No separate definition is needed

 If data stores are not linked to an ERD


 Define data store as a collection of elements (the
same way as data flows are defined)

Systems Analysis and Design in a Changing World, 6th Edition 45


Documentation of DFD Components –
Data element definitions
 Describe a data type, such as string, integer, floating
point, or Boolean
 Each element should also be defined to indicate
specifically what it represents and how it is validated

Systems Analysis and Design in a Changing World, 6th Edition 46


Data Element Definitions

Fig 6-30 Data element definitions

Systems Analysis and Design in a Changing World, 6th Edition 47


Data Dictionary
 Data dictionary
 A repository for definitions of data flows, data
elements, and data stores
 Used to ensure consistency

Systems Analysis and Design in a Changing World, 6th Edition 48


Summary
 Data flow diagrams (DFDs) are used in combination
with the use cases and entity-relationship diagram
(ERD) to model system requirements
 DFDs model a system as a set of processes, data
flows, external agents, and data stores
 Many types of DFDs are developed, including context
diagrams, DFD fragments, subsystem DFDs, diagram
0, and process decomposition DFDs
 Each process, data flow, and data store requires a
detailed definition

Systems Analysis and Design in a Changing World, 6th Edition 49


Summary (continued)
 Analysts may define processes in a number of ways,
including a structured English process specification, a
decision table, a decision tree, or a process
decomposition DFD
 Data flows are defined in terms of their component
data elements and their internal structure.
 Data stores correspond to entities on the ERD and
thus require no additional definition
 Data elements may be further defined in terms of their
type and allowable content

Systems Analysis and Design in a Changing World, 6th Edition 50

You might also like