Your biggest problem is a toxic work environment.
As you note,
we yell at the technical person telling him almost literally that he is "not smart" enough to understand what we are trying to do.
If someone were to do that to me, I'd immediately demand an apology. If I didn't get one, it'd clearly be time to update my resume... or perhaps even go to HR and make sure the other person updates their resume. A work environment where people resort not just to blaming, but to outright insulting others' capabilities, is not one that could be considered acceptable nor healthy.
Either your concerns are founded (he's not smart enough), or they're not. If they are founded, then just fire him and get a new one. Don't waste time with insults. If they're not founded, you're burning a valuable bridge here. Sooner or later he's going to quit and, depending on the size and nature of the local talent pool, he may warn other potential hires to steer clear of your company. You'll be stuck with the bottom of the barrel - developers too desperate to avoid applying to work at your company, and also too complacent to quit despite the toxic environment.
There are two main (broad) approaches to solving your requirements problem.
Broadly speaking, you can solve this in a traditional way, or an Agile way - or in some mixture of the two.
If you want to go the traditional route, then before the developer even starts working (and, consequentially, before the schedule 'starts'), the requirements need to be defined, then sent to the developer. Then the developer needs to redefine the requirements in terms that he understands; in what he plans to give the (internal) client. Then the client needs to look over the new, developer-defined requirements, and sign off on them. Then the developer starts working. And then, at the end, when the client complains that they don't have what they asked for, the developer is entitled to reply "Not my problem. You signed this off."
There are other ways to go about it, but the general goal is to ensure that there is agreement between the clients and the developer on the requirements before any work is done. The better that agreements is mutually understood (and the less the requirements change afterward, see below), the better off you'll be.
The biggest problem I've found with the traditional approach is changing requirements. Not only do actual requirements change over time (new technology comes out, an important contract falls through, etc.), but users never actually even know what they need, until that need is fulfilled.
Agile therefore eschews rigid planning for iteration and adaptation. The developer works for a week or two (or a day or three, etc. - exact time doesn't matter much, as long as it's short), then shows what he's made to the client. At which point the client tells the developer what to change. At this point, it would be downright curmudgeonly to call the developer stupid for not getting the requirements right - not much time was spent on them upfront, and only a short amount of development time has been spent. And with the next iteration, the product becomes a little closer to what the client needs, then a little closer, then a little closer, until they're finally satisfied.
As noted, there's no reason you couldn't combine the two, to a point. Start with the upfront requirements gathering/agreement, and sign it off. Then work on it for a short time, show it to the client, update the plan, and sign it off again. Then repeat.
