C2 wiki on functional specifications suggest that this can be facilitated by tools, how?
A Functional Specification is a list of demands and constraints intended to describe a product to be designed and built…
…tools for describing software products have been developed to the point that functional specs are no longer of any use.
Why not just type a structured Word document?
Best Answer
Functional specifications are typically presented as a document, but depending on your purposes, creating the specification in Word may not be the best choice. There are other options - word processors, spreadsheets, and requirements management tools (1, 2) are some common tools used to create and maintain functional specifications.
Requirements management tools (I'm familiar with IBM Rational DOORS, but there are others) are essentially requirements databases that support creating, maintaining, tracing, and generally managing requirements. Some tools support importing from documents and spreadsheets, as well as outputting into these formats. Internally, they allow you to capture requirements as unique objects (think a row in a database, where each requirement has various attributes). You can also manage changes, by tracing other items (lower level requirements, design artifacts, tests) and seeing what may have to change if a requirement changes.
Spreadsheets, to me, are a step lower than a formal requirements management tool. They support more of the requirements management functions (traceability, tracking various attributes in line with the requirement statement, managing changes).
Of course, you can always do what you suggest - start a well formatted document in your favorite word processor to capture software requirements. However, it is more difficult to ensure some aspects of good requirements. Specifically, traceability (often implemented via requirement IDs) becomes more difficult and the text associated with a requirement needs to be more verbose to capture importance and verification method.
I don't think that any tool has superseded functional specifications. I do think that processes and how tools are used have superseded the traditional idea of a functional specification document.
In agile methods, requirements are often captured as use cases and user stories. In this environment, your functional specification may be uploading your use cases and user stories in some electronic format to a file store or wiki. Even in more plan-driven methods, the use of requirements management tools have replaced the document, where a document is only generated as necessary to provide requirements to external entities.
At the end of the day, the purpose of a requirements specification (functional and non-functional) is to somehow capture what the software is supposed to do (and, after it's finished, what it does in its current state). This set of characteristics drives testing (especially system and acceptance testing). More important than creating a functional specification document is ensuring that the customer and development organization (the design team, the development team, and the test team) are on the same page when it comes to what the system is supposed to do.