Re: Why Creating DFDs Is Very Dangerous

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

Ned:

Nice web site!

You say:  DFDs will drive an analyst into madness.  

My comment: I feel great!  Except that my furniture is
all ripped apart :-)

You say: TWs should strive to work with existing
artifacts, as opposed to doing a task analysis.  

My comment: Quality artifacts is luxury that I have
seldom experienced.   

You say: If discovery [DFDs] is the only tool
available to you, then you have first class butt-heads
for co-workers.  A project should have someone who is
designated as accountable for the requirements and
design.  

My comment:  You clearly have worked for a lot sharper
group of people than I have.

You say: If you're trying to do more than impose a
little order on the interface, or ferret out missing
details in the offical account of what/how/why the
product does, then you probably will need to augment
the street smarts (you mentioned this) with
bulletproof protective gear to CYA

My response: I always get permission before doing a
task analysis.  Yes analysis using powerful DFDs is
dangerous work.  I have not been shot at yet, but I
have (unintentionally) almost started a riot. 

You say: The only way that you (the tech writer, with
locker full of investigative tools) will be in a
position to discover the detailed requirements and
design of a product is if you have access to the
already-completed Requirements discovery process,
which was *ideally* done and documented by business
analysts, product/data designers, solution
architects, or whoever is responsible for designing
the system of inputs/outputs/processes that you
are concerned with. 

My response:  Yours is a very popular viewpoint.  But
I need info to act upon - not tons of incomplete,
incorrect, disjointed artifact (documentation, models,
etc).  I don't ever recall getting what I need from
the BA's, Architects, you name it.  I have always
found that, even with rough-cut DFDs, I am  often way
ahead of everyone else in terms of understanding the
essential tasks that the end-users must perform and
how all of those tasks interrelate.  This
understanding is the key to efficient and effective
planning of user-friendly documentation.

You said: It isn't DFDs that are dangerous. Danger is
doing the analysts' job without asking them for the
information you need.

My response:  O I ask.  I truly desire an easier way. 
Problem is that I don't get because it does not exist.

You said: Tech writers rarely get that kind of
authority to pursue requiremets and design.  (But
doesn't that sound the situation that leads to
the information "turf" issues you described?)

My response:  Your right about [system design].  But,
as far as requirements go, I have found that often the
task of understanding essential requirements is pawned
off onto the TW.




		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com 
 


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

ROBOHELP X5 - SEE THE ALL NEW ROBOHELP X5 IN ACTION!

RoboHelp X5 is a giant leap forward in Help authoring technology, featuring all new Word 2003 support, Content Management, Multi-Author support, PDF and XML support and much more! View an online demo: http://www.macromedia.com/go/techwrldemo

---
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.