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.
: How do you do this? Do you get at least a feature list from the developers
: to start with, and then just develop a list of questions from there? Do
: you go ahead and try to figure out 90 percent of the system before you talk
: to the developers, or do you expect them to be able to explain the system's
: basic concepts and everything to you? What mechanisms do you have in place
: for when they change their systems (either in the underneath, how-it-works
: part, or in the interface)?
At my previous company, we had original design specs that had to be approved
by development and mgmt. Specs addressed both the externals and the
internals of the new features. Often, TWs could snag a good bit of base doc
from there.
Changes to design had to be in Design Change Requests, which had to also be
approved by mgmt. DCRs were usually new features that came up after the
initial specs. Documentation in DCRs were more rudimentarry.
Specs and DCRs could, but were not required to, mention doc hits.
Once the code went to test, problems and bugs were tracked with problem
Tracking Reports, initiated by QA, Development would have to 'check out' the
code, fix the bug, return the code, and have the PTR closed by QA. PTRs had
an additional tag if there was a doc hit. But again, a doc hit did not have
to be flagged. And PTRs could be written against the doc.
Specs, DCRs,and PTRs helped the process. At least they gave me a clue that
something new or different was happening, if not to fully explain the
change, enough so that Icould turn to the programmers and ask what was going
on, get the new code, andrun it for myself.
Ofcoourse, I also got to play with code myself, and find bugs, and write
PTRs, against code and doc. Some programmers appreciated my playing dumb
user before the code got to QA, finding bugs before the coders took an
official PTR hit.
Anyway, I've wasted enuf space for now.
Did this help any?
--
-----
Dan 'Fergus' Roberts
droberts -at- panix -dot- com
-----
