Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Use Case
Previous Previous
 
Next Next
New Post 5/1/2009 4:13 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Use Cases 

Hi Tony,

Forgive me for picking up this thread so long after the event. I've only just stumbled on it. I've seen your posts through the forum and I'm curious about some of your statements in your answer above

#1 "Therefore, if one wants rigorous functional analysis, he/she needs to use a modeling technique that places primary emphasis on the inputs and outputs (typically data flows)."

    -  Can you please explain why you think that rigorous functional analysis requires primary emphasis on data flows. I don't get your reasoning.

#2 why do you think that partitioning from DFD's is better than that from a process driven approach? Surely partitioning is good or bad more because of the ability of the BA rather more than any other reason. As another example, I recently partitioned a system based on what happened 3 months, 4 weeks, 2 weeks, 1 day out from a particular thing and then at intervals afterwards. This was well understood and accepted by business users and developers as a logical way to represent the system. It wasn't based on data flow.

I should say that I started life as DFDer using Yourdon's methodology - still have DeMarco's book in my bookshelf somewhere.

And I'm not being confrontational. I'm genuinely interested in your opinion as I can see you are very passionately against the newer techniques.

To me DFD's, process, etc are all different ways of looking at the same thing and all valid.

Kimbo

 
New Post 5/4/2009 8:41 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases 

Kimbo:

In  your response to your first question:

A function\process is defined by its inputs and outputs.  (These inputs and outputs are typically, esp in info systems, data flows.).  Do you see such?  To me, this is a real fundamental, and extremely important concept.  If you or anyone can refute such, then I am in need of "getting my head straight".  In such case, please, PA LEEZE,  let me know!

If you agree that a function\process is defined by its inputs and outputs, and, as the prospect of systematic input\output analysis seems to the last thing that the vast majority of BAs want to do, without a technique that places PRIMARY emphasis on inputs and outputs, rigorous input\output analysis just ain't going to get done.  And therefore, especially in larger scale eforts, function\process analysis is going to be very incomplete. 

In response to your second question:

If you believe that processes are defined by there inputs and outputs, than what is the process driven approach that you refer to?  To my knowledge, only data flow diagrams focus primarily on process inputs and outputs and therefore, only they are process-centric.   BPMN, for example, has some provision for capturing  inputs and outputs, BUT the inputs and outputs are placed on the same diagram as is a bunch of other - secondary - stuff like: flow of control, sequencing, timing considerations, and swim lanes.   Result:  Input/output analysis  suffers, as, to qoute Yourdon (DeMarco?)  "If we want to get anything done [correctly], we must not try to get everything done - at lease not initially."

Kimbo, my very first post to this site was entitled "The Lost Secret of Business Analysis".  In it I talked about the difference between a logical, natural partioning (i.e, partitioning as a result of flowing the flows of data) and forced, artificaial partitioning.  As per DeMarco, in data flow diagraming, the BA follows the natural flows of data.  When data flows naturally converge, or diverge the BA has discovered a logical process.  The method itself actually prods the analyst through process discovery.  Especially for larger scale efforts, such a partioning, is going to result in a radically different partitioning than any other way.  

Tony

Nobody is good at partitioning just based on intiution.  What matters is being good at using a methodology that will prod you through the partitioning process and make "holes" in your thinking glaringly obvious.  Hate to say it, but partitioning based on timining is another example of forced, artificial partitioning: 

 

 

 

 
New Post 5/4/2009 2:17 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases 

Kimbo:

Darn it - I accidently hit the Submit button before finishing answering your question as to why I think that partitioning from DFD's is better than from the currently popular approaches? "  Let me try here:

Data inputs and outputs define a process.  Without proper consideration of the data I/O's , the BA significantely fails in identifying all the essential processes.  And the partitioning is going to be wrong because one can not properly partition what one does not adequately know.

Only data flow diagrams employ what DeMarco (Yourdon?) referred to as a "lithmus test of completedness"  - the data inputs and output flows.  And, only when we know the system, can will properly partition it.

Tony

 

 
New Post 5/6/2009 10:30 PM
User is offline Kimbo
454 posts
5th Level Poster


Re: Use Cases 
Modified By Kimbo  on 5/7/2009 12:30:33 AM)

Tony,

I think I dispute your basic premise that a process is defined by its inputs and outputs. I haven't thought enough about it yet but you can't define a process without considering the activities that occur in the process. Along with the inputs and outputs I guess. So activity diagrams can have data stores on them which will allow the ability to show inputs and outputs on the diagram. So then they are pretty much DFD's. So maybe we are in fact violently agreeing with each other??

What do you think?

Kimbo

 
New Post 5/8/2009 7:26 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Use Cases 

I think Tony has a track record of success and assumes his tools are key to it.  I suspect that his personality and intelligence and interpersonal skills contribute far more.

Tony's bias for DFDs is an example of confirmation bias   (love that list)

So, while other methods may work fine in the right hands, for Tony it is DFDs.

The issue here is the many many poor analysts that follow forms but don't do the real analysis work.  And when you watch them you could optimistically blame the tools they are using.

 
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