In The influence of non-functional requirements, I wrote that putting together a ballpark cost for a software project is near impossible if you don't have any information about the non-functional requirements. Something I've witnessed recently is a situation where two organisations are engaged with each other on a software project with no understanding of the non-functional requirements.
In one case an organisation purchased an off-the-shelf product and another was a bespoke build. With the latter, the organisation in question needed a software project delivered and had a fairly good idea of exactly what they wanted, engaging a third party to bid for the work. To ensure that everybody had a mutual understanding of the problem, an initial scoping exercise took place, during which the third party was able to understand more about the business domain, clarify some of the ambiguities and put some initial thoughts around the architecture and design of the system.
Having seen some of the output from the initial scoping phase, it's clear that the bidding party had a good understanding of what the system should do and had even started identifying candidate technologies for the delivery phase. The thing they hadn't done, however, was to get to grips with the key non-functional requirements. Details on performance, scalability, availability, etc were all absent. From my experience of the business domain, I know and feel confident in saying that the non-functional requirements will make or break this particular system. Not having them specified is a lose-lose for both parties involved.
My advice is simple. If you're going to engage on a software project, regardless of whether you're using an internal or external team (particularly if using a fixed price model), you simply *must* define the key non-functional requirements as early as possible. Failure to do so will mean neither party will win.