Craig:

What appears very obvious to me is the the Buisness Analysis world is really confused.  On one hand, diiscovery of inputs and outputs is essential for process definition - not kind of a nice thing to do, but essential.   On the other hand, the poplular process modeling techniques either ignore inputs and outputs (i.e., use cases) - or discount the importance of them (i.e., BPMN and Activity Diagrams).

You say I suffer from a bias.   I say that most in the BA field ignore the essential. 

By the way, someone needs to tell the Lean Six Sigma folks that there basic equation, Y = f(x) (i.e., a functions outputs are determined by its inputs) is wrong.  And of course the data flow diagraming experts are wrong.  

Tony

K:

Graphical use cases do not capture inputs and outputs.  The supporting text may attempt to describe such; however, the inputs and outputs need to be modeled or else there is going to be a lack of rigor.  That is why we model before we write text - to assure rigor.   Agile proponents, on one hand, say: "model just enough"; but, on the other hand, they largely espouse use cases - which fail to ensure that the essentials are incorporated in their graphical models.  Go figure?

Regarding activity diagrams, you are right: they do allow incorporation of data flows (called obect flows).  My mistake is understandable, as I have never seen one in the real world with data flows. 

Sooo, both activity diagrams and BPMN diagrams allow for data flows.   But to quote Yourdon: "If you want to get anything done, you must not try to do everything - at least initially".  Activity Diagrams and BPMN diagrams involve incorporating flow of control, flow of sequence, and other stuff all on the same diagram as flow of data.  Especially for larger scale efforts, the result is predictable:  complex diagrams that contain so much stuff, it is impossible to figure out what is missing.

K, let me let you in on a little secret:  data flow diagrams attempt to show flow of control, sequence and data flows just like BPMN does.  However, they - or at least the popular Yourdon technique - show flow of data on seperate higher-level diagrams, and postpone flow of control and sequence until detail level diagrams are constructed.  Reason:  to avoid diagrams so complex that it is impossible to figure them out.

Tony Markos