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.
Um, you have a lot of work ahead of you. First off, is this a brand new
contract? If not, check to see which of these documents already exist. If it
is a new contract, you probably need to check to see if there are any data
item descriptions (DIDs) for the contractually required documentation. My
personal experience is that not all of this documentation falls to the
technical writer and you'll need to work with those team members who are
responsible for that documentation. I'd look to the members of those teams
to provide a general document and if you see changes that need to be made to
it, I'd work those in and issue that as a guideline.
Good luck.
-Vicki Ruiter
vicki_ruiter -at- sra -dot- com
1. Software requirement description. This should be from the contract.
2. Software Design Description. work with the development teams.
3. The verification and validation plans generally would fall to the team
members conducting the IV&V - the point being that it's independent of the
main contractor.
4. Verification results and validation results report. Also goes to the IV&V
contractor.
5. User documentation. You have to decide what documentation is going to be
needed by the user if it isn't specifically written out in the contract.
User manuals, training documentation, administrator materials, etc.
6. Software configuration management plan. This should be written by your
configuration management team. They are in charge of compliance for whatever
level of CMM the project is supposed to attain.
7. a.Development Process Plan - I don't know why this would be a contract
deliverable, but it would be written by the development teams.
b. Software Development Standards Description. Also bye development
teams. Might include human factor engineering standards, standards formats
for dates, etc.
c. Software engineering methods/procedures/tools
description. Also by development teams probably with input from
configuration management/quality assurance. What software are they using to
write the software, and what standards do they processes do they follow for
peer reviews, etc.
d. Software project management plan. Part of configuration
management/quality assurance/development team documentation.
e. Maintenance plan. Management plan taking into effect legal and
contractual requirements. What is contractually required for the maintenance
of the software?
f. Software Safety Plans. No idea what this. Maybe how you are going
to keep people from cutting themselves on the cds.....
g. Software Integration Plan. This would be a test document. How are
they going to test the integration of software systems in the client
environment? Should meet whatever requirements are necessary for the level
of CMM project requires.
h. Release notes-new features and how NMO will
install the software-last step before the software is put in place.
Installation instructions are generally not a release note. You should know
how the software will be installed before the release note stage and should
be documented in a real document. The release notes generally are a what's
new in this software documentation short and sweet and to the point.
Something that they did not include in here are readme files which usually
are the last step before the software is put in place. This is a .txt file
that is put on the build that is sent to the customer and contains
last-minute technical updates, issues, etc.
i. MS project plans for each service. This sounds internal. Sounds like
the scheduling for the development.
j. Standards documents. Don't know what this is.
k. Technical Style Guide. What are the standards for the documentation?
These may be contractually required or there may already be a style guide
for the branch of service for which you are writing. You'll need to find
this out.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
