Chapter 6 The Traditional Approach to Requirements

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

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

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

Traditional versus OO Approaches Figure 6-1

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

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

DFD Fragment from RMO Case Figure 6-3

DFD Integrates Event Table and ERD Figure 6-4

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

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

Context Diagram for Course Registration System Figure 6-5

Context Diagram for RMO Customer Support System Figure 6-6

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

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

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

RMO Subsystems and Events for Each Subsystem Figure 6-11

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

RMO Subsystem DFD Figure 6-13

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

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

Detailed Diagram for Create New Order Figure 6-15

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

Physical DFD for Scheduling Courses Figure 6-16

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

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

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

Unnecessary Data Input: Black Hole Figure 6-17

Impossible Data Output: Miracle Figure 6-18

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

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

Structured English Example Figure 6-19

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

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

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

Decision Table for Calculating Shipping Charges Figure 6-22

Decision Tree for Calculating Shipping Charges Figure 6-23

Simple Decision Tree with Multiple Action Rows Figure 6-24

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

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

Algebraic Notation for Data Flow Definition Figure 6-26

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

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

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

Data Element Definitions Figure 6-29

Components of a Traditional Analysis Mode Figure 6-30

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

Information Engineering System Development Life Cycle Phases Figure 6-31

Information Engineering and Structured Methodologies Compared Table 6-1

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

RMO Customer Support System Process Decomposition Diagram Figure 6-32

Process Dependency Diagram Figure 6-33

Process Dependency Diagram with Data Flows Figure 6-34

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

RMO Location Diagram Figure 6-35

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

RMO Activity-Location Matrix Figure 6-36

RMO Activity-Data Matrix Figure 6-37

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

Workflow Model of University Scheduling System Figure 6-38

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

Reliable Pharmaceutical Service Entity-Relationship Diagram Figure 6-40

Reliable Pharmaceutical Service Event Table