"Shouldn't I be eliciting and documenting these specifics?"
Yes, absolutely.
These specifics will be needed, they are specifics about the business, and will be part of Requirements, so capture it all at the beginning so the SME doesn't have to meet with two people to tell about his business twice (that tends to annoy them).
Also, this is prime opportunity to identify business rules separate from other requirements, allowing you the chance to use a BRMS. If coders are asked to get these details, the rules will end up in code (yuchh).
"Are they Business Requirements or are they Functional or System?"
I would class them as Functional Requirements. Business and System requirements also have varying definitions, but Functionals mean the same thing to most everybody.
"High Level Requirements"
That statement of 'Calculate Sales Tax' is valid requirement statement which, if you call it high or medium level, can be sufficient in certain types of projects;it may be enough, for example, to evaluate software packages. You may also create a set of Requirements at this level of detail to help in scoping or estimating, before heading down to the specifics/details.
There you go...
Dave Wright
www.iag.biz