System Decomposition & Structure Charts

Decomposition breaks a complex task into smaller tasks. This helps people understand, develop, test and maintain the system. Tasks still need compatible inputs and outputs when brought together; decomposition does not guarantee conflict-free development.

Worked example: equipment loans

A library equipment system can be decomposed into identify borrower, find item, check availability, record loan and display confirmation. Record loan can be divided further into calculate due date and save borrower/item/date details.

A decomposition diagram shows the hierarchy: put Equipment Loans at the top, connect it to the five tasks, then connect Record Loan to its two smaller tasks. This represents the parts of the problem, not the sequence of every instruction. A flowchart represents control flow; pseudocode expresses precise steps.

Input, process, output and storage

Inputs are the borrower ID and requested item ID. Processing checks availability and calculates a due date. Output confirms the loan or explains rejection. Storage retains the loan for later return. Storage is needed even after the confirmation leaves the screen.

Independent design

Design a small club attendance system. Draw a decomposition diagram, identify its input/process/output/storage, then give precise steps for recording one arrival. Compare: inputs can include member ID and date; processing checks membership and duplicate arrival; output confirms or rejects; storage keeps attendance history. Other sensible designs are possible if their responsibilities and data agree.