Hi:
You are absolutly correct in saying that one person's "what" is another person's "why". And you will never get any broad concensous on how to distinguish between the two.
So, instead of asking how individual BAs distinguish between the two, maybe the question to ask first is: Is there a logical necessity for having both "whats" and "hows"? There the answer is largely no. Data flow diagrams clearly illustrate. If I were to, for example, create a data flow diagram of Boeing commercial aircraft, I would first create a top-level single-function diagram (i.e., a context diagram) with the function labled something like "Create Commercial Aircraft". This is the top-level "what". Drilling down, the next-level diagram would consist of sub-functions that each also tell "what" is to be done, only to a finer degree of abstraction". The next-level of diagrams would each consist of sub-sub functions that, again, tell "what" must be done, only to a still finer degree of abstraction. And on and on.
Often, on data flow diagrams for more complex systems, I have six or more levels of "whats" - and just "whats". The total number of individual "whats" soon reaches hundreds. Many of these "whats" would currently (I am assuming that I am working on an as-is model here) be accomplished by a person. Other "whats" would currently be accomplished via software. They are still all "whats" - irregardless of whether they are implemented via software or not.
Key Concept: If, while I am performing such a complex analysis, I complicate things even further by trying to develop a scheme as to what is a "what" and what is a "how", all I am doing is making life more difficult. Indeed such unnecessary mental exercises - especially on larger scale efforts - are a real innitiative killer.
Granted, way at the bottom, I often detail out sub-sub-sub-sub functions ("whats") with logical if-then-go-go-like flow charts that essentially discuss "how" that function is to done, but you get the overall point that I am trying to make.
Tony
Tony