Testing Against Requirements
Specifying program requirements means translating a vague problem into concrete, measurable specifications that leave no room for ambiguity.
From Goal to Specification
A request such as create a backup system describes a general goal, not a complete program. Before implementation can begin, the goal must be translated into concrete, measurable requirements. For a backup program, the specification must state which files are included, where the backup is stored, what archive format is used, and how the archive is named. These decisions turn an intention into a target that implementation can follow and testing can check.
The specification is a contract between the problem and the solution. It answers what the program must do before code is written.
The Four Required Decisions
A complete backup specification has four distinct components. The files to back up identify the input. The storage location identifies the main backup directory where the result will be written. The archive format identifies how the files are packaged, with zip as the specified format in the backup requirements. The naming scheme identifies what the resulting archive is called, using the current date and time. Each component answers a different question, so one cannot substitute for another.
Completing an Incomplete Backup Request
A request says: Back up the project files into the backup area.
Identify the missing file requirement: The request does not provide the list of files to back up. The specification must identify the files concretely.
Identify the missing location requirement: The phrase backup area does not define the main backup directory precisely enough. A storage location must be designated.
Identify the missing format requirement: The request does not state how the files will be packaged. The archive format must be defined as zip for this specification.
Identify the missing naming requirement: The request does not explain what the resulting archive will be called. The naming scheme must use the current date and time.
The original request is a general goal, not a complete specification. All four components must be defined before it can guide implementation.
Checking Requirement Quality
Testing against requirements begins before the program exists. Inspect each requirement and ask whether it is concrete, measurable, and specific enough to guide implementation. A requirement is incomplete when it leaves a necessary decision unresolved. For example, naming the files and storage directory without defining the naming scheme leaves the program without instructions for what to call the archive. Naming a storage area without identifying the storage location leaves the program without a defined place to write the backup.
Choosing the Archiving Command
After the backup requirements are defined, an archiving command must be selected to create the archive. The key selection criterion is command line invocation: the tool must be usable from the command line. The specific tool is flexible. Zip is a standard choice and is available by default in a standard GNU/Linux or Unix distribution, but tar, 7z, rar, or another command line archiving tool is also acceptable under the stated requirement.
| Candidate | Meets the command line requirement? | Role in the specification |
|---|---|---|
| zip | Yes | Standard choice |
| tar | Yes | Acceptable command line alternative |
| 7z | Yes | Acceptable command line alternative |
| rar | Yes | Acceptable command line alternative |
Connecting Requirements to Tests
Once the four decisions are locked in, each one can be connected to a question about program behavior. The files requirement asks whether the specified list is what the program backs up. The storage requirement asks whether the archive is written to the designated main backup directory. The format requirement asks whether the result uses the specified archive format. The naming requirement asks whether the archive name follows the current date-and-time scheme. This connection gives every requirement a clear verification target without changing the requirement itself.
Reviewing a Backup Specification
Review this specification: back up the project files as a zip archive in the main backup directory, using the current date and time in the archive name.
Check the files component: The phrase project files identifies the intended input at a general level, but a complete specification requires the files to be defined as a list.
Check the location component: The main backup directory identifies the required storage location.
Check the format component: The specification explicitly chooses zip as the archive format.
Check the naming component: The specification states that the current date and time determine the archive name.
Check completeness: Three components are concrete, but the file input still needs to be expressed as a specific list before the specification is complete.
A specification can be mostly clear and still require clarification. Every one of the four components must be defined concretely.
Common Specification Mistakes
Starting implementation from the general goal alone
The goal does not define the files, location, format, or naming scheme.
Fix:
Translate the goal into the four required backup components before designing the solution.Leaving out the naming scheme
The program has no defined instruction for what to call the resulting archive.
Fix:
Define the naming scheme as the current date and time.Leaving out the storage location
The program has no designated place to store the backup.
Fix:
Identify the main backup directory.Treating zip as the only acceptable command
The requirement is that the archiving command support command line invocation; the specific tool is flexible.
Fix:
Use zip or another command line archiving tool such as tar, 7z, or rar.Using an ambiguous description instead of a concrete requirement
The files and storage location are not defined precisely enough to guide implementation or testing.
Fix:
Define the file list and the main backup directory.
Before considering a specification complete, read each of the four components as a separate requirement. If any component still depends on an unstated decision, clarify it before implementation.
Practice: Lock the Specification
A teammate says: Build a command-line backup program that saves the necessary files in an archive. Identify the missing decisions you would require before implementation. Then state the four components of a complete backup specification and explain what each one must determine.
Hints
- Separate the input files from the place where the archive will be written.
- Ask how the archive is packaged and how its name is formed.
- Check whether the chosen archiving command can be invoked from the command line.
- A useful specification removes ambiguity from a general programming goal. For a backup program, define the files to back up as a list, the main backup directory, the archive format, and the naming scheme based on the current date and time. Select an archiving command that supports command line invocation; zip is standard, but other command line archiving tools are acceptable. Finally, connect each requirement to the behavior it demands and the check that will verify it.
Key Takeaways
- Requirements translate a vague programming goal into concrete, measurable specifications.
- A complete backup specification defines the files, storage location, archive format, and naming scheme.
- Each of the four components is necessary; omitting one makes the specification incomplete.
- The archiving command must support command line invocation, while the specific tool may be zip or another acceptable command line archiving tool.
- Testing against requirements means connecting every requirement to the program behavior it demands and the check that verifies it.