Why No One Asks For Data Flow Diagrams

[Tony Markos <ajmarkos -at- yahoo -dot- com>]

--- "Oja, W. Kelly" <w -dot- kelly -dot- oja -at- verizon -dot- com> wrote:

It may just be an issue of semantics. But you (Tony)
did not really answer the question, you more or less
side-swiped it. So again, if so many of us on this
list that went to skool fer tech writing do not have
the <depth> of DFD knowledge that you <possess>,
what are the odds that an interviewer will? I would
bet the odds are extremely low.

Tony Markos:

Your question is just a slight variation on the
question: If Data Flow Diagrams are so powerful, why
are they seldom used in projects? (They seldom are
PROPERLY used.)  

This second question I have answered more than once -
on both this listserv and on the Requirements
Engineering listserv.  Sometimes, Oja, I get tired of
answering the same question over-and-over again.  But,
since you say many are interested, below I again give
my answer.

***************************
To Restate What I Have Said Before:

Properly used, Data Flow Diagrams are an extremely
powerful task analysis technique.  A skilled DFDer can
run circles around a small army of competing analysts
using ANY other task/function analysis technique.  (To
understand why this is so, one needs to be understand
the difference between a logical, natural partitioning
of a system ("chunking" to us Tech Writers) vs a
forced, artificial partitioning of a system.  This is
a subject not directly related to your question, so I
will not elaborate further on it here.)

But while Data Flow Diagrams, properly used, are very
powerful, the analyst does have to pay a price that
most are not willing to:

  *  Data Flow Diagrams, like nothing else, make
mistakes in one analysis glaringly evident.  While a
real go-getter analyst likes this, because he/she can
accomplish more quicker, many really shy away from
having mistakes in there work being made glaringly
evident.  Especially in the required walkthroughs of
the diagrams.

  *  Data Flow Diagrams require
as-top-down-as-approach to analysis as possible.  This
means that the analyst needs to postpone detail(I said
postpone - not forget about - big difference!) to the
appropriate time.  The danger with postponing detail: 

The vast majority of IT professionals, including most
IT managers, have always approach there work by
jumping immediately into the details.  They think:
"Hey Tony has been doing end-user task analysis for a
week now, and he still does not know about detail X. I
was here only a day when I knew about detail X. 
Therefore, Tony must be goofing off."  

  *  It is very easy to step on a political land mind
using Data Flow Diagrams: DFDs prod the analyst to go
after truly essential procedure like nothing else. 
However, knowledge of essential procedure is "turf"
and people will defend "their turf" to the death. 

***Note:  All the above explains my saying: "It is
only by dying(i.e., following the flow of data) that
we are born again (i.e., come to have a understanding
of the underlying logic of a system)."







		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.