Top-down analysis and design: What is the core approach used when applying a top-down methodology to system development?

Introduction / Context:
Top-down design is foundational in structured and modular development. It reduces complexity by successively decomposing a system into smaller, understandable parts, enabling parallel work and cleaner interfaces among modules.

Given Data / Assumptions:

• The methodology starts from high-level goals/functions.
• Decomposition continues until modules are small enough to implement and test.
• We are contrasting with bottom-up aggregation or post-hoc documentation.

Concept / Approach:
In top-down design, analysts first define the system’s primary function(s). Then they split these into subfunctions, creating a module hierarchy (often visualized in structural charts). Each level clarifies responsibilities and interfaces. This contrasts with bottom-up (starting from components) and with preparing documentation only after coding (which risks mismatches and rework).

Step-by-Step Solution:

Verification / Alternative check:
Structured design literature (Yourdon/DeMarco) emphasizes hierarchical decomposition, cohesion, and coupling metrics, aligning with option (b).

Why Other Options Are Wrong:

• Prepare flowcharts after programming: Backward and risky practice.
• Combine small components to find top functions: That is bottom-up.
• All of the above: Includes incorrect statements.

Common Pitfalls:
Stopping decomposition too early; unclear interfaces; mixing unrelated responsibilities in one module.

Final Answer:
to identify a top level function and then create a hierarchy of lower level modules and components