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.
With data flow diagrams, a person can docment a large number of systems and limit the size of any diagram to about 8 1/2" by 11".
If by NOC you mean the Network Operating Center, that is part of who my end users are. Sounds like it: Seeing interrelationships between systems and diagramming transaction flows.
John Posada <jposada01 -at- yahoo -dot- com> wrote:
> can be handled without that much trouble. If I have a big 7 foot by 10 foot
> diagram (as John mentioned), then changes become unwieldly alot quicker.
The only reason I had to keep everything in one diagram was that we were looking at 11 systems and the data flowed in and out of the system. Part of the reason for the diagram was for the NOC, they wanted to be able to follow the impact on one system if the data was uninterruped in another. In other words, what is the impact to SAP if one of the SQL databases or a connection to/from went down. Therefore, they needed to put their finger on one point and follow the line as it went in and out of the other systems.
Senior Technical Writer
"They say everyone needs goals. Mine is to live forever.
So far, so good."
----- Original Message ----
From: Richard Lewis <tech44writer -at- yahoo -dot- com>
To: Laura Lemay <lemay -at- lauralemay -dot- com>; John Posada <jposada01 -at- yahoo -dot- com>
Cc: techwr-l -at- lists -dot- techwr-l -dot- com
Sent: Thursday, October 4, 2007 3:27:54 PM
Subject: Re: Unique Documentation
One of the objectives with my web-based set of drill-down diagrams is a way of organizing for reteival a whole bunch of legacy docs. Obviously, the diagrams have to be relatively stable to suite that purpose.
So how do I handle the changes?
I am contracting with a large company that is very web intensive and is rapidly changing. However, at the higher levels, the basic functions do not change . Additionaly, I have a series of 8 1/2 by 11 diagrams, and the changes affecting one or more of them can be handled without that much trouble. If I have a big 7 foot by 10 foot diagram (as John mentioned), then changes become unwieldly alot quicker.
Laura Lemay <lemay -at- lauralemay -dot- com> wrote:
As John says the biggest problem [with a set of drill-down diagrams for system documentation] was with maintenance as the system was
dynamic and constantly changing. The web-based diagram was a particular
PITA to keep updated and once I left the company I'm told it rapidly
went out of date.
Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out.
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-