1

Structuring System Requirements: Process Modeling

2

Requirements Structuring in SDLC

3

Introduction• Purpose => clearly and coherently represent

information about the system obtained during requirements determination

• Model– How information flows through the system– What relationships between data flows exist– What processes transform the data– Where data is stored

4

Process Modeling• Graphical representation of processes that

transform data• DFD - graphical tool that models flow of

data in an information system• Structured analysis techniques• Hierarchical• First of three perspectives for system

modeling

5

Process Modeling• Input - requirements gathering• Output/deliverables

– 2-4 DFDs (Context -level, Level-0, others)– Logical models (DFDs)– Close match to Use Case models– Physical DFDs replaced with Use Case

Diagram and Use Case Narratives in our class

6

Process Modeling Deliverables

7

Figure 8-13bPhysical Level-0

Figure 8-13aPhysical

Context Diagram

8

Figure 8-15Current LogicalLevel-0 Diagram

Figure 8-16Proposed LogicalLevel-0 Diagram

9

10

Process

Data flow

Elements of a Data Flow Diagram

Data store

External

entity

11

Process• Actions performed on data that transforms

it in some way• Above the line is a number that indicates

the process number and level• Labeled with a verb phrase• Must change or manipulate the data in some

way therefore must have an input and an output

• Close correspondence to Use Cases

12

Data Flow• Line & arrow• Data in motion (arrow indicates direction of

flow)• Data that moves together (general name of a

business form)• Labeled with a noun phrase• Close correspondence to inputs and outputs

in Use Case Diagram

13

Data Store

• Data at rest• Physical locations• Labeled with a noun phrase• Must interact with a process• Often databases or database tables

14

Data Source/Sink• Source of data from environment to system or

destination of data from system to environment (i.e. OUTSIDE the system)

• Can be person, system, organization, etc.• Labeled with a noun phrase• Black boxes from our perspective• All systems must have one source and one sink• Also called External Entities• Close correspondence with Actors in Use Case

models

15

Data Sources/Sink Rules

• Ignore:– Interactions between sources and sink– Processes that occur within a source or sink– Designs or controls for them

• Do not allow direct access from one of these to any data store within your system

16Data Source/Sink Rules

Figure 8-3aIncorrect

Figure 8-3bCorrected

17

Context

Level-0

Level-1

Level-2

18

Context Level

Level-0

Level-1

Level-2 Same as previousJust different style

19

Context diagramLevel 0 diagram

Level 1 diagram

Level 2 diagram

20

Context Level Diagram• Strong relationship between your Use Case

Diagram and this DFD• Always the 1st DFD• Always has just one process (0 process)• Must have at least 1 external entity (shows

all if more than 1)• Must have at least 1 input and 1 output

dataflow (shows all inputs and outputs)

21

Level 0 Diagram• 1st step in decomposition (from context

level diagram)• Shows all main processes – should be a

close correlation to your essential Use Case Narratives

• First level where data stores are added• Shows external entities and all major

processes they interact with• Shows relationships between major

processes

22

RelationshipBetweenUse CaseNarrativesand DFDs

23

Level 1 DFDs• 2nd step in decomposition process• Generally 1 for each major process on

Level 0 DFD• Shows all internal processes for a single

Level 0 process• Shows information flows• Children processes must wholly &

completely make up parent process• Most will have a detailed Use Case

Narrative

24

Level 2 DFDs

• 3rd step in decomposition process• Not one for every Level 1 process only

those that need it• Shows information flows• Correct numbering important

25

Alternative Data Flows

• When a process can produce different outputs given different conditions

• Show both in DFD• Use Logic Models (process descriptions) to

explain• Typically associated with IF-THEN-ELSE

or CASE (decisions or choices)

26

Process Relationships• Tightly coupled processes - no data stores

between them• Decoupled processes - data stores between

processes

DecoupledProcesses

TightlyCoupledProcesses

27

DFD Diagramming RulesKnow for the Final!!!

28

CommonDFD

Errors

29

30

General DFD Guidelines

• Inputs to a process must be different from outputs of a process

• DFD objects must have unique names• Functional decomposition - going from

highest level deeper and deeper into more detail (each level on its own page)

• Balancing - conservation of inputs and outputs

31

32

Steps in Building DFDs• Build context DFD (from use case diagram)• Create DFD fragment for each essential Use

Case Narrative• Organize DFD fragments into Level 0 DFD• Decompose level 0 processes into level 1

DFDs and level 1 processes into level 2 DFDs as needed

• Validate• Iterate

33

Figure 8-4Context Level

Diagram

Figure 8-5Level-0 Diagram

Hoosier Burger’sFood Ordering System

34

Decomposition of Process 1.0

Hoosier Burger’s Food Ordering System

35

Decomposition of Process 4.0 From the Level-0 Diagram

Level-0

Level-1

Level-2

36

Context Level

Level-0

Level-1

Level-2 DecompositionProcess

Validating the DFD

• Syntax errors – diagram follows the rules– Assure correct DFD structure

For each DFD: Check each process for: A unique name: action verb phrase; number; description

At least one input data flowAt least one output data flowOutput data flow names usually different thaninput data flow namesBetween 3 and 7 processes per DFD

Validating the DFDFor each DFD:

Check each data flow for:A unique name: noun; descriptionConnects to at least one processShown in only one direction (no two-headed arrows)A minimum number of crossed lines

Check each data store for:A unique name: noun; descriptionAt least one input data flowAt least one output data flow

Check each external entity for:A unique name: noun; descriptionAt least one input or output data flow

Validating the DFDAcross DFDs:

Context Diagram:Every set of DFDs must have one Context Diagram

Viewpoint:There is a consistent viewpoint for the entire set of DFDs

Decomposition:Every process is wholly and complete described by the

processes on its children DFDs

Balance:Every data flow, data store, and external entity on a higher level

DFD is shown on the lower level DFD that decomposes it No data stores or data flows appear on lower-lever DFDs that do not appear on their parent DFD

Validating the DFD

• Semantics errors – diagram conveys correct meaning– Assure accuracy of DFD relative to

actual/desired business processes• To verify correct representation, use

– User walkthroughs– Role-play processes

• Examine lowest level DFDs to ensure consistent decomposition

• Examine names carefully to ensure consistent use of terms

41

Advanced DFD Guidelines• Composite data flows can be broken into

component data flows• Inputs must be sufficient to produce outputs• Exception messages at primitive DFD level

can be new• Can repeat external entities to avoid

messiness

42

Figure 8-11 An Example of Data Flow Splitting

43

An Example of Repeating External Entities to Avoid Crossed Lines and Messiness

* *

44

More Guidelines

• Completeness - all necessary components are modeled correctly and fully described

• Consistency - balanced DFDs• Timing - DFDs are drawn as if in perpetual

motion• Iterative - lower level rule of thumb 3

revisions

45

DFDs - Stop When:• Reach lowest logical level• Each data store represents a single entity• Each process is a single decision,

calculation or database operation• Users doesn’t want more detail• Detail is good enough for spec development• Data flows can’t be split any further• A separate process for each lowest level

menu exists

46Hoosier Burger’s Hiring Procedures

47Repository Entry for a Data Flow Diagram

48

List 3 Errors(DFD Rule Violations)For this set of DFDs

49

Any Errors??

Note Source And Destination Information on

Data Flows