Re: Why Creating DFDs Is Very Dangerous

Subject: Re: Why Creating DFDs Is Very Dangerous
From: Tony Markos <ajmarkos -at- yahoo -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Tue, 2 Nov 2004 13:53:11 -0800 (PST)


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

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.



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:

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 for more resources and info.

Re: Why Creating DFDs Is Very Dangerous: From: Ned Bedinger

Previous by Author: Scoping A System
Next by Author: Re: 10 Things All Technical Writers Should Do
Previous by Thread: Re: Why Creating DFDs Is Very Dangerous
Next by Thread: Re: Data Flow Diagrams

What this post helpful? Share it with friends and colleagues:

Sponsored Ads