The external specification
Another important form of closure is that there
must be a document that describes what the software is supposed
to do, so when the software is done, we can compare it to this
external specification document to see if the software
does what it is supposed to do.
- An external specification should describe all possible inputs
to the program, and categorize every possible output that can
result from it, as a function of its inputs.
- Not only must a specification describe every feature, but
it must also specify every possible combination of features.
If this task becomes too difficult, your design may have
featuritis.
- Don't wait until after the software is done to write the
specification. It's best to write down first what you
think you're going to do, and pass that around for
comments. Once everyone is happy,
then proceed with the implementation while keeping the
spec up do date as the design (necessarily) changes.
Project documentation should be linked into the
list of active projects. This entire tree
is under RCS control so you can check out the active list,
modify it, and check it back in.
Next:
The internal documentation
See also:
Project development protocol
Previous:
The requirements document
Home:
Go to the TCC homepage
John W. Shipman, john@nmt.edu
$Header: /u/john/projects/RCS/specification.html,v 1.2 1995/05/30 17:39:52 john Exp $