Hi Gary,
Interesting questions!
First of all, reading between the lines it sounds like you use Use Cases to model design. What everyone seems to call System Use Cases. We used to call that structured english or pseudocode back in the day, but no matter. Am I right? When I talk about use cases here I mean proper, solution agnostic business use cases not screen design.
Anyway I think a combination of textural requirements, process, functions (business use cases), business rules, non-functionals, business domain plus various other artefacts that you need from time to time, will define any system no matter how big or small. That is the business requirements.
Systems analysis stuff, called functional requirements where I work but could be something else where you are, is about defining the screens, data, validations and other stuff needed to realise the business requirements and develop from.
I'm being simplistic but that's pretty much it in a nutshell.
Not sure there is anything like a best practice out there. Everyone will have a different opinion. I've been thinking of writing a paper about all this myself. No idea where to get in published though.
Anyway, when you find your "best practice", just remember that one man's best practice is the next man's belly laugh!
Kimbo