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.
Sorry to rain on your parade, but although DFDs are a convenient form
of getting a handle on many problems, they are by no means the only
way...or even an early step in the process that may be best employed.
A major requirement is that *someone* be able to work with the
potential users to determine if the data model--however derived--is an
accurate representation of their needs and requirements.
It is in this aspect--the interface between the customer and the
developers, that I believe is the area of most significance for tech
writer involvement.
When you become involved in dataflow diagrams, you are in large
measure involved in system architecture...which implies an
understanding of what is possible programmatically.
In my view, it is often well before this that we can be most
effective. For example, often the user does not understand dataflow
very well--or even, in many cases, the very processes he is involved
in on a daily basis from a "50,000 foot view" perspective.
Thus, at times it is essential to do some re-engineering of the
customer processes in order that they get the best results from
program development. This, obviously, comes at a very fluid stage of
development.
Next, I have seen many times when customers don't really begin to "get
it" until they see some representative user interface designs. Even
when totally dummied up and presented as PowerPoint slides for
examination and comment, this often results in enough future users to
begin understanding what *you* think their needs are--and making
suggestions and corrections that help focus in on what they really do
need and want.
You see, it has been my observation over many years that customers
often haven't much idea of what to ask for--what is possible--while
developers often don't know enough about the customer business to know
what to suggest. This sort of tongue-tied state on both sides is where
a communicator is often most useful.
Thus, attaining a true meeting of the minds on both sides is
essential. As you do, dataflow diagrams become a useful architectural
detail for developers to use as a functional model of the system. They
cannot be expected to be accurate or even meaningful to the customers,
though...and should be done late enough in the requirements process
that they only confirm the understanding already arrived at.
Frankly, in your enthusiasm for this one skill, I am often reminded of
the old saw that "when you only have a hammer, every problem resembles
a nail!".
The sort of needs analysis of which I speak is often done in English
accompanied by the sort of screen representations I mentioned, from
both of which the DFD can be usefully constructed.
It is not, as you seem to suggest, a case of sitting down and dreaming
up a diagram as a first step. Inherent in such a hastily-done dataflow
model are assumptions that may have little to do with the realities
the customers face. Lacking an understanding of data modeling, they
may look at your diagram and miss many crucial details...and thus is
the project heading in a wrong direction from the outset.
In other words, the tools you use should match those that must understand them.
At times, I joke when people ask what I do that "I am a translator--I
translate between Geek and English!"
I think your complaint that techwriters "must become less "hands on"
is a major mistake of expression. "Hands on" implies "direct
involvement" as much as it does keyboarding. There are few processes
more "hands on" than interfacing with customers, after all.
The need is for skill in all phases of *communication* including those
that are interpersonal.
Finally, it should not be the techwriter who "takes risks." That is
the province of the project architect and managers. It is the province
of the techwriter to be among those who *reduce* risks for all
concerned--which is, after all, my point in becoming involved earlier
in a project. Since it is often poor communications that result in
problems, does it not make a certain sense that a communicator can be
profitably involved?
David
On Sat, 11 Dec 2004 14:20:21 -0800 (PST), Tony Markos
<ajmarkos -at- yahoo -dot- com> wrote:
> Rigorous requirements analysis requires the "M" word -
> Modeling - like Data Flow Diagrams. And this requires
> taking ones hands off of the keyboard, thinking more
> abstract, and taking more risks.
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.
