When creating software, you will encounter some requirements that are very hard to fulfill, and others that are quite easy to manage. Unfortunately, the difficulty of implementing something is not necessarily proportional to the impact it has on the final product. The result is that non-programmers have difficulties to write specs for a software (unless they learn how to do it) -- it will simply not occur to him or her where the real difficulties for the programmer lie. They will see the problem in their context, and not in the context of programming.

The result is that as a software developer, it is your job to help the guy that's having a problem. You will have to understand the problem in his domain, transfer it over to yours, solve it and transfer the solution back into his domain (This is a vast oversimplification, of course). At the same time, you will have to communicate your needs.

Fortunately, I am able to deal with this quite well in the small shop where I work. My boss is not a programmer, but as a new project approaches, we take the time to sit down and talk about what I need to know and what needs to be specified. This makes it a lot easier to plan ahead, especially when the client's expectations (as usual) are a moving target. Because he then has the background knowledge where the real difficulties lie in the project, he can better deal with the client and fence off requests that would endanger the project -- or at least communicate to the client the costs these changes imply.