Lowest level of detail for functional specifications to be useful
Where I work, people don't like to write specs. (Boy, anyone?) So they don't, unless they are forced by their bosses. If they are forced to write them, they keep them as short as possible. (By the way, they also include me.)
This leads to characteristics such as
- This software records the time between events A and B in the event log
- The name and path of the X parameter are specified in the configuration file in ini format.
- The software is active without having to log on to the computer (implementation as a Windows service).
This example is taken from a very small project and it worked out pretty well, but I don't think it will be enough for something more complex. I did not specify OS / hardware requirements because this is internal development and we have company or department standards covering them.
So my question is: What do you consider the absolute minimum level of detail in a functional specification for any non-trivial software?
source to share
IMHO the important thing about functional specifications (and all other formal methods / tools for software development and project planning (Yourdon, SSADM, PRINCE2, UML, etc.) is that they encourage good practice by making you think in common lines do not guarantee success, but they do contribute to success by formalizing good practice
Thus, the fact of creating FS is good, even if perhaps they could be better. Some planning and preparation is better than general is what a lot of developers do.
What should ideally go into FS? As much as necessary and as little as possible. Just because some functional specs cover X, Y, and Z doesn't mean yours should. If you get too prescriptive, you add unnecessary bureaucracy to simpler projects; accordingly, for complex projects, a prescriptive approach may prompt the developer to stop at the level of detail they really need to go for.
source to share