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
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
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
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
To: IXDA list disc...@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
On Fri, Oct 9, 2009 at 9:40 AM, Santosh sant...@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
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
Perfect. 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=46482
Welcome to the Interaction Design Association (IxDA)!
To post to this list
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
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
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,
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
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.
. . . . . . . . . . . . . . . . . . . . . . . . . .
13 matches
Mail list logo
