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.
- 1Identify the files
State the files to back up as a concrete list rather than leaving the program to guess what belongs in the backup.
- 2Identify the location
Specify the main backup directory so the program has a defined place to write the archive.
- 3Identify the format
Choose the archive format. The standard specification uses zip.
- 4Identify 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. |
The tool is flexible; command line invocation is the required criterion.
When Requirements Are Incomplete
Common mistake Listing files and a destination but omitting the naming scheme
What it looks likeThe specification says what to back up and where to store it, but does not say what to call the archive.
Why it failsThe program does not have a complete rule for identifying the resulting archive.
Do this insteadDefine a naming scheme based on the current date and time.
Common mistake Defining files and a format but omitting the storage directory
What it looks likeThe specification says to create a zip archive from a file list but does not identify a main backup directory.
Why it failsThe program has no specified place to write the backup.
Do this insteadSpecify the main backup directory.
Common mistake Treating the general goal as if it were already an implementation plan
What it looks likeThe instruction is simply to create a backup system.
Why it failsA broad goal does not identify the files, location, format, or naming scheme that the implementation must follow.
Do this insteadDecompose the goal into the four required components.
Common mistake Selecting a tool without checking command-line support
What it looks likeA tool is chosen without establishing that it can be invoked from the command line.
Why it failsCommand-line invocation is the required criterion for the archiving command.
Do this insteadChoose 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.