Software Engineering Unit 3: Requirement Analysis & Structured Analysis (DFD & CFD)

Subject: Software Engineering

Comprehensive Unit 3 notes covering Requirement Analysis principles, Data Dictionary syntax, Finite State Machines (FSM), Data Flow Diagrams (DFDs Level 0/1/2), Control Flow Diagrams (CFD), and Process Specs (PSEC).

Concept Summary

# UNIT 3: Requirement Analysis: Tasks, Principles, Prototyping & Specification, Data Dictionary, Finite State Machine (FSM) Models, Structured Analysis (DFD & CFD) ## 3.1 Requirement Analysis Tasks & Principles ### Requirement Analysis Tasks 1. **Problem Recognition**: Understanding system domain, organizational environment, and stakeholder pain points. 2. **Evaluation & Synthesis**: Analyzing data flows, functional boundaries, operational constraints, and technical feasibility. 3. **Modeling**: Abstracting system functional requirements into graphical structural models. 4. **Specification**: Formally documenting requirements into an SRS. 5. **Review & Validation**: Conducting customer requirement walkthroughs to resolve conflicts and ambiguities. ### Core Analysis Principles - Operational domain must be represented and understood. - Models must depict information flow, control flow, and data structures. - System functions must be partitioned hierarchically to show architectural detail. - Essential requirements must be separated from implementation choices. --- ## 3.2 Data Dictionary (DD) A Data Dictionary is a centralized repository that stores precise structural definitions of every data flow, data store, process name, and composite data element referenced across analysis models. ### Data Dictionary Notation Rules - `=` : is composed of / equals - `+` : AND (sequence) - `[ | ]` : OR (selection of one alternative) - `{ }` : Iteration / repetition (0 or more times) - `( )` : Optional data item - `*...*` : Comment string #### Example Entry ```text Customer_Record = Customer_ID + Customer_Name + Address + (Phone_Number) + 1{Order_History}5 ``` --- ## 3.3 Behavioral Modeling & Finite State Machine (FSM) Behavioral modeling represents how a software system reacts to external events and changes internal states. ### State Transition Diagram (STD) Notation - **State** (Rectangle with rounded corners): Represents a specific system mode of operation (e.g., *Idle*, *Authenticating*, *Processing*). - **Transition Arrow**: Directed line indicating movement from source state to target state. - **Event / Action Label**: Format `Event [Guard Condition] / Action`. - *Event*: External occurrence triggering transition. - *Guard Condition*: Boolean predicate that must be TRUE for transition to occur. - *Action*: Output operation executed during transition. --- ## 3.4 Structured Analysis & Data Flow Diagrams (DFDs) Structured Analysis is a traditional process-centric technique introduced by DeMarco, Yourdon, and Gane & Sarson to transform requirements into Data Flow Diagrams. ### The 4 Standard DFD Symbols 1. **Process (Circle / Bubble)**: Transforms incoming data flows into outgoing data flows. 2. **External Entity / Source or Sink (Rectangle)**: Real-world entities outside system boundary that send data into or receive data from system. 3. **Data Store (Parallel Lines / Open Rectangle)**: Repository of resting data (database table, file, cache). 4. **Data Flow (Arrow)**: Named pipeline conveying moving data between processes, data stores, and entities. --- ### DFD Hierarchy & Leveling Rules #### Level 0 DFD (Context Diagram) Abstract high-level view showing the entire system as **one single process bubble** interacting with external entities. Contains 0 data stores. #### Level 1 DFD Explodes Level 0 bubble into major functional subsystems (typically 3 to 7 process bubbles), revealing primary data stores and inter-process data flows. #### Level 2+ DFD (Sub-process Explosion) Further decomposes complex Level 1 processes into sub-processes for detailed algorithmic clarity. #### Conservation of Data (Balancing Rule) All input and output data flows entering/leaving a process at Level $N$ MUST match the input and output data flows of its exploded sub-diagram at Level $N+1$. --- ## 3.5 Control Flow Diagrams (CFDs) & Process Specifications (PSEC) ### Control Flow Diagram (CFD) Extension of DFD for real-time systems. Replaces data flows with **Control Flows** (dashed arrows conveying discrete signals/events) and processes with **Control Specification (CSPEC)** modules. ### Process Specification (PSEC) Describes the internal algorithmic logic executed inside primitive DFD processes. Expressed using: - **Structured English**: Restricted natural language using `IF-THEN-ELSE`, `DO-WHILE` control logic. - **Decision Tables**: Tabular matrix mapping combinations of conditions to actions. - **Decision Trees**: Tree graph illustrating conditional decision paths. --- ---

Key Revision Rules & Formulas

Data Flow Diagrams (DFD) use Circles for Processes, Rectangles for External Entities, Parallel Lines for Data Stores, and Arrows for Data Flows.
Level 0 DFD (Context Diagram) represents the entire system as 1 process bubble with 0 data stores.
Balancing Rule requires input/output data flow conservation across Level N and exploded Level N+1 DFDs.
Data Dictionary is a centralized catalog defining all data items (+ sequence, [|] selection, {} iteration, () optional).
State Transition Diagrams (STD / FSM) model system behavioral state changes triggered by external events.
Control Flow Diagrams (CFD) model real-time system signals using Control Specifications (CSPEC).
Process Specifications (PSEC) describe primitive DFD logic using Structured English, Decision Tables, or Decision Trees.

Common Exam Pitfalls

Misidentifying DFD process symbols; processes are circles/bubbles, entities are rectangles.
Including data stores in a Level 0 Context Diagram; Level 0 DFD contains NO data stores.
Violating DFD balancing rules between Level 1 and exploded Level 2 sub-diagrams.

Software EngineeringTopic Cheat Sheet

Software Engineering Unit 3: Requirement Analysis & Structured Analysis (DFD & CFD)

5 Free

Software Engineering Unit 3: Requirement Analysis & Structured Analysis (DFD & CFD)

High-Yield Revision Hub

Master Software Engineering Unit 3: Requirement Analysis & Structured Analysis (DFD & CFD)

Concept Breakdown

Detailed technical explanation

UNIT 3: Requirement Analysis: Tasks, Principles, Prototyping & Specification, Data Dictionary, Finite State Machine (FSM) Models, Structured Analysis (DFD & CFD)

3.1 Requirement Analysis Tasks & Principles

Requirement Analysis Tasks

Problem Recognition: Understanding system domain, organizational environment, and stakeholder pain points.
Evaluation & Synthesis: Analyzing data flows, functional boundaries, operational constraints, and technical feasibility.
Modeling: Abstracting system functional requirements into graphical structural models.
Specification: Formally documenting requirements into an SRS.
Review & Validation: Conducting customer requirement walkthroughs to resolve conflicts and ambiguities.

Core Analysis Principles

Operational domain must be represented and understood.
Models must depict information flow, control flow, and data structures.
System functions must be partitioned hierarchically to show architectural detail.
Essential requirements must be separated from implementation choices.

3.2 Data Dictionary (DD)

A Data Dictionary is a centralized repository that stores precise structural definitions of every data flow, data store, process name, and composite data element referenced across analysis models.

Data Dictionary Notation Rules

= : is composed of / equals
+ : AND (sequence)
[ | ] : OR (selection of one alternative)
{ } : Iteration / repetition (0 or more times)
( ) : Optional data item
*...* : Comment string

Example Entry

Customer_Record = Customer_ID + Customer_Name + Address + (Phone_Number) + 1{Order_History}5

3.3 Behavioral Modeling & Finite State Machine (FSM)

Behavioral modeling represents how a software system reacts to external events and changes internal states.

State Transition Diagram (STD) Notation

State (Rectangle with rounded corners): Represents a specific system mode of operation (e.g., Idle, Authenticating, Processing).
Transition Arrow: Directed line indicating movement from source state to target state.
Event / Action Label: Format Event [Guard Condition] / Action.
- Event: External occurrence triggering transition.
- Guard Condition: Boolean predicate that must be TRUE for transition to occur.
- Action: Output operation executed during transition.

3.4 Structured Analysis & Data Flow Diagrams (DFDs)

Structured Analysis is a traditional process-centric technique introduced by DeMarco, Yourdon, and Gane & Sarson to transform requirements into Data Flow Diagrams.

The 4 Standard DFD Symbols

Process (Circle / Bubble): Transforms incoming data flows into outgoing data flows.
External Entity / Source or Sink (Rectangle): Real-world entities outside system boundary that send data into or receive data from system.
Data Store (Parallel Lines / Open Rectangle): Repository of resting data (database table, file, cache).
Data Flow (Arrow): Named pipeline conveying moving data between processes, data stores, and entities.

DFD Hierarchy & Leveling Rules

Level 0 DFD (Context Diagram)

Abstract high-level view showing the entire system as one single process bubble interacting with external entities. Contains 0 data stores.

Level 1 DFD

Explodes Level 0 bubble into major functional subsystems (typically 3 to 7 process bubbles), revealing primary data stores and inter-process data flows.

Level 2+ DFD (Sub-process Explosion)

Further decomposes complex Level 1 processes into sub-processes for detailed algorithmic clarity.

Conservation of Data (Balancing Rule)

All input and output data flows entering/leaving a process at Level $N$ MUST match the input and output data flows of its exploded sub-diagram at Level $N+1$ .

3.5 Control Flow Diagrams (CFDs) & Process Specifications (PSEC)

Control Flow Diagram (CFD)

Extension of DFD for real-time systems. Replaces data flows with Control Flows (dashed arrows conveying discrete signals/events) and processes with Control Specification (CSPEC) modules.

Process Specification (PSEC)

Describes the internal algorithmic logic executed inside primitive DFD processes. Expressed using:

Structured English: Restricted natural language using IF-THEN-ELSE, DO-WHILE control logic.
Decision Tables: Tabular matrix mapping combinations of conditions to actions.
Decision Trees: Tree graph illustrating conditional decision paths.

Key Revision Rules

Essential formulas and core points to memorize

1Data Flow Diagrams (DFD) use Circles for Processes, Rectangles for External Entities, Parallel Lines for Data Stores, and Arrows for Data Flows.
2Level 0 DFD (Context Diagram) represents the entire system as 1 process bubble with 0 data stores.
3Balancing Rule requires input/output data flow conservation across Level N and exploded Level N+1 DFDs.
4Data Dictionary is a centralized catalog defining all data items (+ sequence, [|] selection, {} iteration, () optional).
5State Transition Diagrams (STD / FSM) model system behavioral state changes triggered by external events.
6Control Flow Diagrams (CFD) model real-time system signals using Control Specifications (CSPEC).
7Process Specifications (PSEC) describe primitive DFD logic using Structured English, Decision Tables, or Decision Trees.

Common Exam Mistakes

Where students frequently lose marks

Misidentifying DFD process symbols; processes are circles/bubbles, entities are rectangles.

Including data stores in a Level 0 Context Diagram; Level 0 DFD contains NO data stores.

Violating DFD balancing rules between Level 1 and exploded Level 2 sub-diagrams.

Topic Quiz Practice

No Questions

No practice questions available for this topic yet.