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.
At the high level: They want to know what business
goals can be accomplish with the system and, MOST
IMPORTANTLY, how do all of these goals interrelate -
particuarly within the context of the implemented
system.
At a lower-level: End-users want to know what tasks
must be performed to accomplish the individual goals
and, MOST IMPORTANTLY, how do all of these tasks
interrelate.
At the detail level: End-users want to know what
specific steps they must follow to accomplish tasks.
Whether we put all of the above in a "Businesss
Overview", "Operations Overview", "Architecture
Overview" "Infastructure Overview" (I'll also throw in
Functional Overview) - who cares. When you strip away
all the hoopla: task = operation = business function =
process; and architecture = infastructure. The reason
why we have all these terms for the same thing has
little to do with logic - it has alot to do with
politics.
Do end-users want to have a "database description"?
Thats too soft: Data wise, end-users want to know what
the essential data entities (objects) are and, MOST
IMPORTANTLY, how they all interrelate. And they may
also want to know about the attributes of these
entities.
AJ Markos -
Focused On the Essential Like a Laser.
--- bridget -dot- fitzgerald -at- thomson -dot- com wrote:
>
> Hello,
> I've been tasked to create a systems document or
> developers' guide. I'm
> actually documenting a pathway that encompasses a
> variety of systems and
> processes. My question to you is what goes into a
> "good" systems guide?
> Are there standard pieces that should be included?
> This is my first one
> of this magnitude (I've only done individual systems
> thus far) and could
> use some guidance. So far, I have the following
> outline:
>
> I. Summary Description
> A. Business Overview
> B. Operations Overview
> C. Architecture Overview
> D. Pathway Monitoring & Capacity
> II. Use Cases
> III. System Descriptions
> IV. Database Descriptions
> V. Infrastructure Overview
>
> Am I missing anything?
>
> Thanks for your help in advance,
>
> Bridget Fitzgerald
____________________________________________________
Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
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.
