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.
|> Our management has given my entire
|> project group (programmers, testers, presales people, and writers) the job
of
|> creating system documentation that potential partners could use to evaluate
our
|> system to determine if they would be interested in investing in it.
[...]
|> what kind of
|> information should this document contain? What shouldn't it contain, if
|> anything?
This depends.
Are you looking for investors so you can finish developing the product,
or is it all done, and you need the cash for marketing and distribution?
If it is a work in progress, you are in better shape, since you can
produce draft documentation. For an audience that consists of potential
investors, I would get my hands on the product specs if you have them,
and I'd spend time creating some specs in collaboration with your
developers if don't. IEEE gives some good models to follow - I'd show a
requirements analysis and a design spec at the very least. You could
show some functional specs within requirements, or as part of design;
something that says what the product will eventually do, as you've
designed it. Then maybe some introductory information. If you have time,
go ahead and finish the introductory guide.
If you have a working product, and specs too, start by developing an
introductory guide and some usage information. It sounds like the nature
of your product might lend itself to heavy-duty reference documentation,
but I'd just *plan* the reference set and concentrate on completing
concept information, definitions, and maybe complete reference for one
or two of the product's areas of function (notice I didn't say
"functionality" here ;-). Then, I'd wrap all that together with the
specs as an appendix to the business plan you are showing your potential
moneymen; they will want to see a business plan, you know - market
potential, development costs, revenue projections, a marketing plan,
reference clients if this is in partial release somewhere, and
naturally, when you think the product will be profitable..
But I can't give hard and fast rules via newsgroup, as unfamiliar with
your whole situation as I am, so view these as suggestions.
Does that help any?
--
Len Olszewski My opinions; you go get your own.
saslpo -at- unx -dot- sas -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
