You probably will want to read Software Fundamentals. Collected Papers by David L. Parnas.. In the papers in this book, Parnas not only gives a formal definition of what a specification is (and how a program can be said to fulfill it), but also contrasts it with other related concepts (model, prototype, description) and gives some useful techniques to improve the writing of specifications.

If one goes straight to the commonsense meaning of "specification", a specification is nothing more than a statement of what we want to build. Given this definition, I have not seen any manager or customer resist working up at least a short specification for the work to be done.

The real problem IMHO is to choose the detail level necessary for a specification. If chosen too deep, the specification will strongly resemble the program to be built. If chosen to high, the specification will be meaningless to the programmer.

Usually, managers or customers will start with an extremely high-level specification. The trick seems to be how to get them to provide more detail, without swamping them with technicalities that they don't want to see and that they probably can't absorb.

In my experience, focusing on these items will provide relatively useful specifications that can be agreed upon in minimal time (e.g., 15 minutes to an hour for a 2 day programming project):

• critical success factors - what objectives the project has to fulfill to be considered a success
• user screens (pencil drawing) or other example inputs and outputs
• rough description of data to be handled from user point of view
• any functionality that is *not* just create/update/delete for the data items (security is always worth a question)
• performance constraints (interaction time for user screens, maximum batch loads, etc.)
• budget available (time or money) - very important - this is your negotiation parameter!
• who will make the decisions on this project (your direct customer)
• contacts for further questions

If a manager or customer resists discussion of these items, I usually try to get to his reasons for doing so (feelings of over-complication of trivial tasks, no time, not responsible, etc.) and to counter each one with a proposal on how to go on (explain I don't understand as much about his business as he does, ask to be given a date for a short meeting, asking who else can I ask, etc.). If really nobody can or wants to give you a specification, another option is to declare the project a "Research and Development" project, and to proceed in tight feedback loops with users and other participants to the project. Most of the time, a suggestion like this makes the argument for writing up a specification. The rest of the time - well, you have hit upon a nice playground - or you are being chosen as The Scapegoat (tm). Make sure you got a budget to play with to make the decision.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com