Why is it that time and time again projects end up with bad requirements? Why do the same project experiences and nightmares seem to happen over and over again?
Imagine this scenario - and it may hit home with you so it might not take too much imagination. You are an intelligent and confident leader. Let's say you're in charge of the project and you have a leadership role in seeing that requirements get documented well. You've been educated in the ways of project management and understand the importance of good requirements definition. You started your last project strictly adhering to a textbook method of project planning and requirements definition, only to find that the ideas weren't catching on with your team.
Before you could figure out why it wasn't working with the team, your supervisor requests a progress update (since this is a very visible project). It seems like a career-killer to tell him that you're still trying to figure out what to do, so realize that you must get something going and you decide you're too busy to implement a new process designed to help you do things the right way.
Now, as deployment looms, you wonder how you got to this very same point that you've landed in with other projects. The same set of lessons learned, the same issues and rework, the same frustrations. They are all there all over again.
Before you can change anything, you have to realize and accept that there is a gap between textbook planning and cultural forces that is making it difficult to change the processes. Since I'm located in Las Vegas - let's look at this from the American culture standpoint.
Three American cultural forces - impatience with time, acceptance of mistakes, and the urge to improvise - often cause the biggest headaches on project development tasks.
Let's look at each of these in more depth.
Impatience with time
In the American culture, we want it all and we want it all right now. Customers want their project or product ready yesterday - no matter how many changes they asked for. Product developers and application developers are all about creating things - they don't want to wait. 
They want to start working on a solution right away. Often, they look at requirements as things that get in the way of creativity and the real work of creating the solution. The design started forming in their heads during the first meeting. For many of them, their experience with requirements definition has always been long, boring meetings over vague documents that, in the past, were rarely ever referred to again during the design process.
Moving too fast into design can result in a solution built to several different interpretations of requirements. These poor interpretations of requirements are then built into the solution and are very hard and costly to fix later when everyone realizes that your solution doesn't match the customer's wants and needs.
Acceptance of Mistakes
America has often been called the land of comeback opportunities. Everyone gets a second, third, fourth, fifth chance and so on chance. In the US, we tend to forget the trials and tribulations of the process and focus only on the end result, saying 'Because it worked out okay, there's nothing to learn.' In fact, we admire comebacks more than people who never failed in the first place. We honor them. We are more loyal to a supplier who quickly fixes a mistake he makes than we are to a supplier who never makes a mistake.
Most people in project and product development assume that mistakes are inevitable. Some mistakes are. However, we often confuse preventable mistakes with inevitable ones. Poor preparation and inadequate understanding of customer requirements result in what I'm referring to as preventable mistakes. There's really no honor in scrambling at the last minute and running over budget to get out a solution to a customer when it could have been prevented up front with better planning.
Urge to Improvise
It is in our culture to improvise. Often, we become heroes by improvising. We tamed most of the continent with what we could carry on our backs. We brought Apollo 13 back safely from its disaster-stricken voyage to the moon with duct tape and ingenuity. McGyver was a TV hit. Some of our biggest heroes are improvisers.
Combine our easy acceptance of mistakes with our love of the challenge of solving the unsolvable on the spot with whatever we have available and you have a recipe to maximize rework.
I have worked along side project managers and developers who believed that solving the unanticipated problems under the gun was the fun part of the project. These people often resisted requirements definition because they believed it reduced the need to improvise and took funds away from what their experience told them they would need it for later ... that's right ... rework.
Summary
We have a natural bias toward making assumptions. People often don't ask critical questions because they think they're supposed to know the answer already - or they may incorrectly think they know the answer and don't bother to verify. Our reluctance to reveal ignorance often starts during formal education and studies have shown that it is actually more prevalent in men than in women. Men often feel a greater pressure to remain silent and not ask the difficult questions.
When examining positional relationships, studies have shown that technical professionals are much less likely to ask questions in business training classes than their non-technical counterparts. You can see how problems surrounding assumptions and interpretations can be quickly compounded in this type of thought process.