Anatomy of a Functional Spec
In my opinion, the purpose of a functional spec is to describe the
application’s functionality and user interface/experience. The spec
should enable developers to begin coding the application. Note that I
don’t view a functional spec as a ‘design’ or ‘technical’ document.
Here’s an outline that I’ve used over the years:
Cover Page - includes the application’s name, spec version, date and
name of author
Table of Contents – makes it easy to locate a section
Introduction – summary of the entire application, its features and
what’s included in the spec
Overview – description of the section’s/page’s functionality
Content – functional wireframes (not designed) for all the pages
which identifying different states (e.g., first time visitor,
returning visitor, etc.). I usually annotate each field with a
footnote (e.g., data values, error messages, etc.) and also describe
what happens whenever a user clicks a button or link
Programming Notes – this is where you can get ‘technical’ and leave
notes for the developers
Appendix – include any supplemental items (e.g., use cases, etc.)
that will help document the application
Anybody care to share their ideas?
Get the feed
Comments
I find that I like to use rendered comps with final visuals in my
functional specs. And I often put the visual specs in the appendix.
That way test/QA can use this document as a resource. It depends what
your design resources and skills are.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46618
Do you need the functional spec? I know it is a common thing, and is
often demanded by QA, but what do you get in return?
If the the goal is to allow developers to start coding then the first
draft of the User Manual could be just as helpful. Complemented with a
test spec these 2 documents could potentially cover the needs of the
functional spec. And these are documents that really are needed.
I'm sure there are some information that does not fit in these
documents, but they can be communicated when needed. Interacting with
the developers is something you shouldn't avoid.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46618
I write specs for music applications. I try to keep the pictures
pretty sketchy, unless when pixel-perfection is required.
We have a basic anatomy of the specs, which looks like this:
Title page
Executive Summary - the elevator pitch of the feature
Goals and Non-goals - what user goals we try to satisfy with the
feature
Revision History - a log of design changes
The stuff - the feature described in appropriate order
Menu reference - changes to the menus
Keyboard Shortcuts - a list of shortcuts introduced
Issues and discussions - collected comments about the spec, including
design ideas.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46618
Functional spec is a summary of the functional analysis I make. It
contains all possible features description, the screen flow for all
interactions (regular flows, errors, alternative flows).
I use UML diagrams to describe features in use cases and show how the
process looks like. Wireframes or screenshots of working prototypes
are used to better explain the UI.
If needed or required I am putting there some usability/accessibility
guidelines and remarks.
This helps avoid missing pages/views. Designers know which
functionalities should be on the screen, developers know how to build
the site (what is going where and how). A very handy stuff if written
short and precisely (no one wants to ready another encyklopedia).
In general, the doc has probably the same structure as Siegy Adler
described.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46618
I'd also add that a Revision History is essential, because this will be a
living document, and it will be necessary to track changes.
RE: Agile lite specs vs. full massive specs, I'd be interested in any
discussion on the usability of spec documents from a technical communication
standpoint (and here is a rich area for T-Com grad students to research and
write papers on).
I believe there are a number of usability issues with the standard
conventions of the massive waterfall-support specs, both for basic
documentation of functionality and interface features, AND their ability to
be even remotely usable as living reference documents for future design
modifications, or new staff on-boarding, etc.
OTOH, Agile lite specs, based on user stories, appear dangerously inadequate
for complex sites and projects, esp. sites that are migrated, or have
multiple dependencies to track over time. I've used an interesting tool
called RallyDev for this on one project, but I supplemented it with some
designs of my own, using a wiki, to provide more dynamic and updatable
documentation specs.
My main thing with wiki spec resource interface designs (I modify the wiki a
bit for my specific purposes) is that I want the specs to LIVE and be
useful, not just get written to make programmers happy, and have no further
uses for stakeholder or team reference.
That said, wiki is good for the nonlinear or hypertextual orientation of the
document design, but not so useful as groupware, when you have people of all
different teams (Creative, UX, CS, Editorial, QA) uploading docs to a
central hub and not always handling the doc naming conventions in the best
way for the wiki system.
Just spinning thoughts.
Chris
On Sun, Oct 11, 2009 at 8:42 AM, Siegy Adler <siegy at scadler.com> wrote:
> In my opinion, the purpose of a functional spec is to describe the
> application’s functionality and user interface/experience. The spec
> should enable developers to begin coding the application. Note that I
> don’t view a functional spec as a ‘design’ or ‘technical’ document.
>
> Here’s an outline that I’ve used over the years:
>
> Cover Page - includes the application’s name, spec version, date and
> name of author
>
> Table of Contents – makes it easy to locate a section
>
> Introduction – summary of the entire application, its features and
> what’s included in the spec
>
> Overview – description of the section’s/page’s functionality
>
> Content – functional wireframes (not designed) for all the pages
> which identifying different states (e.g., first time visitor,
> returning visitor, etc.). I usually annotate each field with a
> footnote (e.g., data values, error messages, etc.) and also describe
> what happens whenever a user clicks a button or link
>
> Programming Notes – this is where you can get ‘technical’ and leave
> notes for the developers
>
> Appendix – include any supplemental items (e.g., use cases, etc.)
> that will help document the application
>
> Anybody care to share their ideas?
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>