Problem Analysis and Decomposition
Specifying program requirements means translating a vague problem into concrete, measurable specifications that leave no room for ambiguity.
From Goal to Specification
A programming problem often begins as a broad goal: create a backup system, build a calculator, or organize data. A goal describes the desired outcome, but it does not yet tell a program exactly what to do. Problem analysis begins by replacing that general intention with requirements that are concrete, measurable, and unambiguous.
For a backup program, the specification must settle four decisions: which files will be backed up, where the backup will be stored, which archive format will be used, and how the archive will be named. These decisions form the bridge between understanding the problem and designing its implementation.
The Four Backup Decisions
A complete backup specification has four distinct components. Each one answers a different question about the backup process. Together, they define what the program must archive, where it must put the result, what form that result must take, and what name the result must receive.
| Requirement area | What it determines | Specified form |
|---|---|---|
| Files to back up | The input content for the backup | A list of files |
| Storage location | Where the archive will be written | A main backup directory |
| Archive format | The form of the resulting archive | Zip |
| Naming scheme | What identifies the resulting archive | The current date and time |
The four decisions that make a backup specification complete
A Worked Backup Specification
Decomposing a General Backup Goal
Turn the general goal "create a backup system" into a complete specification.
Identify the files: State the files to back up as a concrete list rather than leaving the program to guess what belongs in the backup.
Identify the location: Specify the main backup directory so the program has a defined place to write the archive.
Identify the format: Choose the archive format. The standard specification uses zip.
Identify the name: Define a naming scheme based on the current date and time so the archive naming rule is explicit.
The vague goal has become a four-part specification: a file list, a main backup directory, the zip format, and a current-date-and-time naming scheme.
The example does not yet implement the backup. It establishes the contract that an implementation must satisfy. This distinction is important: analysis and decomposition happen before code, and their output is a blueprint for the design phase.
Choosing the Archiving Tool
After the backup requirements are defined, the program still needs a tool that creates the archive. An archiving command reads files and writes them into a compressed archive. The key selection requirement is that the tool must support invocation from the command line.
| Choice | Status | Reason |
|---|---|---|
| zip | Acceptable and standard | It is available by default in a standard GNU/Linux or Unix distribution and supports command line invocation. |
| tar | Acceptable if command-line capable | The requirement allows any command line archiving tool. |
| 7z | Acceptable if command-line capable | The requirement allows any command line archiving tool. |
| rar | Acceptable if command-line capable | The requirement allows any command line archiving tool. |
When Requirements Are Incomplete
Listing files and a destination but omitting the naming scheme
The program does not have a complete rule for identifying the resulting archive.
Fix:
Define a naming scheme based on the current date and time.Defining files and a format but omitting the storage directory
The program has no specified place to write the backup.
Fix:
Specify the main backup directory.Treating the general goal as if it were already an implementation plan
A broad goal does not identify the files, location, format, or naming scheme that the implementation must follow.
Fix:
Decompose the goal into the four required components.Selecting a tool without checking command-line support
Command-line invocation is the required criterion for the archiving command.
Fix:
Choose zip or another archiving tool that supports command-line invocation.
The Specification as a Contract
A finished specification is a contract between the problem and the solution. It answers the question, "What must the program do?" For the backup problem, the specification state is reached only when the file list, storage directory, archive format, and naming scheme have all been decided.
This contract improves implementation because it gives the code a clear target. An incomplete or ambiguous specification leads to an incomplete or ambiguous implementation. A clear specification reduces misunderstandings and rework, and makes the coding phase more reliable.
A backup requirement currently says only: "Make a backup of the project." Decompose this statement into the four requirement areas that must be settled before implementation.
Hints
- Ask what exact input content the backup should contain.
- Ask where the archive should be written.
- Ask what archive format is required.
- Ask how the resulting archive should be named.
- Files to back up: define a concrete list.
- Storage location: define the main backup directory.
- Archive format: define zip as the standard format in this specification.
- Naming scheme: define the current date and time.
Key Takeaways
- Problem analysis translates a vague programming goal into concrete, measurable, and unambiguous requirements.
- A complete backup specification defines the files, storage location, archive format, and naming scheme.
- Every one of the four components is necessary; omitting one leaves implementation-critical information unresolved.
- The archiving command is flexible, but it must support command-line invocation; zip is the standard choice.
- A complete specification acts as a blueprint and contract for the implementation.