http://www.joelonsoftware.com/articles/fog0000000033.html

The biggest complaint you'll hear from teams that do write specs is that "nobody reads them." When nobody reads specs, the people who write them tend to get a little bit cynical.

The fact that the spec was shelved (unread and unloved) when it was completed makes people feel like it was all a bunch of work for naught.

So. Specs are good, but not if nobody reads them. As a spec-writer, you have to trick people into reading your stuff, and you should also probably make an effort not to cause any already-too-small brains to leak out through eye-sockets.

Tricking people into reading your stuff is usually just a matter of good writing. But it's not fair of me to just say "be a good writer" and leave it at that. Here are four easy rules that you absolutely must follow to make specs that get read.

Rule 1: Be Funny

Rule 2: Writing a spec is like writing code for a brain to execute

Rule 3: Write as simply as possible

Rule 4: Review and reread several times

R ule 5: Templates considered harmful

http://www.joelonsoftware.com/articles/fog0000000034.html

When Microsoft started growing seriously in the 1980s, everybody there had read The Mythical Man-Month, one of the classics of software management. The main point of that book was that when you add more programmers to a late project, it gets even later. That's because when you have n programmers on a team, the number of communication paths is n(n-1)/2, which grows at O(n2).

Program manager (project manager) would own the design and the spec for products. Since then, program managers (project managers) gather requirements, figure out what the code is supposed to do, and write the specs. There are usually about 5 programmers for every program manager (project manager); these programmers are responsible for implementing in code what the program manager (project manager) has implemented in the form of a spec.

A program manager (project manager) also needs to coordinate marketing, documentation, testing, localization, and all the other annoying details that programmers shouldn't spend time on. Finally, program managers are supposed to have the "big picture" of the company in mind, while programmers are free to concentrate on getting their bits of code exactly right.

from http://www.joelonsoftware.com/articles/fog0000000036.html

This is the best source how to write functional specifictions where you can find best examples and explanaitons.

When you design your product in a human language, it only takes a few minutes to try thinking about several possibilities, revising, and improving your design. Nobody feels bad when they delete a paragraph in a word processor. But when you design your product in a programming language, it takes weeks to do iterative designs.

if you don't have a spec, you will always spend more time and create lower quality code. Here's why.

The most important function of a spec is to design the program . Even if you are working on code all by yourself, and you write a spec solely for your own benefit, the act of writing the spec -- describing how the program works in minute detail -- will force you to actually design the program. So that's giant reason number one to write a spec.

Giant reason number two is to save time communicating. When you write a spec, you only have to communicate how the program is supposed to work once . Everybody on the team can just read the spec.

Number three giant important reason to have a spec is that without a detailed spec, it's impossible to make a schedule. Not having a schedule is OK if it's your PhD and you plan to spend 14 years on the thing, or if you're a programmer working on the next Duke Nukem and we'll ship when we're good and ready . But for almost any kind of real business, you just have to know how long things are going to take, because developing a product costs money .

The QA people read it so that they know how the program is supposed to work and they know what to test for.

The marketing people use it to write their vague vaporware white papers to throw up on the web site about products that haven't been created yet.

The business development people misread it to spin weird fantasies about how the product will cure baldness and warts and stuff, but it gets investors, so that's OK.

The developers read it so that they know what code to write.

The customers read it to make sure the developers are building a product that they would want to pay for.

The technical writers read it and write a nice manual.

The managers read it so that they can look like they know what's going on in management meetings.