Re: Definition of a functional spec

[Susan Harkus <susanh -at- CARDSETC -dot- COM -dot- AU>]

Michelle,
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.

Susan Harkus
Cards Etc Pty Limited

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=