Jan:

Why use dfd's vs use cases? While dfd's offer ease of understanding, explain business processes, support layers of detail, serve as design inputs, and are in widespread use. many will say the same of use cases.

The essential difference between dfd's and use cases: Use cases are basically dfd's without the data flows. See my comments under the article "The How of Essential Modeling" on why this difference makes dfd's and use casese profoundly different.

Tony

Finding this artical was a nice relief. As an IT Business Architect I spend a signficant amount of time analyzing and documenting IT portfolio and IT Business Architecture standards (business planning). In this strategic domain, I am working a little with technical architects, but more with executive business sponsors (you remember, the people that approve our IT budgets) - they don't want to see UML or techno diagrams - they want an easy to read business context diagram to convey scope and strategic should be models. UML is great, but it's only one of our tools in our Analyst and Architect tool box.

Hi Tony,

Thanks for your comments. As a training provider I'm a firm believer that we should supply what the market wants rather than try to lead it in a particular direction. We use structured techniques in a lot of our courses so people can more easily understand the fundamentals of the business analysis process. Unfortunately there's a view in some quarters that if it's not UML (or BPMN?) then it's 'old fashioned". The paper includes use case diagrams to show that similar results can be achieved with other notations. Ditto for essential modelling. What we do see is that business users (and business side ba's) find DFDs a lot easier to grasp so there's still some life in the "old" techniques !!

Best Regards...Jan

Jan:

Thanks for the informative response. I am well aware of the "No body ever got fired for recommending IBM mentality". What is missed by all (or at least 99.9%) in the requirements analysis community is that any draw-the-circles-first-thing-and-forget-about-the-data-flows approach to functional analysis (i.e., use cases and BPMN) is really much older than data flow diagrams.

Data flow diagrams were primarily invented to help analysts overcome the age-old overwhelming temptation to such an approach. Dfd er's call such an approach a forced artificial partitioning , which is just a fancy way of saying a validate-your-own-BS approach.

DFD's, even though they have been around since the late 60's, is the latest and greatest.

Tony

I agree that a picture is worth 1000 words! I would also suggest that clip-art is much more intuitive for business users than formal technical diagrams.

One technique I've used with both DFDs and ERDs (Entity-Relationship Diagrams) is to replace the circles or squares with a picture that is representative of the information or the activity.

Then in a PowerPoint I place the more "marketing version" of the diagram as the first slide, and then slowly fade to a second slide which has the appropriate technical representation.

I've found that the visual icons tend to stick more and be less distracting to the business users. For example if an entity is ACCOUNT, I typically use a bag with a dollar sign....For an INDIVIDUAL I use a stick figure... for ACCOUNT SETUP I put the icon for a computer with a data entry screen (if it is manual entry).

Fading to a model diagram with the box or circle exactly located in the same place helps a business user understand intuitively the meaning.

Best regards,
Loretta