A lot of clients ask how they should write a specification for a piece of software, what it should include and how it needs to be written. Usually they're actually talking about an informal requirement (a software developer needs to know what the client wishes the software to do).<p>This leads to sharing my favourite definitions of requirements and specifications; they are from Practical Cryptography by Niels Ferguson and Bruce Schneier.<p>Chapter 9, Pages 131-132.<p>"Requirements<p>Requirements are an informal description of what the program is supposed to achieve. It is really a "what can I do with it" document, rather than a "how exactly do I do something with it" document. Requirements are often a bit vague and leave details out in order to concentrate on the larger picture.<p>Functional specification<p>The functional specifications give a detailed and exhaustive definition of the behavior of the program. The functional specification can only specify things that you can measure on the outside of the program.<p>For each item in the functional specifications, ask yourself whether you could create a test on the finished program that would determine whether tat item was adhered to or not. The test can only use the external behavior of the program, not anything from the inside. If you can't create a test for an item, it does not belong in the functional specification.<p>The functional specification should be complete. That is, every piece of functionality should be specified. Anything not in the functional specification does not have to be implemented.<p>Another way to think of the functional specification is as the basis for testing the finished program. Any item can, and should, be tested.<p>Implementation Design<p>This document has many names, but it specifies how the program works internally. It contains all of the things that cannot be tested from the outside. A good implementation design will often split the program into several modules, and describe their functionality. In turn, these modules descriptions can be seen as the requirements for the module, and the whole cycle starts all over again for the module."