Functional Specs
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.
July 31st, 2006 at 6:15 pm
[…] Michael Mahemoff picked up on my recent ramblings about functional specs and adds his own 5 cents (in my mind, his thoughts are worth more than just a couple of pennies). I agree with Michael with regards to the dichotomy - like most things in life, docu needs exist on a continuum. If I’m just writing a simple little app for my own use, I probably won’t write much of anything beyond the code but if I’m reworking the software that keeps planes in the air, well, chances are I’ll need to jot a few things down! […]
February 23rd, 2008 at 2:28 pm
[…] Nate’s talking about functional specs. […]