Depending on who you believe, functional specs are either an absolute must or something to be avoided like the plague. While I vacillate on the necessity of written docu, if pressed I trend towards the 37signals approach - the code never lies (misleads, sure) and iterating code tends to provide better answers anyway. That said, there have been occasions where I *really* would have liked something more concrete than “it has to be like the old system…only better” or “the requirements are whatever I say they are”. While I’ll concede the need to write something down, I’ve seen many examples that go a bit, ah, overboard when it comes to specs. Seriously, if it needs a table of contents and an index, it’s time to pare it down a bit.
The struggle comes down to purpose: why do we write functional specs? Some companies believe they should be the complete conveyance between customers and developers - when you get there, you’re in trouble. By the time you’ve finished writing down every possibility (and sat through many, many mind numbing meetings), chances are the business has changed three or four times obviating all of your hard work.
So the question is, what should a requirements document provide? Agile mentor Venkat Subramaniam nails this issue right on the head - instead of trying to map every fork, provide enough depth to help the developer explore the issues.
Rather than providing answer to all my questions, I would like for it to help me ask the right questions when I am ready to delve into the implementation.
A great requirements document helps me not with right answers, but with right questions.
Keep this in mind next time you sit down to write a spec - it should aide communication, not supplant it. Help your devs ask the right questions, don’t try and answer every single one.
