Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Use Case
Previous Previous
 
Next Next
New Post 3/13/2009 6:04 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Use Cases 

I'm heading off to an IvarJacobsen lecture on a fortnight.  I wonder what he'll have to say on the topic.  (He has abandonned use cases by the way.)

 
New Post 3/13/2009 9:34 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases 

David:

By following sequencing and flow of control, we are proded to more fully identify essential functionality than with use cases.  However, especially for complex systems, there is a radical difference in the resulting system partitioning if we place primary emphasis on following the flow of data vs placing primary emphasis on following the flow of sequencing and control.  You will find that placing primary emphasis on following the flow of data  results in a much more rigorous analysis.

Process modeling techniques place primary empahsis on following flow of sequence and flow of control.  Data flow diagrams place primary emphasis on following flow of control.

Tony

 

 

 
New Post 3/13/2009 9:36 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases 

David:

Oppps, the last sentence of my previous post should read:  "Data flow diagrams place primary emphasis on following the flow of DATA."

Tony

 

 
New Post 3/13/2009 10:16 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Use Cases 

 

Tony,

I have read your previous posts about control versus data flow. My first reaction these days after many discussions on methods is that, if your method is working for you, go for it.

Given that, I can tell you where my experience has led me. "In the beginning", (1980 for me) there was Structured Analysis and Design, which was all about Data Flow Diagrams. Those diagrams had data stores on them, where data would flow to be stored until it was needed, probably because of a time delay between a sending and receiving activity.

Next up for me was data modeling which, among other things, considered flow-driven data stores to be bad examples of data duplication and data silos. When I combined the two, I drew DFDs with one big datastore in the middle, where activities would send data to store it and would go to get data they needed. A seprate Data Modle would descibe the details of this one datastore. The flows between activities started to wither away for me.

Then for me came Information Engineering, which had Data Models (like above) and Functional Models. The latter included Functional Dependency Diagrams, showing the rational order of activities based on states, e.g. create Customer had to come before Modify Customer.

Then came Business Process Modeling, which showed the timing and resource view of activities, and showed how functions would be used to respond to an event.

Then came UML and Use Cases, where I essentially swapped IE Functions out for Use Cases.

That's still simplyfying a few things, but it has led over time to me distrusting  Data Flow Diagrams as I first learned them. I have not seen anything lately to make me change my mind, and so would not recommend them myself to anyone else.

So, I guess this creates a challenge of a minor sort. What more can you tell me that might change my view?  The first question I have, is do you use data modeling as well as DFDs?


David Wright
 
New Post 3/23/2009 2:18 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases 

David:

Analysis is largely about discovery.  Functional modeling (DFDs) drives data modeling, as functional modeling is stronger at guiding the discovery proces.  That is logical "holes" in our analysis is much more glaringly evident with functional analysis than with data analysis.  For discovery, data models are relatively inert.     (Yes, I also use data modeling.)

Also, a function (same thing as a process) is defined by its inputs and outputs.  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).    If primary emphasis is not placed on inputs and outputs - like only DFDs do - I will gaurantee you that the analyst will miss alot of them.  (By the way,with data flow diagrams, an analyst can also capture flow of control, sequence, timing, etc.  They are just captured at lower-level child diagrams to the DFDs.)

Finally, and probably most importantly, consider that analysis is also about partitioning.  The system partitioning that results from properly constructed DFDs is going to be very different than that of BPMN, use cases, activity diagrams, etc.  Only DFDs enforce what is called a logical, natural partitioning (vs a forced, artifical partitioning).  With DFDs, we follow the natural flow of data as they split and combine to flush out a functional partitioning.  With the other techniques - there is no science to the partitioning, we just do it (i.e., force it).

Tony

 

 
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