Structuring System Requirements Process Modeling 1 Requirements Structuring

















































- Slides: 49

Structuring System Requirements: Process Modeling 1

Requirements Structuring in SDLC 2

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

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 8

9

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

Level-0 Context Level-1 Level-2 17

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

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 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 • 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 processes - data stores between processes Decoupled Processes Tightly Coupled Processes 26

DFD Diagramming Rules Know for the Final!!! 27

Common DFD Errors 28

29

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

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 Level-0 Diagram 33

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

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

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: 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 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

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

* * 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 • 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 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

Repository Entry for a Data Flow Diagram 47

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

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