Once upon a very long time ago I made a Requirements Gathering Document, based on a bunch of great information borrowed from several great people, a ton of influence from Mike Monteiro (if you haven’t read Design Is A Job you absolutely should), and some ideas and experience of my own updated over the years.
**** WeWeb Requirements Gathering <PDF> ****
It’s always stood me in good stead, and I’ve taught it to my students and mentioned it in a few talks and I get asked for copies or a link, so here it is.
Requirements are tough to get right, but they’re the thing that will kill any project (fast, but more likely slowly and painfully) and possibly some relationships if you screw them up. And the main problem is all of the unsaid stuff; the assumptions on both sides that nobody realises are being assumed, the things the client doesn’t know aren’t possible, or the things the client hopes you realise, or things that can’t quite be articulated but They’ll Know They Don’t Them Like When They See Them.
Make no mistake. It’s YOUR job to discover all that stuff, and connect the dots for them between the actual technology and their half-formed, wishy-washy desires. You’re selling them a service, so do it right. Go get the requirements. Properly.
In return, hopefully they won’t tell you it wasn’t what they asked for, it wasn’t what they expected, or you didn’t deliver what was agreed.
Once you’ve gathered your Requirements you can then produce a report for the client reiterating back to them what you understand the requirements to be, in plain English, asking them to make any corrections, and (importantly) detailing the (achievable) success criteria you agreed upon for the project. Get them to sign off on a copy of this to Start the project.
You can send this with a breakdown of Required and Desireable project elements in a Pricing Estimate/Quote, reiterating the success criteria, plus your payment terms. I suggest at least a 10% Retainer to start the project, a Midway 40% payment, and a Final payment. This prevents you running after people for money quite as much, and agreeing ‘success criteria’ prevents them arguing at the end that you didn’t meet their expectations. Don’t hand over the final code until the Final payment has been released. Say this in your Pricing Estimate. Add that prices are valid for 30 days from the Quote, in case something changes in your supply chain. You may also want to add that after completion anything more than a minor 30 minute code update will attract additional charges/require a new quote.
Good luck!
