The way you frame your question makes two assumptions.

First, it assumes that additional analysis work would reduce scope creep/change/drift/evolution to the point where it would be a non-issue.

Second, it assumes that estimation (budget and schedule) risk is dominated by requirements risk, i.e. if you had complete and detailed requirements, your estimate would be accurate enough to make estimation risk a non-issue.

In my repeated and painful experience, neither assumption is true.

No matter how hard you try, new requirements will emerge, just because both you and the client will be learning by doing the project. Sometimes these "creep" requirements add significant value to the software, and it's a shame if they can't be added because of some blood oath contract someone insisted upon, at the start of the project when collective ignorance about the project was a maximum.

And even if new requirements don't emerge, there is typically enough uncertainty associated with some technical gotcha, or just with estimation uncertainty in general, to put you in a bind. Is the team stable from project to project? Do they have control over the sales estimate? If not, no amount of additional analysis will save you.

Here's what I used to do when I was in your situation.

First, analyze whatever the prospect gives you for gaps. I found that preparing a Function Point analysis surfaced these really quickly, plus I could then do a metrics-based estimate. If the prospect will pay for this additional analysis, great, but do this on your own nickel if you have to. You won't have detail, but you will have reduced the chance that they (and you) missed a whole section of functionality because they were fixated on bright-shiny-object features and not the whole system.

Then, go after the biggest known source of risk first, before sinking a lot of time into anything else.

If it's a particular area of the requirements, go after that, preferably with something quick, interactive, and effective, like a requiremnts workshop (Ellen Gottesdiener style) or a prototype.

If it's a technical risk, build a proof (or sometimes, "poof") of concept. Or get a sample of the data you need to import. Data's always a source of fun and surprises.

If it's a newly formed team of uncertain effectiveness, specify, design, build, and release, if only internally, some portion of the project. Used in conjunction with an agile-methods-style point-based estimate, this can give you early calibration of your estimates.

Run the project using short-cycle iterative (agile) development if at all possible. Compared to a waterfall, it soaks up risk like a sponge instead of shattering. Better to have 70% of the features 100% done than 100% of the features 70% done (guess we'll have to skip most of our test plan...)

If you're stuck with a waterfall, go ahead with your SRS (or whatever you call a "functional specification"). Issue change requests early and often, every time you see drift off of the budget and timeline for any reason. Don't wait until your buffer is consumed and your budget is 2/3 gone before firing off the red flare.

Godspeed!

robert
www.ufunctional.com