Copyright 2002 Prentice-Hall, Inc. Chapter 7 Structuring System Requirements: Process Modeling

Copyright 2002 Prentice-Hall, Inc.

Chapter 7Structuring System

Requirements: Process Modeling

Learning Objectives

Understand the logical modeling of processes through studying data flow diagrams

How to draw data flow diagrams using rules and guidelines

How to decompose data flow diagrams into lower-level diagrams

Balancing of data flow diagrams

Structuring System Requirements

Modeling a system’s process The two sub-phases of the analysis phase of the SDLC

Requirement determination Requirements structuring

In the requirement structuring phase, the SA must organize and utilize the information gathered during

requirements determination into a meaningful representation of the IS that exists (Process Modeling)

Model the processing logic and the timing of the events (logic Modeling).

Structure of the data within the system (Data Modeling)

Process Modeling

Graphically represent the functions or processes that capture, manipulate, store and distribute data between a system and its environment and among system components

A common form of process model is Data flow diagram (DFD)

Process Modeling

Data flow diagrams enable us to model how data flows through an information

system (i.e. between external entities and the processes and data stores within a system),

the relationship among data flows, and how data is stored at specific locations. the processes that change or transform data.

Process Modeling

As data flow diagrams concentrate on the movement of data between processes, these diagrams are called process models.

Process Modeling

Deliverables and Outcomes Set of coherent, interrelated data flow diagrams Context data flow diagram (DFD)

Scope of the system, indicating which elements are inside and outside the system.

DFDs of current logical system Technology-independent DFD Shows what data processing functions are performed by the

current information system. Enables analysts to understand current system

8.88.8

Process Modeling

Deliverables and outcomes (continued)DFDs of new logical system

Technology independent Show data flows, structure and functional

requirements of new system

8.98.9

Data Flow Diagramming Mechanics

DFDs are versatile diagramming tools. Four symbols are used to represent both

physical and logical IS. See Figure 8-2

Two different standard sets can be used DeMarco and Yourdan Gane and Sarson

8.108.10

Figure 8-2Comparison of DeMarco & Yourdan and Gane & Sarson DFD symbol sets

8.118.11

Data Flow Diagramming Mechanics Data Flow

Depicts data in motion and moving from one place to another in the system.

A data flow is data that move together. It can be composed of many individual pieces of data that are generated at the same time and flow together to common destinations.

Drawn as an arrow Select a meaningful name to represent the data Example:

Data on a customer order form or a payroll check. The results of a query to a database. The contents of a printed report Data on a data entry computer display form.

8.128.12

Data Flow Diagramming Mechanics Data Store

Depicts data at rest May represent one or many different physical locations for data

e.g. File folder Computer-based file(s) Notebook

Represented by a rectangle with a vertical line on the left side. At the left end, the number for the data store is written. At the right side, a meaningful label for the data store is written.

Examples : Data about the customers, students, customer orders, or suppliers

invoices, roster of classes

8.138.13

Data Flow Diagramming Mechanics Process

Depicts work or action performed on data so that they are transformed, stored or distributed

Represented by a rectangle with rounded corners, and a line drawn through the top. The upper portion is used to indicate the number of process, and the lower portion indicates the name for the process.

When modeling data processing of a system, it doesn’t matter whether a process is performed manually or by a computer.

Examples: Generate paycheck Calculate overtime pay Compute grade point average (gpa)

8.148.14

Data Flow Diagramming Mechanics Source/Sink

Depicts the origin and/or destination of the data i.e. Source which produces data or Sink which consumes or accepts data. Sometimes referred to as an external entity, as they are outside the system.

Drawn as a square symbolName states what the external agent is

8.158.15

Data Flow Diagramming Mechanics

Because they are external to the Information system, many characteristics are not of interest to us

Examples of sources or sinks are as: A person inside or outside the business units supported by

the system the SA is analyzing and who interacts with the system e.g. customer

Another information system with which the system (the SA is analyzing) exchanges information e.g. instructor information system and student information system

Another Organization that sends data to or receives information from the system ( the SA is analyzing) e.g. book supplier and the university.

Do not consider the following characteristics of sources and sinks

When drawing Data Flow Diagrams, do not show Direct Interactions that occur between source and sinks. How information is used in the Source or Sink ( i.e. show

a source or sink a black box) How to control or redesigning a source or sink from the

perspective of the information system. Sources or Sink directly accessing stored data since

external agents cannot directly manipulate data stored within the system i.e. processes within the system must receive or distribute data between the system and its environment.

Example : Hoosier Burger’s Customer Order System

Hoosier Burger uses an information system known as customer order information system which is used to take Customer order from the Customer. and gives the Food order to the kitchen, the Receipt is to the CustomerManagement Reports to the Restaurant

Manager Draw the highest level Data flow Diagram i.e.

context diagram

Data Flow Diagramming Definitions Context Diagram

A data flow diagram (DFD) of the scope of an Information system that shows the

Whole system boundaries, external entities that interact with the system and major data flows between the external entities and the

system Highest level view of the system The context diagram contains only one process

labeled as “0” representing the entire system.The data stores of the system are

conceptually inside the one process, no data stores appear on a context diagram.

The sources/sinks represent its environment8.198.19

Figure 8-4Context diagram of Hoosier Burger’s automated food ordering system

8.208.20

Data Flow Diagramming DefinitionsLevel-0 Diagram (Diagram after the Context diagram) Next step is to expand the context diagram shown

in fig 8-4 to show the breakdown of processes A data flow diagram (DFD) that represents a

system’s major individual processes (functions), data flows and data stores at a high level of detail

Each process has a number that ends in .0 Capturing data from different sources Maintaining data stores Producing and distributing data to different sinks High level descriptions of data transformation

operations.

Developing DFDs: An Example

The system begins by receiving and transform the customer order ( name the process as 1.0) and outputs four data flows.

1. Food order send to the kitchen.

2. goods sold data.

3. inventory data

4. a receipt given to the customer.

8.228.22

Developing DFDs: An Example Goods sold data obtained from process 1.0 is used to

update the Goods Sold File by adding the new good sold data obtained in process 1.0 (Name the process as P2.0 and the data file as D2) .

Inventory data obtained from process 1.0 is used to update the Inventory File by deducting the inventory data (no. of items from the item stock) from the inventory file( Name the process as P3.0 and the data store as D1)

The Management reports are produced by reading the information from the updated D1 and D2 i.e. daily goods amount sold file and inventory data file ( Name the process as P4.0). These Management reports are given to the Restaurant Manager

8.238.23

Figure 8-5Level-0 DFD of Hoosier Burger’s food ordering system

8.248.24

Functional decomposition

The act of going from a single system to component processes is called functional decomposition

Functional decomposition is an iterative process of breaking the description or perspective of an system down into finer and finer details.

For Hoosier Burger system, the larger system is broken into four processes. Each of the processes ( or subsystems) are also candidates for decomposition. Each process may consist of several sub-processes. Decomposition continues until no sub-process can logically be broken down any further.

The lowest level of DFDs is called a primitive DFD.

Decomposition of level-0 DFD of Hoosier Burger SystemLevel -1 Data flow Diagram

The first process 1.0 called Receive and Transform Customer Food order is decomposed into five 5 logically separate processes or functions. They are Receive customer order ( P 1.1) Transform the order into a kitchen format used for the kitchen

(P1.2) Transform the order into a printed receipt for the customer

( P1.3) Transform the order into goods sold data ( P1.4) Transform the order into inventory data ( P1.5)

No source and sinks are represented are not shown in level -1 DFD.

Decomposing Process 1.0, 2.0 or 3.0 or 4.0 would create level-1 diagram.

Level - 1

Decomposition of level-0 DFD of Hoosier Burger System Process 2.0 and Process 3.0 use data input to update

data stores. Since updating a data store is a singular logical function , neither of the processes need to be decomposed further.

Each level-1, -2 or –n DFD represents one process on a level-(n-1) DFD. Each DFD should be on a separate page.

Process 4.0 (Produce Management reports) can be decomposed into three sub-processes. Access Goods Sold and Inventory data (P 4.1) Aggregate Goods Sold Inventory Data ( P 4.2) Prepare Management Reports ( P 4.3)

Level -1

Decomposition of level-1 DFD of Hoosier Burger System Process 4.3 should be further

decomposed into sub processesFormat Management Reports (P 4.3.1)Print Management Reports ( P 4.3.2)

Level 2

Data Flow Diagramming Rules

Basic rules that apply to all DFDs Inputs to a process are always different than outputs.

The processes transforms inputs into outputs, rather than simply pass the data through without some manipulation. Sometimes process produces same input data and at the same time new data flows

Objects on a DFD always have a unique name In order to keep the diagram uncluttered, you can repeat

data stores and sources/sinks on a diagram.

8.328.32


Process No process can have only

outputs (a miracle) No process can have only

inputs (black hole) A process has a verb

phrase label

Data Store Data cannot be moved

directly from one store to another.

Data cannot move directly from an outside source to a data store

Data cannot move directly from a data store to a data sink

Data store has a noun phrase label

8.338.33


Source/Sink Data cannot move

directly from a source to a sink

A source/sink has a noun phrase label

Data Flow A data flow has only one

direction of flow between symbols

It may flow in both direction A fork means that exactly

the same data goes from a common location to two or more processes, data stores or sources/sinks

8.348.34


Data Flow (Continued)L. A join means that exactly the same data comes from any

two or more different processes, data stores or sources/sinks to a common location

M. A data flow cannot go directly back to the same process it leaves. There must be at least one other process that handles the data flow, produces some other data flow, and returns the original data flow to the beginning process.

N. A data flow to a data store means updateO. A data flow from a data store means retrieve or useP. A data flow has a noun phrase label

8.358.35

Balancing DFDs

When decomposing a DFD, you must conserve inputs to and outputs from a process at the next level of decomposition

This is called balancing Example: Hoosier Burgers

In Figure 8-4, notice that there is one input to the system, the customer order

Three outputs: Customer receipt Food order Management reports

8.368.36

Balancing DFDs

Example (Continued)Notice Figure 8-5. We have the same inputs

and outputsNo new inputs or outputs have been

introducedWe can say that the context diagram and

level-0 DFD are balanced

8.378.37

Balancing DFDs

Notice Fig 8-7, where Process 1.0 from the level-0 DFD has been decomposed. Process 1.0 has one input and four outputs.

The inputs and outputs in level-1 diagram are the same.

No new inputs and outputs have been added. Compare Process 4.0 in fig 8-5 to its

decomposition in fig 8-8, the inputs and outputs are the same.

Balancing DFDs

An unbalanced exampleFigure 8-10 In context diagram, we have one input to the

system, A and one output, BLevel-0 diagram has one additional data flow,

CThese DFDs are not balanced

8.398.39

Figure 8-10An unbalanced set of data flow diagrams(a) Context diagram(b) Level-0 diagram

8.408.40

Balancing DFDs

The DFDs are balanced when we split a data flow going to a process into separate data flows going to two processes (see Figure 8-11). These diagrams are still balanced since exactly the same data are included in each diagram.

Balancing leads to four additional advanced rules (See Table 8-3)

8.418.41

Advanced Rules governing data flow diagrams A composite data flow on one level can be split into

component data flows at the next level, but no new data can be added.

The inputs to a process must be sufficient to produce the output from the process.

To avoid having data flow lines cross each other, repeat data stores or source/sinks on a DFD. Use an additional symbol, like a double line on the middle vertical line of a data store symbol, or a diagonal line in a corner of a sink/source square

Guidelines for Drawing DFDs

CompletenessDFD must include all components necessary

for systemEach component must be fully described in

the project dictionary or CASE repository Consistency

The extent to which information contained on one level of a set of nested DFDs is also included on other levels

8.458.45


TimingTime is not represented well on DFDsBest to draw DFDs as if the system has never

started and will never stop. Iterative Development

Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled

8.468.46


Primitive DFDsLowest logical level of decompositionDecision has to be made when to stop

decomposition

8.478.47


Rules for stopping decompositionWhen each process has been reduced to a

single decision, single calculation or single database operation

When each data store represents data about a single entity, such as a customer, employee, product or order.

When the system user does not care to see any more detail

8.488.48


Rules for stopping decomposition (continued) When the analyst have documented sufficient detail to

do subsequent systems development task. When every data flow does not need to be split further

to show that data are handled in various ways When you believe that you have shown each

business form or transaction, on-line display and report as a single data flow

When you believe that there is a separate process for each choice on all lowest-level menu options

8.498.49

Using DFDs as Analysis Tools

Gap AnalysisThe process of discovering discrepancies

between two or more sets of data flow diagrams, representing two or more states of an IS or discrepancies within a single DFD

Inefficiencies in a system can often be identified through DFDs

8.508.50

Documents

Copyright 2002 Prentice-Hall, Inc. Chapter 7 Structuring System Requirements: Process Modeling