First thing we do is establish a wiki for all the process details. Anytime someone puts in their notice, they have to to make sure the wiki is completely up-to-date on all of their responsibilities and to train someone currently in the office on those things before they leave. That person trains the replacement when he or she is hired and handles the responsibilities until the hire takes place. Now the new people have a place to go to understand the processes. They have a place to go review before a meeting, to be sure they understand what this area is about.
One of the biggest problems we used to have is that new software developers (especially contractors) didn't understand the business processes or why they were important. So we set up a training session specifically for that. We also ask them about the business processes in their current job when hiring to help identify people who are used to understanding the the meaning behind what they do. These people are more likely to care about getting up-to-speed on such things.
I have a training sessions specifically on data meaning that shows them why it is important to understand what the business is using the data for and why it is critical to understand the complexities of our database as it relates to the business. After they work through a few examples, they are much better prepared to understand that you can't just know how to use an ORM or a write SQL code, you have to understand what the results of queries mean. After all I can write a ton of different queries on the same set of tables and have the business meaning be totally different.
You can also ask the client to spell out specifically which things they feel that new people need to know to come up to speed quickly. Their list may be very different from what you would do for initial training. It could also help to have the business users of the software, produce a video where they go through different sections of the application and talk about what they do in that section and why they do it. We did a session like that shortly after I was hired and it made so many things and programming choices much more clear to me.
A key part of this is having your own management care about processes, requirements and business rules and modeling that behavior by explaining them as they go with new people, by asking them questions about those things when planning a new module, etc. You get what you expect and if you don't expect people to learn the business as well as the technical programming side, they won't. Every meeting that does not contain the client should also talk about these things. New people need to understand that they are important. In technical meetings, you should be looking for holes in requirements and then passing those questions up to the client to resolve (not make assumptions about what they want!!!!!) Any organization that cares about business rules and requirements pushes a very large portion of initial requirements back for clarification. If QA and the dev disagree about what a requirement says, it gets pushed back up for clarification, if the dev has a question about what to do in this situation not covered (requirements often only cover one decision side of a decision tree), then it gets pushed back. Devs will be less likely to pretend they are clear on the requirements when they see senior people pushing them back for clarification.
Code reviews should also look at requirements to see if the code meets the requirements. QA should base their tests on the requirements.