More on Functional Specifications

Then there are FS documents which get into details of technical design. May be the author, with a good intention to give a heads up to the development team, points out the programs to be analyzed for impact and enhanced if required. Other times, the author is not aware of the existing system functionality and works backwards from the existing code and prepares the FS by analyzing the existing code. This is not the right way to write a FS. However, in absence of proper supporting documentation, and may be lack of time from the end users to explain the current system behavior, there is no other alternative for the FS author, other than looking into the existing source code to find out what the system does. However, if the author is not technically sound, he does not figure out completely what the functionality is, and just dumps the code into the FS for the development team to figure out what to do with it. This is not the right way to go about it! What the author of the FS does not understand is that the FS is supposed to give the behavioral aspect of the system and not how this behavior is to be achieved. How that behavior is to be achieved is a question for the design/development team to grapple with. A FS as the name suggests should give only the emergent functionality of the system. There should be mention of different interfaces in the system and how the interfaces interact with each other, but rarely ever any code to tell how it may be achieved.