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:Tara English-Sweeney <tens00 -at- gmail -dot- com> To:John Posada <jposada99 -at- gmail -dot- com> Date:Tue, 29 Jun 2010 11:02:28 -0400
Hi John. Good to hear from you. Gig is going great. Love it here! Hope all
is well with you. I appreciate all of the responses. The document I wrote is
out for review at this moment. A few days early - woo hoo!
This is interesting because it's a product functional spec and they wanted
use cases. I had some other thoughts on how it should be handled based on
the details of the request- less use cases and more feature/function
descriptions, but had to live with the way it was done historically. So, I
have a first cut and apparently, everyone thinks it should be better than
anything we've had in the past. This will be a living document, of course
and we will add more going forward. A lot of the idea behind this was more
to protect ourselves from customers pointing fingers and saying that we
weren't clear in the way our product functions or to protect ourselves from
them thinking that something could be done that can't.
Off to get familiar with the next project on my plate - an SDK. Interesting
> Hey, Tara...how are ya? How's the gig?
> To answer your question, which I don't know if it was before going off
> on a tangent, I see no difference with creating an FS on a system
> before or after build, except that the FS after the build might be a
> little more accurate. Don't let the state of the application confuse
> you...just write it as you would a normal FS. When I've written them
> post development, they were more an "As built" document, oten becaus
> they wanted to upgrade but before they could, they needed to know what
> they had so they could write the spec for the next generation.
> However, what does have an influence is that it is beiong asked for by
> marketing. Because of this, the FS should have more benefit-related
> information. Every feature you describe, instead of just how it
> functions, should have something about what impactt that function has
> on the user who is using it.
> Picture marketing writing their stuff base don this FS. You want them
> to have an accurate picture of the feature impacts.
> John Posada
> Senior Technical Writer
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-