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
- Structuring system requirements
- System requirements checklist output example
- Erickson nursing theory
- Dimensional modeling vs relational modeling
- Deal structuring process
- Process modeling in system analysis and design
- Monitors: an operating system structuring concept
- Business process and functional modeling
- Business process and functional modeling
- Modeling process quality
- Modeling process quality
- Decision trees show the logic structure in a
- Uml xor
- Stochastic process modeling
- Function allocation diagram aris
- Exercise 4
- Bpmn data store example
- Describe data and process modeling concepts and tools
- Structuring arguments
- Morphology
- Thinning and thickening in image processing example
- Time structuring in transactional analysis
- Supply chain drivers
- Time structuring in transactional analysis
- Time structuring in transactional analysis
- Direct observation
- Global tax structuring
- Structuring organizations for today's challenges
- Organizational structuring
- Mixed departmentalization
- Example of dominance structuring
- Components of facilities decisions
- Islamic structuring
- Structuring in counseling
- Structuring element dapat berukuran
- Structuring element dapat berukuran
- Morfologi citra adalah
- Structuring
- Drivers of supply chain management
- Framework for structuring drivers
- Alternative investment structuring
- Smart structuring
- Political risk structuring solutions
- Mhc-pms use case diagram
- Generalization in software engineering
- Mathematical modelling of mechanical systems
- Job costing and process costing
- Process costing vs job order costing
- Requirement specification process
- A spiral view of the requirements engineering process