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.
Re: Writing a product functional spec AFTER the product is built
Subject:Re: Writing a product functional spec AFTER the product is built From:Keith Hood <klhra -at- yahoo -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com, Tara English-Sweeney <tens00 -at- gmail -dot- com> Date:Sun, 27 Jun 2010 20:26:38 -0700 (PDT)
I've had to do this about half a dozen times. Usually it's because they want to modify the product, and the first version of the product was never documented or the documents are wrong. Sometimes it's because the company is trying to get a government contract that requires them to have documentation of all the software tools they use, and they didn't bother to document the thing when they built it. For a while it seemed like I had become a specialist in retroactive build documents. I had to do a LOT of hands-on testing to see what the software actually did. I usually had to start by writing and running test scripts, complete with deliberate false inputs, and recording screen changes and outputs. Then I could develop "requirements" from those results.
Just remember the audience doesn't know your documents are retroactive, and they don't need to know
that. There's no real difference in the requirements or use cases now or before the product is built. The documents still have to describe accurately what the software should do in which circumstances. They still must explain what the user should expect from the software - what they have to put in and what they should expect to see, hear, or smell coming back out.
If your stumbling block is an introduction, I suggest you schedule a meeting with both the product manager and the marketing department, and the three of you try to work out what they want the introduction to do for or to the customers.
From: Tara English-Sweeney <tens00 -at- gmail -dot- com>
Subject: Writing a product functional spec AFTER the product is built
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Sunday, June 27, 2010, 10:34 PM
Hello. I am wondering how often technical writers have been asked to write a
product functional specification after a product has been built. I have been
working feverishly on one. The goal is for it to be used as a sales tool and
even more importantly, to ensure that customers have a clear definition of
the the features and functions (via use cases) so there is no
misinterpretation.
Needless to say, my first cut is nearly done and I'm trying to write the
introduction. However, in my experience this is a document that is typically
created before the software is created. I have been searching the web for
examples of these documents or definitions to help me write my introduction
but I can't seem to find anything out there!
Has anyone done anything like this? I'd love to hear your experiences. Also,
if anyone can point me to resources of similar documentation, I'd appreciate
it.
Gain access to everything you need to create and publish information
through multiple channels. Your choice of authoring (and import)
formats with virtually any output. Try Doc-To-Help free for 30-days. http://www.doctohelp.com/
---
You are currently subscribed to TECHWR-L as klhra -at- yahoo -dot- com -dot-
Gain access to everything you need to create and publish information
through multiple channels. Your choice of authoring (and import)
formats with virtually any output. Try Doc-To-Help free for 30-days. http://www.doctohelp.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-