Designing a Solution
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 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.
Start 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.
List the files: Define the files to back up as a concrete list rather than referring generally to important files.
Choose the destination: Designate a main backup directory as the storage location.
Choose the format: Specify zip as the archive format.
Define 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 |
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.
Defining only which files to back up
The backup process is still missing critical decisions, so the specification cannot fully guide implementation.
Fix:
Define all four components: files, storage location, archive format, and naming scheme.Leaving the destination vague
The program has no specified place to write the backup.
Fix:
Designate a storage location as part of the specification.Treating the broad goal as the finished solution
A general goal does not state the concrete behavior the program must satisfy.
Fix:
Translate the goal into specific decisions about the files, location, format, and name.Requiring one tool without checking the actual command criterion
The archiving-tool requirement is flexible; the essential criterion is support for command-line use.
Fix:
Accept 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
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
- Designing a solution starts by translating a broad programming goal into concrete, measurable, and unambiguous requirements.
- A complete backup specification defines the files to back up, the main backup directory, the archive format, and the naming scheme.
- Each of the four requirements serves a distinct purpose; omitting one leaves the specification incomplete.
- The archiving command must support command-line invocation, while the particular command can be flexible.
- A 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.