Business requirements and functional requirements have different purposes and are used by different parties on a software project:

Business requirements have a purpose to capture end-user needs, i.e., they should be statements about WHAT an application should do for the end-user. Business requirements are first used by project management to plan the next release:

a)      agree with the end-users on the release scope;

b)      estimate the development effort;

After the release scope has been agreed, business requirements are used by BA (or developers) to specify solutions to the needs. These solutions (i.e. HOW TO details) are captured as software requirements (where functional requirements are a kind of software requirements). Functional requirements are used by developers and testers.

To summarize, business requirements should capture WHAT an application should do, whereas functional requirements should capture HOW the user needs can be implemented (from the end-user perspective).  

Hope, this could help. Yuri

You can see why I have a problem distinguishing between the two...becauase everyone has a different opinion.  The terms do not seem to be consistently used anywhere.  Somewhere in every explanation is something about "the What" and "the How" but I have yet to find a good explanation with examples to back the it up.  That is why I was asking for examples in my first post.  Sometimes is sounds like BRs are higher-level features the system must support and the FRs are the details and other times it sounds like they are both refering to the same thing and other times the BRs are the overall business goals and the FR are the requriements.  I'm still unsure of the most effective way to use the two and if it makes sense to think of them as being the same or different.

I am swooping in a bit on Jimbo's topic because I have had recent discussions in my organization regarding my predisposition (as a Business Analyst) toward "writing too technically".  There has been a swing in expectations in my department recently (new kid in town with different perspective on "industry standard" is shaking things up).  Several of us are writing what they are calling "high-level" requirements (which is what I would consider "Calculate Sales Tax" and leaving the details to Development to work out with Business), and the rest of us are still eliciting this detail as Business Analysts and providing to the Developers in our Requirement documents.  I have been trying to put a "name" for years to my style of Requirement Writing, or to the level of detail I have been documenting.

In my mind, "Calculate Sales Tax" or even "The system shall calculate Sales Tax" is too vague.  It's a good starting point, but should prompt more questions...

I would expect to help the SME's to have an idea, or be assisted in determing:  What is the formula we should be using to calculate Sales Tax?  Does the Sales Tax need to be posted in a separate transaction?  Does it need to be displayed separately from the total amount and from other local taxes?  Is there a different taxable % based on the state the Sales Tax is applicable in?  Are there specific transactions were this tax is or is not applicable?  Will you need reporting on the Sales Tax?

I would not anticipate that our Business Sponsors/SME's/end users would be satisfied with the solutions development comes up with if they are not armed with these answers, as they do not really need to know our "business" in order to code for the needs.  Shouldn't I be eliciting and documenting these specifics?  Are they Business Requirements or are they Functional or System?