Q:

How can I get our BAs to provide business requirements, and stop confusing them with implementation

Our BAs (Business Analysts) have an annoying habit of providing us with system requirements, rather than business requirements.   Often times, they don't even know what the business requirement is. 
It infuriates me, because I see a list of requirements, and it will be tied to the way it should be implemented, rather than the problem that should be solved. 
A very contrived example would be, "System should email customer an order confirmation."  instead of "The customer needs to be informed that the order is confirmed." 
Granted, in this case, it will likely be an email.   However, there is a chance we make a business decision to be more personable and want to follow up orders with phone calls to verify they found everything they were looking for, etc...
Other examples are more insidious.   I was working with something that handled reallocating distribution to different locations based on sales.   The order is initially placed sending $X amount to store X, $Y amount to store Y, and $Z amount to store Z.  However, 6 months had passed from the initial order, and we see that store Z is now outperforming store Y, who's sales have dropped.   We want to swap the goods we are distribution between the stores.   The business rules I were given were tied very closely to the implementation, and in many case, where X->Y, Y->Z and Z->X no swaps would occur, even though our eyes can see that we are literally just shuffling goods between stores. 
So I suggested a new approach, queu up the orders we have, sort them, sort the stores based on sales, and then rematch the lists that way.   Ensuring the best selling stores get the largest orders.   
However, because I don't actually know the business rule, and just know the shuffling algorithm I was given, which seems incorrect, fixing it involves going back to the users, and getting the business rules...which should have been done in the first place. 
What I'm asking is, is there a trick to gathering good requirements that are based upon business rules?   How can I get the BAs to do this, when they aren't already.   I'm having a hard time know explaining the difference between business and system rules...and they clearly aren't grasping it.   How can I educate, and improve their abilities? 

A:

Change the format.  Traditional functional requirements are pretty flawed and have decades of focusing on the "what" and not the "why" or the "who."  
User Stories and User Persona based requirements focus on the "who" and the "why."  While agile is the most obvious user of this today, it's not a new concept.  I first learned about this concept through a product management methodology from the 1990's call "Building a Market Focused Organization."  
Take US Banks in the 70's and 80's.  In their efforts to become more competitive in post deregulation era they went out to their customers.  They didn't start with what to do, they started with asking the customers questions.  Then they looked at what the customers said "Longer hours, more tellers."  and asked how they could solve this (without spending the $ on longer hours and more tellers).  The outshoot was to leverage a technology that had been around since the mid-60's but had languished as a gadget without a true market.  And so came to pass ATMs.  
So use User Personas and User Stories.  Mike Cohn has published two very good books on this topic that I highly recommend.  
I recently did a two part blog on using agile practices at the product requirements level, to drive useable requirements.  If you're interested in it, my blog is linked in my profile.  Look for the "Garbage in, Gorilla out" and "How much is that gorilla in the window" blogs. 

A:

What are you doing to make sure you get the requirements that you want?  
I practiced as a BA for several years at a large company.  I will tell you that this is not an uncommon problem that you are having.  I can also tell you that the only way It gets fixed is when you and the BA get on the same page. 
Yes, the BA is supposed to document the requirements in a manner that is easily consumed by the dev team.  The dev team is supposed to produce code that works and doesn't drive support calls (that you do not have to take) also.  
Either way, getting requirements to you is only one part of a BA's job.  The other part is to get the NON technical senior leaders that hold the checkbook which pays both of you to give requirements that make sense and don't change every week.  I can promise you that they do not get your problem at all. 
If you start looking for work where the BA is going to be a rockstar you are going to be looking for a lot of work in your career. 
Why not get with the BA on the side.  After work, for coffee or whatever and help them understand what your needs are.  Train them to ask the questions so that they are gathering the requirements in a way that you can consume efficiently.  It's a win win for both of you. 
Oh, and I coded before I became a BA and still do today so I know why your requirements need to be clean.