Define a functional spec

7 Oct 2009 - 2:02pm
4 years ago
13 replies
1545 reads
Siegy Adler
2009

Here's my definition...

A functional spec is a document that describes, in non-technical
terms and illustrations, what a Website, or Web-based application,
will look like and how it will function. A good functional spec,
which should be based on stakeholder requirements, provides
developers with the information they need to code the application.

When asked to describe what a spec is, I often use the following
construction analogy:

1) The property owner (i.e., stakeholder) meets with the architect
(i.e., spec writer) to describe the structure (i.e.,
Website/application) they want built
2) The architect drafts the blueprint (i.e., spec)
3) The contractor (i.e., developer) builds the structure based on the
blueprint

Do you agree?

Comments

8 Oct 2009 - 1:52am
Anonymous

Perfect. 1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482

8 Oct 2009 - 7:08am
Adrian Howard
2005

On 7 Oct 2009, at 12:02, Siegy Adler wrote:

> When asked to describe what a spec is, I often use the following
> construction analogy:
>
> 1) The property owner (i.e., stakeholder) meets with the architect
> (i.e., spec writer) to describe the structure (i.e.,
> Website/application) they want built
> 2) The architect drafts the blueprint (i.e., spec)
> 3) The contractor (i.e., developer) builds the structure based on the
> blueprint
>
> Do you agree?
[snip]

Only if it's like architecture is in real life (where the contracter
will then tell the architect that X and Y can't be done because of Z,
and the Q will cost three times the amount of money than expected -
and they'll both go back to the client, and tweak things, and move on,
and discover new problems, tweak the plans, tweak the building, and
work it out together, etc.)

In my experience if you ask any architect about the relationship
between the original plans/blueprints of any non-trivial construction
and the building that got constructed you are guaranteed an
interesting conversation.

That's not because the original blueprints were wrong... it's that a
building is always more than the blueprints.

Specs in software are the same.

Cheers,

Adrian
--
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh

8 Oct 2009 - 8:18am
EugeniaOrtiz
2009

I think that a spec, as you say, describes what an application
"should do" (function) but not how it should looks like
(structure). I think that is made on the design stage. What do you
think?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482

8 Oct 2009 - 8:34am
David Lambert
2009

The construction analogy is a compelling one because it *seems* to be
so similar to what we do, but the analogy breaks down in a couple of
key areas.

First, there is far more standardization in Civil Engineering than in
software. As a home buyer, you can ask for a 2-car garage with one
door and a 2' bump on the left side (elevation to match house), and
you've done a fairly good job of specifying what you want to see in
a garage.

Adequately specifying software behavior is a lot more complicated
because there's so much more variation in how things can operate,
even within the realm of "mainstream" designs. The same is true of
architecture, by the way, which has no guidance equivalent to the
building codes that guide Civil Engineers.

The other aspect of this that people tend to gloss over is that when
you build a house, you specify structure with an architect, but then,
when it's time to put in wiring, fixtures, etc., chances are, you're
meeting with someone else so that you can specify those "detail"
items. This can be difficult in software, because it's not obvious
to anyone but a software engineer which piddly little details are
5-minute changes, and which ones require massive retro-fitting or
redesign.

Bottom line: I think the analogy works if you keep it to a *very*
high level, but it's important to understand where it starts to
break down.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482

8 Oct 2009 - 12:10pm
jabbett
2008

It sounds like a useful analogy, but it's incomplete.

I imagine that an architect knows both how inhabitants interact with a
building and how the component parts of the building come together
(steel, wood, nails, etc.). Also, an architect still will need an
HVAC engineer, a landscape architect, an electrician, etc., to design
the other systems that the inhabitant doesn't really see/think
about/interact with.

I've found that some designers expect that software developers are
like those 3D printers -- the designer writes the CAD file and the
developer just robotically "prints out" the software. No doubt, more
software gets outsourced to incompetent development teams because of
this misconception.

In software, there's also another layer in there, because interaction
design is separate from software design. Your completed design
doesn't tell a developer exactly what architecture, what database,
what application platform, what programming language to use. It
doesn't tell him what database objects to model, or what classes to
define. A great deal of design takes place after the "design" is
complete.

So, your whole collection of design artifacts work together to create
a vision of the completed product, and they should all be used
together (in addition to formal requirements for things that the user
doesn't see) to communicate with your customers and your developers.
Designers then need to stay involved during the development process to
reformulate portions of the interaction design as conflicts with the
software design arise.

I would suspect that architects, too, stay involved during construction ;)

Best,
Jon Abbett
jonathan at abbett.org

On Wed, Oct 7, 2009 at 8:02 AM, Siegy Adler <siegy at scadler.com> wrote:
> Here's my definition...
>
> A functional spec is a document that describes, in non-technical
> terms and illustrations, what a Website, or Web-based application,
> will look like and how it will function. A good functional spec,
> which should be based on stakeholder requirements, provides
> developers with the information they need to code the application.
>
> When asked to describe what a spec is, I often use the following
> construction analogy:
>
> 1) The property owner (i.e., stakeholder) meets with the architect
> (i.e., spec writer) to describe the structure (i.e.,
> Website/application) they want built
> 2) The architect drafts the blueprint (i.e., spec)
> 3) The contractor (i.e., developer) builds the structure based on the
> blueprint
> Do you agree?
> ________________________________________________________________
> 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
>

8 Oct 2009 - 3:39pm
Siegy Adler
2009

Eugeo,

I agree that the functional spec is not a design document. However, I
believe it is useful to include high level wireframes of the items to
be displayed on the page, etc.

Best regards,

Siegy

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482

8 Oct 2009 - 4:20pm
Thomas Petersen
2008

The problem with the analogy is that is implies static composition.
(i.e. property, architect, structure)

What I would look for is digital ecosystem

Environment, interaction, nodes, data i.e. something in constant
flux, constantly evolving.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482

8 Oct 2009 - 3:55pm
Mr Bootle
2009

My understanding is in line with Eugeo.

A functional spec is that, functional, it describes what the app is
to do, ie tasks. The design does not feature in that document. That
is a separate document and separate requirement. Sure, wireframes can
help the spec but it has nothing to do with how it works.

I use functional specs (or story writing in agile) so the developers
can start programming immediately while the designers can start on
the wireframes and ui.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482

8 Oct 2009 - 3:00am
Wynn Xiao Wu
2009

Why can't we skip the documentation step altogether and document with
rapid prototyping...

For websites / app it would be:

1)Stakeholder sits with Designer/Builder
2)Designer builds wire frame prototype using something like
Jumpchart.com
3)Designer and stakeholder iterate through design on prototype
4)Application / Site evolves from prototype

Essentially there are no unnecessary documents created or work being
done. The spec is the prototype which turns into the product. If
anything, the 'functional spec' is a one sheet a paper which
essentially says "Build according to prototype."

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482

9 Oct 2009 - 7:42am
Charusmitha Ram
2008

I would describe a functional spec as a contract between the product
team and the development team that defines all the modules that needs
to be implemented in the product so that the dev team can figure out
the technical requirements.
This is NOT applicable for a truly agile model, is somewhat useful for
a semi-agile environment and is quite essential for older traditional
models. But I think the origin of a functional spec is from older
models.
In semi-agile environments it is created in tandem with design
documentation and updated as the design iterates. In older models it
is created after the design phase is done. (obviously this is very
inefficient).

Sent from my iPhone

9 Oct 2009 - 8:30am
Adrian Howard
2005

On 8 Oct 2009, at 06:18, Eugeo wrote:

> I think that a spec, as you say, describes what an application
> "should do" (function) but not how it should looks like
> (structure). I think that is made on the design stage. What do you
> think?

I think that what the application "should do" and how it should look
are often more closely related than people think - and separating the
two can sometimes cause more harm than good.

Adrian

--
http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh

9 Oct 2009 - 8:40am
Santosh
2006

In my opinion when you are writing a functional spec it should be complimented atleast with a wireframe. This will set stage for designs which can come a little later than the functional specs and the wireframes.

________________________________
From: Adrian Howard <adrianh at quietstars.com>
To: IXDA list <discuss at ixda.org>
Sent: Friday, October 9, 2009 9:30:33 AM
Subject: Re: [IxDA Discuss] Define a functional spec

On 8 Oct 2009, at 06:18, Eugeo wrote:

> I think that a spec, as you say, describes what an application
> "should do" (function) but not how it should looks like
> (structure). I think that is made on the design stage. What do you
> think?

I think that what the application "should do" and how it should look are often more closely related than people think - and separating the two can sometimes cause more harm than good.

Adrian

--http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh

________________________________________________________________
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

9 Oct 2009 - 10:34am
Charusmitha Ram
2008

On Fri, Oct 9, 2009 at 9:40 AM, Santosh <santsub at yahoo.com> wrote:

In my opinion when you are writing a functional spec it should be
> complimented atleast with a wireframe. This will set stage for designs which
> can come a little later than the functional specs and the wireframes.
>

Not sure of the above. If the wire frames and interactions are handled in
the design document (which should be the case), I don't see the need for
including including a wire frame in a functional spec. A functional spec is
simply an inventory of tasks within specific modules. Designers have very
little to contribute directly to a functional spec as these are owned by the
product managers solely to communicate implementation requirements to the
development team. I would not want any of my design artifacts to be used
here.

Syndicate content Get the feed