Functional decomposition using DFDs: When decomposing a system, how is the Data Flow Diagram typically partitioned?

Introduction / Context:Data Flow Diagrams (DFDs) depict processes, data stores, and data flows. Functional decomposition breaks complex systems into manageable subsystems. The organizing principle is the logical cohesion of activities (processes)—not arbitrary groupings by files or ignoring the DFD entirely.

Given Data / Assumptions:

• “Actigrams” refers to activity/process symbols in the model.
• We intend a decomposition that preserves logical cohesion and minimizes inter-module coupling.
• Data stores and flows inform grouping, but processes drive boundaries.

Concept / Approach:Partition the DFD so that processes which transform related inputs to related outputs (high functional cohesion) are grouped, while minimizing cross-boundary flows. This eases assignment to teams, clarifies interfaces, and supports modular design. Grouping solely by data stores (“datagrams”) risks mixing unrelated logic that happens to touch the same files.

Step-by-Step Solution:

Verification / Alternative check:Structured analysis guidance recommends grouping by cohesion and separating by coupling, aligning with logical activity clusters shown on the DFD.

Why Other Options Are Wrong:

• DFD is ignored: Opposes structured analysis.
• Partition by datagrams/data stores: Data-centric only; can weaken cohesion.
• Both (a) and (c): Includes “ignore DFD,” which is incorrect.

Common Pitfalls:Overfitting to current files; creating partitions with excessive cross-calls; ignoring future maintainability when drawing boundaries.

Final Answer:is partitioned according to the logical "closeness" of the actigrams