Re: The End Of Technical Writing

Subject: Re: The End Of Technical Writing
From: "Ned Bedinger" <doc -at- edwordsmith -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 28 Oct 2004 19:37:51 -0700


Three questions for you to address:

1. Something you said a while back seemed to suggest that the DFD approach
can be risky. What's that about?

2. How do you account for the power of DFDs to capture end-user tasks? My
experience is that many tasks are not related to data flow. Consider a
procedure named "Troubleshooting an unresponsive server." Would you
automatically assume a data view of the diagnostic tasks (checking
configurations, pinging hosts, restarting services) and go from there?

3. You descxribed DFD as a top-diown approach to a system and task
analysis. In what sense is it top-down?


I also diagram (even data flows, if data flow is in scope) to consolidate
what I know about a system. For example, I always try to keep a "state of
my understanding" diagram handy in SME interviews (at all times, really). I
want a SME to validate what I think I know, much of that exchange can be
done quickly, visually with a diagram. IF I am concerned with the flow of
data in a system, then I would of course show the data flow, even in a
separate DFD.

BTW, regarding Task Analysis, I worked in an IT department that had a
program called "Walk a Mile In My Shoes" -- IT people could arrange to
explore their career paths by spending a few hours on the job with other IT
professionals in the company. Some tech writers took this as an opportunity
to spend time with their customers, seeing (often for the first time) who
and what they were the writers for. I'll admit that I have analyzed many
tasks and written many procedures in a complete vacuum, with no real
experience of the user or the real context. I'd go a little further to say
that first hand experience of the user in the work context is a helpful
adjunct in getting task analysis right.

Ned Bedinger
Edwordsmith Technical Communications

----- Original Message -----
From: "Tony Markos" <ajmarkos -at- yahoo -dot- com>

> For Discovery of Tasks:
> Data flow diagrams add rigor to task analysis by
> making logical "holes" in ones analysis glaringly
> evident. When we have tasks on the diagram with
> outputs, but no inputs, or vice-versa, or when data
> flows show as going nowhere, they stick out like a
> sore thumb! They actually prod one through the
> analysis (i.e., discovery) phase.


ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!

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!

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: The End Of Technical Writing: From: Tony Markos

Previous by Author: Re: Allocated chapter numbers for specific chapter content
Next by Author: RE: Neophyte - impostor looking for advice on contract tech-doc job
Previous by Thread: RE: The End Of Technical Writing
Next by Thread: Why Creating DFDs Is Very Dangerous

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

Sponsored Ads