I've never been a fan of detailed or formal requirements docs for
software or other projects, as I've found the customer's needs
always change and sticking to a pre-made list is impossible. But
there has to be *something* to start with, something reasonably
detailed enough to make an estimate (and I recommend doubling that
before telling the customer). I got an email from a potential client
recently:
"...help me in setting up an already purchased server, programming
of some modules in Perl and handling in cron jobs for one of my
projects. I would appreciate a quick turnaround time."
Apparently, this was enough detail to come up with a fixed-bid
estimate - even after I challenged and asked for more detail.
Another example - a friend of mine wanted me to develop a web-
based, database enabled app with user, admin and reporting
interfaces, calendaring and email hooks. This was supposed to be an
easy project I could put together one night, in my spare time.
Sometimes conveying the scope of a project is hard. Hidden from the
casual user is how a software app works under the hood (all-too
frequently behind a web browser). When you've been doing project
work for a while, you get a sense for where the pitfalls and time-
sinks lie, it's just hard getting clients to see them. I'm sure I've
heard this analogy somewhere before, but projects like these are
like icebergs - the part you see is just the smallest part.
Unfortunately, to your clients, this part is all that exists.
