in reply to
They don't specify because they don't know what they want
This is a very common problem when creating software systems. More often than not, the customer comes to you with a problem they want solved. They usually have a rough idea of what they want in order to solve the problem, but that rough idea is usually a lot rougher than we'd (as developers) like.
There are a number of things that can be done to counter this, and you've already hit on a number of them, such as giving the customer more time to influence the project and also to get them more invloved in the project. The second concept, getting the customer involved, is VERY important. If the customer sits back and simply waits for results (and you allow them to), 99% of the time, you're going to give them a final project that isn't what they expected and probably doesn't do what they wanted it to. Obviously, this is not a good situation. You need to actively get the customer involved. Bother them. Question them. Keep hacking at the problem until both of you know exactly what the system is supposed to do. If you do a good job of this, what you eventually hand over to the customer will be exactly what they expected and they'll be much happier with the project.
So how do you keep the customer involved? Like I said, keep questioning them. Try to identify anything about the project that you don't know for certain - anything from how something should be displayed on the screen to complicated business rules. Believe me, your customers like to feel like they know their business (don't you like to feel like you know how to write software?) and they'll be more than happy to talk to you about how their business runs. This is a good way to get the customer involved right away.
Another good method of getting the customer involved and verifying concepts is to create a rapid prototype. This is a rough mock-up of the final project that doesn't do a whole lot, but it lays out the basic interface and "look and feel" of the final project. Showing this to the customer can help identify and resolve issues with future functionality and interface early in the development process. Of course, rapid prototyping isn't without problems of its own - look here for a fairly extensive node on the subject.
Of course, one danger with this whole process is to allow the customer to alter the projet requirements throughout the entire process. At some point, you need to be able to "sign off" the requirements and tell the customer that this is what you'll be getting. At that point, the requirements have been worked out to the point where the customer will get what he/she needs from the project and you will be able to complete it on time. Once the customer signs off, the project need to go into some form of "change control." By that, I mean that the customer should have very limited ability to change the project. Only absolutely necessary changes should be made (something that would cause the project to fail that had been overlooked). Why must this be done? If you allow the customer to keep adding new features as the project advances, you'll run into the horrible beast known as scope creep. Soon, you'll end up with a project so large that you'll be unable to maintain it or add to it. This is a very nasty situation to get into. After that sign-off, any new features that the customer wants should go into a later release of the software or some such thing.
So I've babbled quite a while about this topic. It really all comes down to one thing that you've already hit on - customers seldom know what it is that they really want. There are ways to get around this (which I've been trying to outline here), but the most important thing to do is to know, ahead of time, that your customer is clueless. Not that they don't know business, but they don't necessarily know your business. It is our job, as develoers, to teach them as much about our business as we need to learn from them about theirs.
Skepticism is the source of knowledge as much as knowledge is the source of skepticism.