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.
Subject:Re: What type of document is this? From:"Brezinski, Brittany" <brittany -dot- brezinski -at- bestwestern -dot- com> To:"techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 29 Feb 2012 17:55:35 +0000
Hi, Sean!
I am not aware of any industry-standard term for your document, but I can share with you what my department called the documents for our products. This was at my last job where we had one writer per product before we switched to the agile method for our software development. I may be forgetting a document or two, but we had a hefty set of documents for awhile. I didn't provide descriptions for each document, so please let me know if you have questions.
For individual projects, we had the following document set:
- Business Requirements
- Functional Requirements
- Functional Specification
- Functional Design Description (different from the FD below, as this one only described the changes of the functions/features included with the release)
- Release Notes
Then, for each product, we had the following set of documents:
- Functional Description (FD) - I think this is the one that is similar to your unidentified document. It described the complete functional design of the product including features, functions, user types, roles, and purpose of each screen/page. It did not include any procedures. It was intended for the Product Developers to help them understand the users' perspective for the GUI when they started planning for a new release. It was also given to the marketing team and prospective customers (at a management level, not end-user) with the marketing information to help sell the product.
- Help (function/feature description-based)
- User Guide
- Training Guide
- Administrators Guide
- Marketing Brochure
- Product Description
After we switched to the agile method, our document set was reduced to the following and our group was diminished to a couple of writers.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
