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: Definition of a functional spec From:Susan Harkus <susanh -at- CARDSETC -dot- COM -dot- AU> Date:Thu, 3 Jun 1999 09:17:25 +1000
I don't disagree with any of the recommendations that have been posted on
functional specifications but I do think there is an alternate approach.
Who will use the information in your functional spec? Analyse the
information needs of your users and prototype some information
capture/presentation formats. When you and your users agree on what they
need, review the prototype and see what you can leave out. Get agreement on
the final format and start writing. This is really quite a short
develop-refinement cycle if all stakeholders are available to provide
feedback. One or two days?
For example, in my previous job and now, the client functional spec is used
to develop test cases and also as the primary source of Help information =
clear functional descriptions of all user operations. In my current job,
the client functional spec is also used by the developers ... in most
cases, that does not require more information than is needed for the other
two uses but sometimes it does. For example, identifying the type of a
message box prompt.
Servicing product maintenance people is less important for a functional
spec than a design spec because developers and writers will go straight to
the product to see how it currently behaves. No one wants to read if they
can avoid it.
Although people talk about document types, it all comes down to the fact
that people have their own expectations about what a document should
contain based on their information requirements. Even if your organisation
says it needs a functional spec, what that item becomes will be a
customised solution that meets the stakeholders' needs.