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:Tony Markos <ajmarkos -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 27 Oct 2004 18:20:34 -0700 (PDT)
--- Dick Margulis <margulisd -at- comcast -dot- net> asks:
.....When I've worked with DFDs they have been very
instructive in terms of software design (what messages
flow in which direction between software
modules; what data goes in and out of which db
tables); but they have had little or nothing to do
with user tasks....
Tony Markos responds:
Key concept: Data Flow Diagrams have nothing
inherently to do with computer systems analysis or
design. DFDs where first used almost fifty years
before the computer was invented. In the late 1890's
there were no software functions, just people and
their tasks.
DFDs can be used for tech comm of computer systems,
but they can just as easily be used to document
completely manual procedure.
Dick Margulis asks:
How do they [DFDs] differ from use case diagrams?
Tony Markos responds:
Hugely - especially for task analysis! I recently
initiated a thread on the Requirements Engineering
listserv that included discussion of this very matter.
Data Flow Diagrams actually prompt you through a task
analysis. With DFDs we follow each data flow from
start to finish. When the flows in our DFD naturally
combine or split apart, we have "flushed-out" an
essential task that may otherwise have gone
undiscovered. Thats what analysis is - a discovery
process.
In contrast, with Use Case diagrams, we are forced to
play the old connect-the-box (or oval) game: We draw
Use Case ovals for the tasks that happen to pop into
our mind; then, we try to connect each oval to actors
and/or other Use Case ovals. This results in the age
old problem: Whenever we try to perform analysis buy
connecting together boxes, as opposed to following the
data flows, we are going to miss a lot of important
tasks - especially in larger-scale analysis efforts.
Avoidance of Connect-The-Box is THE fundamental
principle behind DFDs.
The other very important difference between Use Cases
and Data Flow Diagrams for task analysis is that Use
Cases are fundamentaly a bottom-up analysis technique
(at least compared to DFDs). DFDs are a true top-down
technique. Whenever we try performing a larger-scale
analysis in a bottom-up fashion, we end up "drowning
in an ocean of detail".
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.
