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.
Interesting article. I'm embedded in a software requirements analysis
group (six engineers, two writers), and my team's primary responsiblity is
compilation and distribution of the specifications. Clear and consistent
requirements written in plain English are particularly important for us
because the majority of our developers and testers are offshore.
Face-to-face meetings are rare, teleconferences can be difficult to
schedule, and many of the consumers of our documentation are ESL readers.
We don't do a lot of work in pseudocode, as our group's requirements work
is fairly high-level and tends to stay out of the architecture. We handle
a bit of user advocacy (mainly phrasing to use in UIs), but our Human
Factors guys are the primary sources for that. I'd have to say our most
important service is normalizing the language, format, and organizational
structure of the specifications. We spend a lot of time assimilating
requirements from multiple parallel projects, identifying the similarities
and inconsistencies, and getting our engineers to communicate with one
another when those projects start to go in different directions.
We spend surprisingly little time as note-takers. Our first team lead
aggressively hammered home the point that the writers were not here as
overpaid secretaries, and that seems to have stuck with the organization.
In many cases, our role in design meetings is to record decisions directly
in the specifications. Because we maintain the spec repository and wrote
or read _all_ the specs at one point or another, we also serve as as
historians and research assistants.
One of my former managers had a textbook diagram he'd pass around to point
out the importance of getting the specs right up front. The figure often
cited was that the cost of reworking something in the code is about 20x
what it would have cost to rework the same mistake in the specs before
programming and testing began. I like to think that we contribute to that
sort of cost savings. :)
- C.
__
Clayton A. Oliver
Technical Communication Team Lead
Lexmark International, Inc. mailto:coliver -at- lexmark -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
