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.
> Data Flow Diagrams are a tool for documenting manual
> and/or automated procedure. In the Yourdon DFDing
> class that I took, the instructor made clear the point
> that DFDs were first utlized over fifty years before
> the computer was invented.
>
> Back in the early 1890's there were no software
> functions, just people performing tasks.
>
> (FYI: Documenting procedure is a the major thing that
> TWs do.)
No, its not. Documenting procedures is ONE of the things TWs do. A good TW is
also documenting concepts, terminology, explanations, and designs. procedures
are one part of a larger picture.
The MAJOR thing TWs do is understand, digest, and explain information.
Explaining task flows is ONE subset of that.
If you focus all your energy on process, you will not produce good documents.
I realize Tony that you are very excited about diagramming. I was too when I
first discovered it. But, its one part of a larger picture. A procedure without
context is worthless. Furthermore, one of the problems with a lot of technical
manuals is that they only document procedures. Following a procedure without
understanding what you're doing it counterproductive.
Moreover, if you understand how something works, the procedures and tasks often
become self-evident. Making them less important.
Furthermore, Yourdon is well-know for describing how to design software. In
software design, you are dealing with complex, interrelated processes. This is
true. As such, work-flow modeling is important. Yourdon was not tech writer and
his ideas are not directed at tech writers (exclusively.)
But software development and design is NOT the same as documentation. Software
design has specific metrics and specific processes. Software works or it
doesn't. It has strict rules that are uniformly enforced on all systems. Every
system will interpret the data exactly the same (assuming they are configured
alike).
Communication with people isn't like that. It has subjective metrics and
processes. And the rules change from reader to reader. How people interpret the
data is dynamic and volatile.
Tony, diagramming is useful. Don't misread my point. It has value, but its one
tool in a big kit.
Andrew Plato
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around http://mail.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.
