I've found that almost no matter what you do, the customer doesn't always know what they want. What they want and what they say that they want, can very easily be two different things, because they don't know the right verbiage to ask for.

I just try to be as clear as possible. For instance, if they want to do inventory with the system. Then I'll explain what the inventory system will do. "I'll build you a form where you can pick from a combo drop down list of parts and manually enter a number and press a process button to remove or add to the inventory". I may even create an example image to send them, it only takes a minute to create the form with no coding or "looking good", just a plain idea visual. This sometimes will bring up their questions of "well would I be able to change the price at the same time or assign a vendor to them?". In which case we can get that done right away. Otherwise, I figure I've done the best I can, built them exactly what I told them I would, and if we have to rebuild stuff it's on them and it's just going to add additional time to the job.

Create a list of Requirements.
Spell out step by step the functionality you are going to build.
Draw a process flow, if it helps, to explain the things you want to achieve.
If you can provide walk throughs of your current development.
Get a sign off after each demo.
You are welcome to change features but set expectations of if you now want x then you can't have y.

If you develop for an industry, there may be certain industry standards you need to adhere to.  For instance, how long should a name field and an address field be?  30 characters, 40, or more?  It turns out there is an industry standard.  The pictures below are documents made by ANSI (American National Standards Institute), giving a guideline on how such data should be specified.  This particular guideline is for an electronic invoice.  In my old job, we received electronic orders from customers, and we billed them by sending electronic invoices back to them.  These documents had names and addresses, naturally, and all the data had widths that were agreed upon by both parties.  That's because you can't have someone sending 40-character address fields to someone whose computer system can only accept 30-character addresses.  So ANSI decided that a name can have up to 60 characters, and a street address can have 55 characters, as shown below.  All parties should have a computer system that can handle that.

I worked in garment retail, and we made UPC hang tags like the one pictured below.  ANSI again decided that style numbers, color names, etc. cannot exceed a certain length -- for the obvious reason that a hang tag isn't wide enough to show them if they are too long.  So it is usually decided that a style number or color can be 10 characters or less.

Should an invoice number be numeric or alphanumeric, and how wide should it be?  According to the same ANSI document, an invoice number can be a 22-character wide alphanumerical data (e.g. ABC1234567890...).

These kinds of industry guidelines usually exist because they help professionals who are in your position so you are not completely in the dark when you make specifications for your database.

Thanks everyone for the information!

Be clear to yourself what you need to do for this and get get it in writing on the quotation provide.
go over all details before distributing and make sure you developed what they asked for!
Hope these two screen shots is good enough!!!

Thanks Abraham, I like the project database and the quote process.