I just finished reading a book that strongly recommended you do not write a functional specification for your web application. The book stated that such a spec leads to all kinds of problems. In fact, it stated that the only people who are interested in such a spec are those people who really don't have anything else to contribute to the project. On the surface, this recommendation seems to make sense.On my own project, we used to have a mammoth functional specification document for each of our applications. These documents actually contained both the application requirements and design together. That's what added to their size. The funny thing is that, even though it was a chore to keep updated when the new requirements came in, it was a very useful document. The spec always informed us what the correct and required behavior was. Many times the customer would complain and issue trouble tickets on our software. The spec saved us a number of times by authoritatively documenting the correct behavior of the application.
Some time ago, the project manager decided to move away from this functional specification style of documentation. Instead we would separate design and requirements. Unfortunately, now the requirements are stand-alone and are hidden in some requirements tracking system. And now the newly created design documents are light and do not contain enough information for anyone to make much use of them. It is strange. Our customers and even our own developers find ourselves going back to the functional specifications to get the real details on different parts of the applications. This experience may differ, but I am wholly unconvinced that a specification, in and of itself, is evil.
