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.
You espouse an approach to Task Analysis that is, in
one way, very solid: Proceed in as top down a fashion
as possible.
Such an approach, especially for larger systems, is
critical. A major cause of failure in projects is
trying to perform Task Analysis in a bottom-up
fashion. Closely related, and even more failure
prone, is the TW jumping right away into an ocean of
design detail - and then drowning in those details.
But with your approach, the Task Analyst draws a
hierarchy of task boxes, and then trys to
appropriately connect the boxes together. There is a
significant flaw with such an approach, which is
readily seen when comparing that approach with the
only technique that addresses the flaw: Data Flow
Diagrams.
With Data Flow Diagrams, we follow the flows of data
through the system. When our data flows naturally
combine and split apart, we have flushed out an
essential task that very well may have otherwise gone
undiscovered during the analysis. And at its root,
Task Analysis, like all analysis, is a discovery
process.
With a connect-the-boxes approach (such as in
hierarchal decomposition) only the functions that
readily pop into the Task Analyst's head are
identified. The "holes" in our Task Analysis are not
made glaringly evident - we are not prompted to
discover what we do not know.
Note: The connect-the-boxes approach is also very
common in Systems Analysis. It, along with being
fundamentally bottom up, is the tragic flaw of Use
Cases.
Tony Markos
--- Jon -at- taskarchitect -dot- com wrote:
......For instance you could have an overview document
outlining the high level tasks of
product use, then sub-documents that describe each
sub-task.
.... there?s more information about the tool at
www.TaskArchitect.com.
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today! http://vote.yahoo.com
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 ejray -at- raycomm -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
