TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: The End Of Technical Writing From:eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Fri, 29 Oct 2004 15:04:22 -0400
bounce-techwr-l-106467 -at- lists -dot- techwr-l -dot- com wrote on 10/29/2004 02:34:13 PM:
> In any task, there are inputs and outputs. Inputs and
> outputs can be data, or other things such as tooling
> and materials required for manual tasks.
How is a DFD any more efficient than any other method of identifying such
inputs and outputs? How does a DFD force me to identify tools or
materials? how can you claim DFDs are the only tool forcing you to do this
type of analysis when for most tasks there are many other ways to
list/gather required inputs and outputs without producing diagrams of
little use.
How is a DFD of such a situation any more productive than a brainstorming
session coupled with "connecting boxes"? Unless you're working with actual
data or product and trying to map its progress and interaction, DFDs seem
to be little more than just such an exercise.
> Tony Markos responds:
> Data flow diagrams are most definetly applicable for
> people-doing-troubleshooting tasks. SomePossible
> inputs for your example: Reference manual data,
> responses from diagnositic software, existing
> configurations - documented or manually observed.
All of which hasn't really advanced the production of a troubleshooting
task or table one bit. And actually, troubleshooting is one area where a
LOGIC flow chart is what you are trying to produce.
A DFD of the entire system and the various outputs provided by systems and
components might provide clues as to what needs to be included in
troubleshooting, but such information should already be available in table
form for all the various data and physical interfaces and displays.
Guess I just don't have the moxie to compare myself to Einstein, claim I'm
one of the few can work correctly, or have the belief/faith comparable to
some born-again religion.
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed! 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.
