K wrote:  What's happened to the old tested ideas of IPO (input-process-output).....

An understanding of  input-process-output is essential to logically understanding how a system works.   Yes, the concept has been around awhile, but the important point is to focus on the concept's essentiality.  

What happened to a focus on input-process-output?   The concept is still recognized by the  knowledgeable as fundamental.  Case in point, look at the BABOK 2.0.    This document is the latest and greatest from those who lay claim to setting a certification standard for BAs.  The document is also a functional spec on how to create a functional spec.  Notice that it is organized around input\process\output diagrams.  (Granted, the document would be much easier to read if, instead of using simple  input\process\output diagrams, integrated input\process\output diagrams (i.e., data flow diagrams) were used.)

So the question now becomes: If the knowledgeable recognize input\process\output as fundamental, why don't the masses?   Answer: newer techniques are easier to use, even though they result in the situation that you mentioned: "...the artist gives you a blank stare when you ask about inputs and outputs to/from a proess".

Tony

K,

We seem to have gone off topic which was me responding to your assertion that the best BAs have degrees. I note that you have yet to define what a "best BA" is and what the causal relationship between holding degrees and being a "best BA" is.

On your previous post you preface it with "Are you saying that university education or any education for that matter is not needed to be an analyst; rather you’d prefer analysts to be logical and by this I “infer” that their deliverables (requirements etc) are truthful: reflecting the needs of the user?"

I agree that I am saying that "university education or any education for that matter is not needed to be an analyst; rather you’d prefer analysts to be logical". I disagree with with your inference about "truthfullness". The application of logic is to sepcfiy justified requirements based on the smart objectives of a project. The justification is the mapping between every requirement and business rule and the objective(s) they directly or indirectly help achieve and any other requirements or business rules also needed to achieve those obnjectives whether the user specifies them or not. You do what you need to do to achieve the project objectives. I have written on this at length (see my website www.smart-BA.com).

Hope that clears things up?

Guy