Structuring System Requirements Process Modeling 1 Requirements Structuring

  • Slides: 49
Download presentation
Structuring System Requirements: Process Modeling 1

Structuring System Requirements: Process Modeling 1

Requirements Structuring in SDLC 2

Requirements Structuring in SDLC 2

Introduction • Purpose => clearly and coherently represent information about the system obtained during

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 3

Process Modeling • Graphical representation of processes that transform data • DFD - graphical

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 4

Process Modeling • Input - requirements gathering • Output/deliverables – 2 -4 DFDs (Context

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 5

Process Modeling Deliverables 6

Process Modeling Deliverables 6

Figure 8 -13 a Physical Context Diagram Figure 8 -13 b Physical Level-0 7

Figure 8 -13 a Physical Context Diagram Figure 8 -13 b Physical Level-0 7

Figure 8 -15 Current Logical Level-0 Diagram Figure 8 -16 Proposed Logical Level-0 Diagram

Figure 8 -15 Current Logical Level-0 Diagram Figure 8 -16 Proposed Logical Level-0 Diagram 8

9

9

Elements of a Data Flow Diagram Process Data flow Data store External entity 10

Elements of a Data Flow Diagram Process Data flow Data store External entity 10

Process • Actions performed on data that transforms it in some way • Above

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 11

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

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 12

Data Store • • • Data at rest Physical locations Labeled with a noun

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

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

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 14

Data Sources/Sink Rules • Ignore: – Interactions between sources and sink – Processes that

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 15

Figure 8 -3 a Incorrect Figure 8 -3 b Corrected Data Source/Sink Rules 16

Figure 8 -3 a Incorrect Figure 8 -3 b Corrected Data Source/Sink Rules 16

Level-0 Context Level-1 Level-2 17

Level-0 Context Level-1 Level-2 17

Context Level-0 Level-1 Same as previous Just different style Level-2 18

Context Level-0 Level-1 Same as previous Just different style Level-2 18

Context diagram Level 0 diagram Level 1 diagram Level 2 diagram 19

Context diagram Level 0 diagram Level 1 diagram Level 2 diagram 19

Context Level Diagram • Strong relationship between your Use Case Diagram and this DFD

Context Level Diagram • Strong relationship between your Use Case Diagram and this DFD • Always the 1 st 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) 20

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

Level 0 Diagram • 1 st 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 21

Relationship Between Use Case Narratives and DFDs 22

Relationship Between Use Case Narratives and DFDs 22

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

Level 1 DFDs • 2 nd 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 23 Narrative

Level 2 DFDs • 3 rd step in decomposition process • Not one for

Level 2 DFDs • 3 rd step in decomposition process • Not one for every Level 1 process only those that need it • Shows information flows • Correct numbering important 24

Alternative Data Flows • When a process can produce different outputs given different conditions

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) 25

Process Relationships • Tightly coupled processes - no data stores between them • Decoupled

Process Relationships • Tightly coupled processes - no data stores between them • Decoupled processes - data stores between processes Decoupled Processes Tightly Coupled Processes 26

DFD Diagramming Rules Know for the Final!!! 27

DFD Diagramming Rules Know for the Final!!! 27

Common DFD Errors 28

Common DFD Errors 28

29

29

General DFD Guidelines • Inputs to a process must be different from outputs of

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 30

31

31

Steps in Building DFDs • Build context DFD (from use case diagram) • Create

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 32

Figure 8 -4 Context Level Diagram Hoosier Burger’s Food Ordering System Figure 8 -5

Figure 8 -4 Context Level Diagram Hoosier Burger’s Food Ordering System Figure 8 -5 Level-0 Diagram 33

Decomposition of Process 1. 0 Hoosier Burger’s Food Ordering System 34

Decomposition of Process 1. 0 Hoosier Burger’s Food Ordering System 34

Decomposition of Process 4. 0 From the Level-0 Diagram Level-2 Level-1 Level-0 35

Decomposition of Process 4. 0 From the Level-0 Diagram Level-2 Level-1 Level-0 35

Context Level-0 Level-1 Decomposition Process Level-2 36

Context Level-0 Level-1 Decomposition Process Level-2 36

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

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 flow At least one output data flow Output data flow names usually different than input data flow names Between 3 and 7 processes per DFD

Validating the DFD For each DFD: Check each data flow for: A unique name:

Validating the DFD For each DFD: Check each data flow for: A unique name: noun; description Connects to at least one process Shown in only one direction (no two-headed arrows) A minimum number of crossed lines Check each data store for: A unique name: noun; description At least one input data flow At least one output data flow Check each external entity for: A unique name: noun; description At least one input or output data flow

Validating the DFD Across DFDs: Context Diagram: Every set of DFDs must have one

Validating the DFD Across 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

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

Advanced DFD Guidelines • Composite data flows can be broken into component data flows

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 41

Figure 8 -11 An Example of Data Flow Splitting 42

Figure 8 -11 An Example of Data Flow Splitting 42

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

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

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

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 44

DFDs - Stop When: • Reach lowest logical level • Each data store represents

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 45

Hoosier Burger’s Hiring Procedures 46

Hoosier Burger’s Hiring Procedures 46

Repository Entry for a Data Flow Diagram 47

Repository Entry for a Data Flow Diagram 47

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

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

Any Errors? ? Note Source And Destination Information on Data Flows 49

Any Errors? ? Note Source And Destination Information on Data Flows 49