If you ask a business analyst the difference between analysis and
design or the difference between business requirements and solution
requirements you will, in all likelihood, hear about “what” verses
“how”.  However, I have found that, in practice, this distinction is
not as clear as we often assume.  One person’s “what” is another
person’s “how”.  I would like to hear from the group on what criteria
you use to distinguish “what” from “how”.
 

Requirements need to be specified in enough detail so that everyone can agree that they constitute a basis for development. Often time a single Requirements Specification can be produced covering both the business project and the Technology Project(s) supporting it. To ensure that agreement is there the requirements must be Testable and Prioritised - using MoSCoW Rules etc and Traceable.

The Business Functional Requirements will specify

The Non Functional Requirements will cover

The Infrastructure Requirements will cover

The Functional Specification will then state HOW these requirements can be met. The FS will consist of process and data models which together make up the application model and provide an unambiguous description of how the system will meet the requirements that should be understood by both users and Technology alike. The Application Model will normally consist of an Application Process Model which could consist of Use Cases or functional decomposition models using Data Flow Diagrams and Elementary Function Descriptions, etc.

The main thing is that the Functional Specification supports the business objectives and requirements as defined in the Requirements Specification. It is an iterative process and as Craig says is very much like peeling back concentric circles. Tagging a why to each requirement makes a lot of sense in this context.