Functional Specs (long and getting longer) [signed]
19 Mar 2006 - 10:31am
7 years ago
There has always been a sense about web development that everything must be
new and other disciplines have nothing to add to what we are doing.
Particularly since web development has been done in a hurry. Remember that
old adage that Internet time was like dog years...
My view of the FS is that of a blueprint: you would never invest the
millions of dollars needed to build a bridge or a building without knowing
exactly what was required. Web development, interaction, digital, rich media
(whatever it is we do) design has to be done to the same or similar
standard. We have been lucky since most people don't know what it is we do
and if necessary we can bullshit them out of our office: but that is a
The FS is the blueprint for everyone involved in the project: the wacky
marketing people, the odd IT folks, and the receptionist. Just like a
blueprint it explains what we what to do and what we have to do. It gives us
criteria to show the completed project as completed. It helps us control the
The particular scope that I worry most about comes not from the client,
which I can manage, but from programmers. It is the programmer working alone
who comes to a decision point and says "I think this works better so I am
going to add this feature" that scares me the most. So I want a good FS that
everyone understands there to guide that person and everyone else involved
in the project. There is a lot of creativity that goes into writing the
specification: there is no creativity (or very little) in following it.
In general parlance: a bad FS is better than none. So without a strong
standard what do we do? The best thing is to review and debrief projects
after they are done. In order to do that we need to document them well
beyond what we *want* to do. As well it can be difficult to find the time to
talk about old projects but without this process we don't have enough
information to improve the next project.
Internet Presence Management http://www.iaai.camonette at iaai.ca 416 469 4337
> > [Please voluntarily trim replies to include only relevant quoted material.] > > Interesting stuff. Jason Fried's rant-lette is thought-provoking. I think > we've all experienced his frustration with the funk-speck as an appeasement > document (which says more about the poverty of the team's process than a > weakness of the document itself). > > That brings us to the focal issue of "audience". When viewing the > Functional Spec, business stakeholders have one agenda, tecchies another. > The biz guys are looking at business requirements and workflow, the tecchies > are looking at data structures and code objects. A Functional Spec tries to > provide the common ground for both worldviews: > * It is a set of screen-based visual images + behaviors > * that reflects the goals and tasks that have been described by the business > side > * as well as the constraints and requirements of the technical environment > The trick is to create a document that someone actually wants to read. > > > JF >So what do we do in place of a functional spec? We write a one page > story about what the app should do. > > Jason's "one page story" is the accessible, descriptive overview that > should accompany any well-conceived discussion. In my own writing, I append > such an overview at the head of *every* document produced for the project: > It is the context for all that follows. > > And we SHOULD push active design to the forefront: Most decision makers see > the "vision thing" of what we're creating as a dance of screens, not as an > abstracted Visio diagram (just watch their eyes glaze over). The sooner > it's HTML, the better. > > But you gotta capture the total thought process on something, somewhere - > You might want to call it a "functional specification". Note: I generally > try to "annotate" my HTML prototypes with funcspec info, so that the model > is itself a living document, but a good ole paper document has its > advantages. > > Observation > You know the story: They've already produced 50,000 lines of code - and now > they call in an IxD person to "make it usable". Often one of the first > things I do is to capture "what it is" in a Functional Spec (which never got > written in the first place). It's scary how many software products move > forward without capturing the basics... >
------------------------ [ SECURITY NOTICE ] ------------------------
To: discuss at lists.interactiondesigners.com.
For your security, monette at iaai.ca
digitally signed this message on 19 March 2006 at 15:31:40 UTC.
Verify this digital signature at http://www.ciphire.com/verify.
------------------- [ CIPHIRE DIGITAL SIGNATURE ] -------------------
--------------------- [ END DIGITAL SIGNATURE ] ---------------------