1. Chapter 6
The Traditional
Approach to
Requirements

2. Objectives
Explain how the traditional approach and the object-oriented approach differ when an event occurs
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

3. Objectives
Develop data flow diagrams, data element definitions, data store definitions, and process descriptions
Develop tables to show the distribution of processing and data access across system locations
Read and interpret additional models that can be incorporated within traditional structured analysis, including process decomposition and workflow diagrams

4. Overview
Investigate the structured approach for representing system activities and interactions
A variety of diagrams, models, and document system requirements when using the structured development approach
Provide examples from RMO customer support system

5. Traditional versus OO Approaches Figure 6-1

6. Data Flow Diagrams
Graphical system model that shows all main requirements for an IS
Inputs / outputs
Processes
Data storage
Easy to read and understand

7. Data Flow Diagram Symbols Figure 6-2
Process
Step-by-step instructions
Data flow
External agent
Data store
Data at rest
Real-time link

8. DFD Fragment from RMO Case Figure 6-3

9. DFD Integrates Event Table and ERD Figure 6-4

10. DFD and Levels of Abstraction
DFDs are decomposed into additional diagrams to provide multiple levels of detail
Higher levels are more general
Lower levels are more detailed

11. Context Diagrams DFD that summarizes all processing activity
Highest level view of system
Shows system boundaries
Scope is represented by a single process and outside agents

12. Context Diagram for Course Registration System Figure 6-5

13. Context Diagram for RMO Customer Support System Figure 6-6

14. DFD Fragments
Represents system response to one event within a single process symbol
Self contained model
Focuses attention on single part of system
Shows only data stores required to respond to events

15. Course Registration System
DFD Fragments for the
Course Registration System
Figure 6-7

16. Event Partitioned System Model
DFD that models system requirements using a single process for each event in a system or subsystem
Sometimes called diagram 0
Decomposition of the context level diagram
Is decomposed into more detailed DFD fragments

17. RMO Subsystems and Events
for Each Subsystem
Figure 6-11

18. Relationships Among DFD Abstraction
Levels when Subsystems are also Defined
Figure 6-12

19. RMO Subsystem DFD
Figure 6-13

20. Event-Partitioned Model of the Order-Entry Subsystem
Figure 6-14

21. Decomposing DFD Fragments
Sometimes DFD fragments need to be explored in more detail
Broken into subprocesses with additional detail
Numbering scheme doesn’t equate to execution sequence

22. Detailed Diagram for Create New Order
Figure 6-15

23. Physical and Logical DFDs
Logical model
Assumes implementation in perfect technology
Does not tell how system is implemented
Physical model
Describes assumptions about implementation technology
Developed in last stages of analysis or in early design

24. Physical DFD for Scheduling Courses Figure 6-16

25. DFD Quality Readable Internally consistent
Accurately represents system
Reduces information overload
Minimizes required number of interfaces

26. Data Flow Consistency Problems
Differences in data flow content between a process and its process decomposition
Data outflows without corresponding inflows
Data inflows without corresponding outflows
Results in unbalanced DFDs

27. Consistency Rules
All data that flows into a process must flow out or be used to generate data that flows out
All data that flows out of a process must have flowed in or been generated from data that flowed in

28. Unnecessary Data Input: Black Hole
Figure 6-17

29. Impossible Data Output: Miracle
Figure 6-18

30. Documenting DFD Components
Lowest level processes need to be described in detail
Data flow contents need to be described
Data stores need to be described in terms of data elements
Each data element needs to be described
Various options for process definition exist

31. Structured English
Method of writing process specifications that combines structured programming techniques with narrative English
Well suited to lengthy sequential processes or simple control logic
Ill-suited for complex decision logic or few sequential processing steps

32. Structured English Example
Figure 6-19

33. Structured English Process Description
RMO Process 2.1 and its
Structured English Process Description
Figure 6-20

34. Structured English Process Description for Determining Delivery Charge
Figure 6-21

35. Decision Tables and Decision Trees
Can summarize complex decision logic better than structured English
Incorporate logic into the structure of table or tree to make descriptions more readable

36. Decision Table for Calculating
Shipping Charges
Figure 6-22

37. Decision Tree for Calculating
Shipping Charges
Figure 6-23

38. Simple Decision Tree with
Multiple Action Rows
Figure 6-24

39. Data Flow Definitions
Textual description of data flow’s content and internal structure
Often coincide with attributes of data entities included in ERD

40. Simply Listing Elements Figure 6-25
Data Flow Definitions
Simply Listing Elements Figure 6-25

41. Algebraic Notation for Data Flow Definition Figure 6-26

42. Sample Report Produced by RMO Customer Support System Figure 6-27

43. Data Flow Definition for the RMO Products and Items Report Figure 6-28

44. Data Element Definitions
Describe data type
e.g. string, integer, floating point, Boolean
Very specific
Length of element
Maximum and minimum values

45. Data Element Definitions
Figure 6-29

46. Components of a Traditional Analysis Mode
Figure 6-30

47. Information Engineering Models
Focuses on strategic planning and data requirements of new system
Shares features with structured system development methodology
Developed by James Martin in early 1980’s

48. Information Engineering System Development Life Cycle Phases
Figure 6-31

49. Information Engineering and Structured Methodologies Compared
Table 6-1

50. Process Decomposition and Dependency Models
IE process model information types
Decomposition of processes into other processes
Dependency relationships among processes
Internal processing logic

51. RMO Customer Support System Process Decomposition Diagram
Figure 6-32

52. Process Dependency Diagram
Figure 6-33

53. Process Dependency Diagram
with Data Flows
Figure 6-34

54. Location and Communication Through Networks
Logical information needed during analysis
Number of user locations
Processing and data access requirements at various locations
Volume and timing of processing and data access requests
First, identify locations where work is to be performed

55. RMO Location Diagram
Figure 6-35

56. Location Considered List functions performed by users at each location
Place in matrix
Rows are system activities
Columns are locations
Other matrices
Activities versus data

57. RMO Activity-Location Matrix
Figure 6-36

58. RMO Activity-Data Matrix
Figure 6-37

59. Workflow Modeling
Modeling flow of control through a processing activity as it moves through a system
People
Organizations
Computer programs
Specific processing steps

60. Workflow Model of University
Scheduling System
Figure 6-38

61. Workflow Model of RMO Telephone
Order Entry System
Figure 6-39

62. Reliable Pharmaceutical Service Entity-Relationship Diagram
Figure 6-40

63. Reliable Pharmaceutical Service Event Table