Designing a Solution
Designing a solution begins by converting that broad goal into requirements that are concrete, measurable, and unambiguous.
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 what you want in general, but it does not yet tell a program exactly what to do. Designing a solution begins by converting that broad goal into 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, what archive format will be used, and how the resulting archive will be named. These decisions create a target that implementation can follow.
The Four Backup Decisions
A complete backup specification has four distinct components. Each one answers a different question about the backup process. Together, they describe what is included, where the result goes, how it is packaged, and how it can be identified.
| Requirement | Question it answers | Specified form |
|---|---|---|
| Files to back up | What should the program include? | A list of files |
| Storage location | Where should the backup be written? | A main backup directory |
| Archive format | How should the files be packaged? | Zip |
| Naming scheme | What should identify the archive? | The current date and time |
The four decisions needed for a complete backup specification
A Worked Backup Specification
Replacing a vague goal with four decisions
Specify a backup program without leaving its behavior ambiguous.
- 1Start with the goal
The broad goal is to create a backup system. This identifies the problem area but does not yet provide enough information for implementation.
- 2List the files
Define the files to back up as a concrete list rather than referring generally to important files.
- 3Choose the destination
Designate a main backup directory as the storage location.
- 4Choose the format
Specify zip as the archive format.
- 5Define the name
Use the current date and time as the naming scheme for the resulting archive.
The goal has become a complete specification containing a file list, a main backup directory, the zip archive format, and a naming scheme based on the current date and time.
The important change is not merely adding detail. The specification removes decisions that would otherwise be left unresolved during implementation. A developer can use the completed specification as a blueprint because each major part of the backup process has been addressed.
Choosing the Archiving Command
After the backup requirements are defined, the program needs an archiving command to create the archive. An archiving command reads files and writes them into a compressed archive. The key selection criterion is that the command must support invocation from the command line.
| Choice | Relationship to the requirement | Selection status |
|---|---|---|
| zip | A standard command-line archiving choice and the specified archive format | Acceptable |
| tar | An archiving tool that can be invoked from the command line | Acceptable |
| 7z | An archiving tool that can be invoked from the command line | Acceptable |
| rar | An archiving tool that can be invoked from the command line | Acceptable |
| A tool without command-line invocation | Does not satisfy the command-line requirement | Not acceptable |
The command-line interface is required; the specific archiving tool is flexible.
Requirements as a Design Contract
Once the four decisions are fixed, the problem-solving phase has moved into the design phase. The specification acts as a contract between the problem and the solution: it states what the program must do before any code is written.
A clear specification gives implementation a clear target. An incomplete or ambiguous specification leads to incomplete or ambiguous implementation because important decisions remain unresolved. Defining requirements is therefore part of solving the problem, not separate administrative work.
Common mistake Defining only which files to back up
What it looks likeThe specification contains a file list but does not identify a storage directory, archive format, or naming scheme.
Why it failsThe backup process is still missing critical decisions, so the specification cannot fully guide implementation.
Do this insteadDefine all four components: files, storage location, archive format, and naming scheme.
Common mistake Leaving the destination vague
What it looks likeThe requirement says to create a backup but does not identify a main backup directory.
Why it failsThe program has no specified place to write the backup.
Do this insteadDesignate a storage location as part of the specification.
Common mistake Treating the broad goal as the finished solution
What it looks likeThe only requirement is create a backup system.
Why it failsA general goal does not state the concrete behavior the program must satisfy.
Do this insteadTranslate the goal into specific decisions about the files, location, format, and name.
Common mistake Requiring one tool without checking the actual command criterion
What it looks likeThe specification rejects every tool except a particular named archiver even though the requirement is command-line invocation.
Why it failsThe archiving-tool requirement is flexible; the essential criterion is support for command-line use.
Do this insteadAccept an archiving command that can be invoked from the command line, including zip, tar, 7z, or rar.
Before implementation begins, check the specification as a four-part checklist. If the file list, storage location, archive format, and naming scheme are all defined, the backup process has a complete set of core requirements.
Requirement Design Practice
A teammate says, “Make a backup of the project.” Rewrite this as a complete backup specification. Your answer should identify the files to back up, the storage location, the archive format, and the naming scheme. Then state what criterion an archiving command must satisfy.
Hints
- Use a concrete list for the files rather than a general phrase such as important files.
- Name a main backup directory as the storage location.
- Use zip as the archive format and the current date and time as the naming scheme.
- The command must support invocation from the command line.
What do you think happens?
If a backup specification names the files and storage directory but omits the naming scheme, is it complete?
Reveal answer
No, because one of the four core requirements is missing.
The naming scheme is a distinct, non-negotiable component. Without it, the program does not know what to call the resulting archive.
A Complete Design Target
- 1Designing a solution starts by translating a broad programming goal into concrete, measurable, and unambiguous requirements.
- 2A complete backup specification defines the files to back up, the main backup directory, the archive format, and the naming scheme.
- 3Each of the four requirements serves a distinct purpose; omitting one leaves the specification incomplete.
- 4The archiving command must support command-line invocation, while the particular command can be flexible.
- 5A finished specification serves as a blueprint and design contract for the implementation.
Key Takeaways
- A general goal is not yet a solution; requirements must make the intended behavior concrete and unambiguous.
- Backup requirements have four core components: files, storage location, archive format, and naming scheme.
- The archiving command must be usable from the command line, but the specific tool is flexible.
- A complete specification creates a clear implementation target before coding begins.