LECTURE 6: Traditional Approach to Requirements

ITEC 3010 Systems Analysis and Design, I

[Prof. Peter Khaiter]

Lecture Outline
Traditional Approach vs. OOA Data Flow Diagrams (DFDs) DFD and Levels of Abstraction Context Diagrams DFD Fragments Physical and Logical DFDs Evaluating DFD Quality Documentation of DFD Components Locations and Communication Through Networks
2

Traditional Approach vs. OOA

Two approaches differ in the way the system is modeled and implemented: Traditional approach: views a system as a collection of processes (like computer programs, a set of instructions that execute in sequence) when the process executes it interacts with data (reads data values and then writes data values back to the data file emphasizes processes, data, inputs/outputs Object Oriented approach (OO): views a system as a collection of interacting objects which are capable of their own behavior (called methods) which allow the objects to interact with each other and with people using the system there are NO conventional processes and data files per se, just interacting objects
3

Traditional Approach vs. OO Approach

Requirements for the Traditional and OO Approaches

Data Flow Diagrams (DFDs)

Graphical system model that shows all main requirements for an IS in one diagram
Inputs/outputs Processes Data storage

Easy to read and understand with minimal training (only 5 symbols used) DFD integrates processing triggered by events (event table) with the data entities modeled by ERD

DFD Symbols

The square is an external agent (a person or organization, outside the boundary of a system that provides data inputs or accepts data outputs) The rectangle with rounded corners is a process (named Look up item available and can be referred to by its number, 1) A process defines rules (algorithms or procedures) for transforming inputs into outputs The lines with arrows are data flows (represents movement of data). Slide shows two data flows between Customer and process 1: a process input Item inquiry and process output named Item availability details The flat three-sided rectangle is a data store (a file or part of a database that stores information about data entity)
7

Data Flow Diagram Symbols

DFD Fragment Showing Use Case Look Up Item Availability from the RMO

DFD Integrates Event Table and ERD

10

DFD and Levels of Abstraction

DFD is a modeling technique that breaks the system into a hierarchical set of increasingly more detailed models DFD may reflect the processing at either a higher level (more general view of the system) or at lower level (a more detailed view of one process) These different views of the system (higher level versus low level) creates the levels of abstraction DFDs are decomposed into additional diagrams to provide multiple levels of detail Higher-level diagrams provide general views of system Lower-level diagrams provide detailed views of system

11

Layers of DFD Abstraction for Course Registration System

12

Context Diagrams

DFD that summarizes all processing activity for the system or subsystem
Highest level (most abstract) view of system Shows system boundaries System scope is represented by a single process, external agents, and all data flows into and out of the system
13

Context Diagrams for a Course Registration System

14

Notes on Context Diagrams

Useful for showing system boundaries (represents the system scope within the single process plus external agents) External agents that supply or receive data from the system are outside the system scope Data stores are not usually shown in the context diagram since they are considered to be within the system scope It is the highest level of DFD Context diagram does not show any details of what takes place within the system
15

Context Diagrams for RMO CSS

16

DFD Fragments

Created for each use case in the event table

Represent system response to one event within a single process symbol

Self-contained models
Focus attention on single part of system Show only data stores required in the use case
17

Three Separate DFD Fragments for Course Registration System

18

Event-Partitioned System Model

DFD to model system requirements using single process for each use case/activity in system or subsystem Combines all DFD fragments together to show decomposition of the context-level diagram

Shows the entire system on a single DFD (in greater detail than on the context diagram)
Sometimes called diagram 0 Used primarily as a presentation tool Decomposed into more detailed DFD fragments
19

Combining DFD Fragments to Create EventPartitioned System Model

20

Layers of DFD Abstraction

21

RMO Subsystems and Use Cases/Activities from Event Table

22

Context Diagram for RMO Order-Entry Subsystem

23

Five Separate DFD Fragments for RMO Order-Entry Subsystem

24

The eventpartitioned model of the Order-Entry subsystem (diagram 0)

25

Decomposing DFD Fragments

Most DFD fragments can be further described using structured English

Sometimes DFD fragments need to be diagrammed in more detail

Decomposed into subprocesses in a detailed DFD

DFD numbering scheme
Hierarchical decomposition
DFD Fragment 2 is decomposed into Diagram 2 Diagram 2 has processes 2.1, 2.2, 2.3, 2.4 four steps to 26 complete the activity

Detailed DFD for Create new order DFD fragment

27

Hierarchy of the DFDs

The top most - context diagram (entire system as one process), which breaks down to the subsystem diagram (one process per subsystem) The subsystem diagram is, in turn, decomposed into a set of the event-partitioned subsystem diagrams

There is no single diagram 0. Instead, there is an event-partitioned DFD for each of the subsystems
Each event-partitioned DFD is a diagram 0 for a single subsystem
28

Hierarchy of the DFDs

29

FIGURE 6-20 Incorrect and correct way to draw DFD. 30

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 E.g., the technology assumption is embedded in the name of process 1.1 Making copies for department chairs it is a manual task, which implies that the data store Old schedule 31 and the data flows into and out of process 1.1 are papers, etc.

Physical DFD for Scheduling Courses

32

Evaluating DFD Quality

Readable Internally consistent and balanced Accurately represents system requirements Reduces information overload rule of 7 +/- 2
Single DFD should not have more than 7 +/-2 processes No more than 7 +/- 2 data flows should enter or leave a process or data store in a single DFD

Minimizes required number of interfaces

33

Data Flow Consistency Problems

Differences in data flow content between a process and its decomposition

Data outflows without corresponding inflows Data inflows without corresponding outflows Results in unbalanced DFDs
34

Black Hole and Miracle

black hole, i.e. a process with a data input that is never used to produce a data input. The following rules help to avoid the black holes: - All data that flow into a process must flow out of the process or be used to generated data that flow out of the process - All data that flow out of a process must have flowed into the process or have been generated from data that flowed into the process Miracle - a process with a data output that is created out of nothing ( miraculously appears)

35

Unnecessary Data Input: Black Hole

36

Process with Impossible Data Output: a Miracle

37

Process with Unnecessary Data Input

38

Process with Impossible Data Output

39

Documentation of DFD Components

DFDs show three types of internal system component: processes, data flows and data stores The details of each component need to be described 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

40

Process Descriptions
Each process on a DFD must be formally defined There are several options for process definition including decomposition. In a process of decomposition, a higherlevel process is formally defined by a DFD that contains lover-level processes, which, in turn, may be further decomposed into even lower-level DFDs. Eventually a point will be reached when a process becomes so simple that it can adequately be described by another process description method, i.e. without next lower-level DFD. These description methods include: - Structured English - Decision tables - Decision trees These models describe the process as an algorithm.
41

Structured English

Method of writing process specifications

Combines structured programming techniques with narrative English

Well-suited for lengthy sequential processes or simple control logic (single loop or if-then-else)
Ill-suited for complex decision logic or few (or no) sequential processing steps

42

Structured English Example

43

Process 2.1 and Structured English Process Description

44

A structured English process description for calculating shipping charges

45

Decision Tables and Decision Trees

Can summarize complex decision logic better than structured English

Incorporate logic into the table or tree structure to make descriptions more readable

46

Decision Table for Calculating Shipping Charges

47

Decision Tree for Calculating Shipping Charges

48

A Decision Table with Multiple Action Rows

49

Data Flow Definitions

Data flow is a collection of data elements Data flow definition is a textual description of data flows content and internal structure Lists all the elements, e.g. a New Order data flow consists of CustomerName, Customer-Address, CreditCard-Information, Item-Number and Quantity Often coincide with attributes of data entities included in ERD plus computed values

Algebraic notion is alternative to the list

Describes data elements on data flow plus data structure
50

List and Algebraic Notation for Data Flow Definition

51

RMO Products and Items Report

52

Data Flow Definition for RMO Products and Items Control Break Report

53

Data Element Definitions

Data type description

String, integer, floating point, Boolean Sometimes very specific written description e.g., special codes (e.g. code A means ship immediately, code B hold for one day and code C hold shipment pending confirmation)

Length of element (usually for strings) Maximum and minimum values (for numeric values) Data dictionary repository for definitions of data flows, data stores, and data elements
54

Data Element Definition Examples

55

Data Store Definitions

A data store on the DFD represents a data entity on the ERD (so, no separate definition is needed, just a note referring to the ERD for details) If a data store are not linked to an ERD, a definition is provided as a collection of elements (like did for data flows)

56

Components of a Traditional Analysis Model

Four components of a traditional analysis model are Data flow diagrams Entity-relationship diagram Process definitions Data definitions They form an interlocking set of specifications for system requirements DFD shows highest-level view of the system Other components describe some aspect of DFD These models were created in the 1970s and 1980s as a part of the structured analysis methodology
57

Components of a Traditional Analysis Model

58

Locations and Communication Through Networks

Physical 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

Needed to make initial design decisions such as

Distribution of computer systems, application software, database components, network capacity

59

Gathering Location Information

Identify locations where work is to be performed Draw location diagram a map that identifies all of the processing locations of a system (business offices, warehouses, manufacturing facilities) List functions performed by users at each location Build activity-location matrix - a table that describes the relationship between processes and the locations where they are performed Rows are system activities from event table Columns are physical locations Build activity-data (CRUD) matrixis a table that describes stored data entities, the locations from which they are accessed and the nature of the access (i.e. which activities require access to the data). Source of this information is: - the DFD fragments (traditional approach) and - sequence diagrams (OO approach) CRUD create, read, update, and delete 60

RMO Location diagram

61

RMO Activity-Location Matrix

62

RMO Activity-Data Matrix (CRUD)

63

Readings
Todays lecture: Chapter 6 The Traditional Approach to Requirements For next lecture: Chapter 7 The ObjectOriented Approach to Requirements

64