Functional Specification...What the heck is it?

As usual, When I was looking for some information about writing Functional Specifications, I stumbled upon this nice article by http://www.joelonsoftware.com.

The part I liked most is the comparison between a project which is started without a FS and another project which is started with complete FS. Also, the author elaborated nicely about the advantages and benefits of writing FS from not just developer/project manager point of views, but as well from QA team, Documentation team, Marketing team, Managers and even Biz Dev people who are going to market that product!

The keyword is communication. If there is a cleanly written FS, it helps in many ways to communicate the information/details about the product well throughout the organisation!

some excerpts from the article...(Courtesy http://www.joelonsoftware.com )

....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. 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 (that gets lost or thrown away, but that's a different story). The managers read it so that they can look like they know what's going on in management meetings. And so on....

When you don't have a spec, all this communication still happens, because it has to, but it happens ad hoc. The QA people fool around with the program willy-nilly, and when something looks odd, they go and interrupt the programmers yet again to ask them another stupid question about how the thing is supposed to work. Besides the fact that this ruins the programmers' productivity, the programmers tend to give the answer that corresponds to what they wrote in the code, rather than the "right answer." So the QA people are really testing the program against the program rather than the program against the design, which would be, um, a little bit more useful.

When you don't have a spec, what happens with the poor technical writers is the funniest (in a sad kind of way). Tech writers often don't have the political clout to interrupt programmers. In many companies, if tech writers get in the habit of interrupting programmers to ask how something is supposed to work, the programmers go to their managers and cry about how they can't get any work done because of these [expletive deleted] writers, and could they please keep them away, and the managers, trying to improve productivity, forbid the tech writers to waste any more of their precious programmers' time. You can always tell these companies, because the help files and the manuals don't give you any more information than you can figure out from the screen. When you see a message on a screen which says

Get your download from : http://www.inleadmedia.com/files/PainlessFunctionalSpecifications_34.doc

Happy Reading...