There are really only three methods for describing requirements in the whole world, these are:
* Imperative: "The system shall....."
* Prescriptive: "X = Y * 5. If X then Y. Use Cases, ER Diagrams, etc".
* Narrative: Bob hits X, Y happens, then Z. This is because A is true. If B were true we would do this.
Imperative is how everyone starts of doing requirements in their first job. Those long lists of "requirements" that make everyone's lives so miserable. IMHO you should never use these for anything but the simplest project.
Prescriptive is the model we move to after we've been hurt by scope creep a few times. We'll just lock everything down in a detailed unambiguous model that is 300 pages of impenetrable UML, and then we'll be OK. We won't have capture what the user actually wants, but at least we'll have documented it unambiguously.
Narrative is where we realise that our systems are only part of larger stories, and need to be seen in that context and we make the customer the centre of our design by giving them the starring role in the story. User Stories, or well-written use cases are good examples here.
This distinction has nothing to do with functional vs. business requirements. It's a seperate dimention about how we document requriements. The type of requirement is a compeltly seperate discussion.