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.
Use Cases are an analysis tool. There are two major
categories of analysis tools: Those that employ a
forced, artificial chunking (systems analysts use the
term "partitioning" )of the system and those that
employ a natural,logical chunking of the system.
Use Cases are of the first category - they employ
forced, artificial chunking. The basic steps: FIRST
the analyst draws circles, squares, ovals, stickmen -
whatever. THEN the analyst trys to figure out how to
link them all together.
There are, of course, other things that are done in
creating a Use Case, but understanding that Use Cases
require the analyst to FIRST draw the functions or
objects (i.e, boxes, ovals, etc)is of the highest
importance! Why? Because what the analyst is doing
is, up-front, putting his/her limited understanding of
the system functionality down on paper and then trying
to force reality to fit into that limited
understanding in linking them together. The
inevitable result: A diagram that is going to miss
many essential requirements - especially for
larger-scale systems.
Analysts who use techniques that employ logical,
natural partitioning of a system, in contrast, make no
up-front determination of system functionality -
ovals, boxes, etc are NOT drawn first. Instead the
analyst follows the natural flow of things and is
proded, when flows naturally combine or split apart,
in identifying functions (ovals, boxes, etc). Logical
"holes" in the analyst understanding don't remain
hidden until design - they are made glaringly obvious
in analysis. The result: A model that is is rigorous
and comprehensive - especially for larger-scale
efforts.
AJ Markos
> Anthony wrote:
>
> > Can anyone explain the authoring and preparation
> of
> > use cases and the process of putting one together?
>
> > This will be done in a software development
> > environment for an ERP product.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
Doc-To-Help 2005 now has RoboHelp Converter and HTML Source: Author
content and configure Help in MS Word or any HTML editor. No
proprietary editor! *August release. http://www.componentone.com/TECHWRL/DocToHelp2005
---
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.
