SE-565 Software System Requirements IX. Data Flow Diagrams

1
SE-565Software System RequirementsIX. Data
Flow Diagrams

• Dr. Jiacun Wang
• Department of Software Engineering
• Monmouth University

2
Topics

• Requirements engineering methods
• Structured techniques for documenting and
  analyzing requirements
• Data-Flow Diagrams
• Data Dictionaries

3
Role of methods in RE

• Process of requirements engineering (RE) is
  usually guided by a requirements method
• Requirement methods are systematic ways of
  producing system models
• System models are important bridges between the
  analysis and the design process

4
Necessary properties for a RE method

• Suitability for agreement with the end-user
  (using intuitive notation)
• The precision of definition of its notation
• Assistance with formulating requirements
• Definition of the world outside
• Scope for malleability
• Scope for integrating other approaches
• Scope for communication
• Tool support

5
No ideal RE method

• There is no ideal requirement method
• A number of methods use a variety of modelling
  techniques to formulate system requirements
• System models can be enriched by modelling
  different aspects of using modelling techniques

6
SA and OOA

• Structured analysis (SA)
• focus on functionality
• focus on data
• Object-oriented analysis (OOA)
• integrate data and functions

7
Data-Flow Modeling

• One of the most popular structured methods
• The Data-Flow Diagram (DFD) method (DeMarco,
  1979) provides a description of a system based on
  modeling
• the transformational processes of a system,
• the collections (stores) of data that the system
  manipulates, and
• the flows of data between the processes, stores
  and the outside world.
• The DFD describes the functional viewpoint of the
  system e.g. it describes the system in terms of
  its operation (tasks).

8
Data-Flow Modeling (cont.)

• This method works well for transaction-processing
  systems and other function-intensive
  applications.
• The DFD provides a way to represent the steps
  involved in a business process or the operations
  of a proposed software system.
• A DFD illustrates how the functional
  requirements in the SRS combine to let the user
  perform specific tasks.

9
The four basic elements of the DFD notation

• The circle (the bubble)
• It denotes an operation and is labeled with a
  brief description of the operation
• Transformation of data into other data
• Notation

3. Reserve seat
10

• The box or rectangle (terminator)
• It denotes external entities - source or sink of
  information outside the boundaries of the system
• The source/sink can be a human user or other
  system
• Notation

Customer
Source of information
11

• The paralleled bars or parallel lines
• It denotes a data store or file
• A place where data are held for later
  transformation or reference.
• Notation

12

• The arc (arrow)
• It denotes the flow of information between the
  other three elements - data flow
• Notation

13
The Data-Flow Diagram NotationSummary
Data Transformation
Terminator
Terminator
Input
Output
Data dictionary
14
Hierarchical/functional decomposition

• The DFD can present the system at different
  levels of details. (Hierarchical/functional
  decomposition)
• Context level
• Level 1
• Level 2
• .
• Level n

The decomposition continues until the lowest
level diagram contains only primitive process
operations that can be clearly represented in
narrative text, pseudocode, activity diagram,
etc.
details
15
Guidelines for building DFDs

• 1. All names should be unique.
• 2. Suppress logical decisions (no diamond shaped
  boxes!).
• 3. Dont become bogged down in details. Defer
  error conditions and error handling until the end
  of the analysis (not in the case of a diagnostic
  system or patient monitoring system, for ex.).
• 4. Preserve the number of inputs and outputs
  between the levels.
• 5. As bubbles are decomposed into less abstract
  bubbles, the corresponding data flows may also
  need to be decomposed.

16
Rules of decomposition
A top level process
I
I1
O
O3
A
A
I2
O
I1
O3
O1
O2
I1
I2
I
is decomposed into some number of lower level
processes
I2
17
Guidelines for building DFDs (cont.)

• 6. Place data stores only on the Level 1 and
  lower levels, not on the context diagram.
• 7. Name each process as a concise action verb
  object
• 8. Number the processes uniquely and
  hierarchically. On level 1 diagram number each
  process with an integer. If you create a child
  DFD for process 2, number the processes in that
  child diagram 2.1, 2.2, etc.
• 9. Dont show more than 10 processes on a single
  diagram because it becomes harder to understand
  and change. Instead, introduce another layer of
  abstraction by grouping related processes into a
  higher-level process.

18
Example Simple library system
The context - level DFD forIssue library item
Library card
Library user
Issue library item
Library assistant
Requested item
Return date
Issued item
19
Example Simple library system
Level 1 of the DFD for the Issue library item
User database
User details
Updated details
Library card
Update user details
Check user
Library user
User status
User ID
Item ID
Requested item
Check item
Item status
Return date
Library assistant
Issue item
Issued item
Item details
Item database
Update details
20
Example A Distribution SystemContext level data
flow diagram
Reply to be mailed
Discarded correspondence
21
Level 1 data flow diagram
Discarded Correspondence
Customer Correspondence
Response to Customer
Reply to be mailed
Order items
Supplier Response
Invoice
Recorded Customer Order
Mgmt-Queries
supplies
Dept-Queries
Order Copy
Reports to Depts
Mgmt-Reports
Correspondence with Supplier
22
Level 2 DFD Receiving correspondence
Customer Correspondence
Discarded Correspondence
Routed Correspondence
Read Evaluate Correspondence
Recorded Customer Order
1.2
Supplier Response
Correspondence Demanding Reply
Draft of Reply
Reply To Be Mailed
23
Class exercise

• Draw the context diagram, level 1 and one
  level 2 diagrams for modeling the processing of
  an ATM.

24
Data Dictionaries

• Repositories to store information about all data
  items or attributes used in the application.
• Typical information include
• Name of data item
• Aliases (other names for the item)
• Description/Purpose (meaning)
• Related data items (formulas)
• Range of values
• Data flows (generated_by/used_by)
• Data structure definition/form

25
Data Dictionaries Notation
Meta Symbol
Meaning

And (concatenation)
()
Optional

Iteration

..
..
..
Selection of one alternative

A literal string
26
Simple Book Order DFD
Customer
Customer database
Credit Status
Invoice
Order
Create Invoice
Verify Order is Valid
27
Data Dictionary for the Book Order DFD
28
Data Dictionaries (cont.)

• Integration problems are reduced if all
  developers respect the data dictionary
  definitions.
• The data dictionary complements the project
  glossary
• Begin collecting data definitions as you
  encounter them during the elicitation
• If you keep the data dictionary current, it will
  remain a valuable tool throughout the systems
  maintenance life

29
Class exercise Create a 5 item data dictionary
for this DFD
User database
User details
Update details
Library card
Library user
Update user details
Check user
User status
User ID
Item ID
Requested item
Check item
Item status
Return date
Issue item
Library assistant
Issued item
Item details
Update details
Item database