Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Use Case
Previous Previous
 
Next Next
New Post 6/11/2009 6:01 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases 

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

 
New Post 6/12/2009 7:52 AM
User is offline KJ
243 posts
6th Level Poster


Re: Use Cases 

Tony,

Use cases do have inputs and outputs .  for example, I normally write my use cases to include “this use case starts when <actor> receives an invoice (see sample a)”.  I finish my use case with the actor’s goal (the output).

Use cases by their nature are disjoint. Put a swag of use cases in a hat and shake it and what do you get, just a swag of disjointed use cases. Use cases only make sense when you view them in the context of a business process, which is either a BPMN or Activity diagram. We’ve been round the BPMn input output debate a few times, so lets tackle Activity Diagrams. In Uml 2.0 Activity diagrams do have input and outputs (see object flows).

Six Sigma...mmmh.

Warm regards,

K

 

 
New Post 6/15/2009 8:48 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases 

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

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Use Case

Community Blog - Latest Posts

Salesforce has established itself as one of the most reputable CRM platforms, providing important customer data to assist businesses in effectively managing their operations. Salesforce is the world's best CRM platform that helps businesses to keep up the data in an arranged or structured manner. Salesforce is the world's most popular...
There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms: Data exploration means the deep-dive analysis of data in search of new insights. Data presentation means...
Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC