Functional Specs

18 Mar 2006 - 2:40pm
8 years ago
13 replies
817 reads
Amnon Dekel
2005

This is a serious issue. At my startup we are tryng hard to find the best
trade off between spec'ing and wasting time. Although I wrote a 200 + page
UI spec for our app, I think the following article is VERY relevant. Here
is an excerpt.

---- Excerpt ----
*Step 1: Don't write a functional specifications document*
Don't write a functional specifications document. Why? Well, there's nothing
functional about a functional specifications document.

Functional specifications documents lead to an illusion of agreement. A
bunch of people agreeing on paragraphs of text is not real agreement.
Everyone is *reading* the same thing, but they're often *thinking* something
different. This inevitably comes out in the future when it's too late.
"Wait, that's not what I had in mind…" "Huh? That's not how we described
it." "Yes it was and we all agreed on it — you even signed off on it." You
know the drill.
The full text can be foud at:
http://www.37signals.com/svn/archives/001050.php (make sure you read the
comments).

I do a lot of Mocking Up in my work (usually using Director). I find it very
useful in many cases. But I don't think a mockup can be a full replacement
since it takes time and money to mock things up. Still looking for the
golden tradeeoff.

Amnon Dekel

Comments

18 Mar 2006 - 4:05pm
mojofat
2004

It seems to me that he's really saying "Write a functional spec in this
way" and not really "Don't write functional specs." He even says
explicitly: "The interface is the functional spec."

Although I see where he's going, and I see a some value in it, I think
there are two important things missing from this opinion. First, specs
(in my opinion) are meant to be discussed and not just read. This
means discussing them with the principal players in the project,
iterating the design, and really putting in the skull sweat upfront.
I've seen and been on way to many projects where code was wholesale
thrown away b/c there was no work done upfront. Second, I think this
author is assuming that specs are written in a waterfall methodology.
Again, I think the spec process is wholly important and requires
getting all the people discussing it. A UI mockup is good, but it's
not going to be readily obvious all the time what each little widget or
interaction point is supposed to do...or maybe how it relates to the
system as a whole.

Specs...when used correctly...are not about making people "feel
involved." They're about actually involving people and, hopefully,
making all of your mistakes upfront in the early phase instead of later
when a group of programmers are already well down the road. I think we
would be hard pressed to find an example of a successful software
product (sales and user satisfaction) that didn't begin life as a
successful spec as well.

Regards,

-al

On Mar 18, 2006, at 12:40 PM, Amnon Dekel wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> This is a serious issue. At my startup we are tryng hard to find the
> best
> trade off between spec'ing and wasting time. Although I wrote a 200 +
> page
> UI spec for our app, I think the following article is VERY relevant.
> Here
> is an excerpt.
>
> ---- Excerpt ----
> *Step 1: Don't write a functional specifications document*
> Don't write a functional specifications document. Why? Well, there's
> nothing
> functional about a functional specifications document.
>
> Functional specifications documents lead to an illusion of agreement. A
> bunch of people agreeing on paragraphs of text is not real agreement.
> Everyone is *reading* the same thing, but they're often *thinking*
> something
> different. This inevitably comes out in the future when it's too late.
> "Wait, that's not what I had in mind…" "Huh? That's not how we
> described
> it." "Yes it was and we all agreed on it — you even signed off on it."
> You
> know the drill.
> The full text can be foud at:
> http://www.37signals.com/svn/archives/001050.php (make sure you read
> the
> comments).
>
> I do a lot of Mocking Up in my work (usually using Director). I find
> it very
> useful in many cases. But I don't think a mockup can be a full
> replacement
> since it takes time and money to mock things up. Still looking for the
> golden tradeeoff.
>
> Amnon Dekel
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>
>

18 Mar 2006 - 7:54pm
Jan Koehler
2005

I agree 100%

On Sat, 18 Mar 2006 2:32 pm, Allen Smith wrote:
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> It seems to me that he's really saying "Write a functional spec in this
> way" and not really "Don't write functional specs." He even says
> explicitly: "The interface is the functional spec."
>
> Although I see where he's going, and I see a some value in it, I think
> there are two important things missing from this opinion. First, specs
> (in my opinion) are meant to be discussed and not just read. This
> means discussing them with the principal players in the project,
> iterating the design, and really putting in the skull sweat upfront.
> I've seen and been on way to many projects where code was wholesale
> thrown away b/c there was no work done upfront. Second, I think this
> author is assuming that specs are written in a waterfall methodology.
> Again, I think the spec process is wholly important and requires
> getting all the people discussing it. A UI mockup is good, but it's
> not going to be readily obvious all the time what each little widget or
> interaction point is supposed to do...or maybe how it relates to the
> system as a whole.
>
> Specs...when used correctly...are not about making people "feel
> involved." They're about actually involving people and, hopefully,
> making all of your mistakes upfront in the early phase instead of later
> when a group of programmers are already well down the road. I think we
> would be hard pressed to find an example of a successful software
> product (sales and user satisfaction) that didn't begin life as a
> successful spec as well.
>
> Regards,
>
> -al
>
>
>
>
> On Mar 18, 2006, at 12:40 PM, Amnon Dekel wrote:
>
>> [Please voluntarily trim replies to include only relevant quoted
>> material.]
>>
>> This is a serious issue. At my startup we are tryng hard to find the
>> best
>> trade off between spec'ing and wasting time. Although I wrote a 200 +
>> page
>> UI spec for our app, I think the following article is VERY relevant.
>> Here
>> is an excerpt.
>>
>> ---- Excerpt ----
>> *Step 1: Don't write a functional specifications document*
>> Don't write a functional specifications document. Why? Well, there's
>> nothing
>> functional about a functional specifications document.
>>
>> Functional specifications documents lead to an illusion of agreement.
>> A
>> bunch of people agreeing on paragraphs of text is not real agreement.
>> Everyone is *reading* the same thing, but they're often *thinking*
>> something
>> different. This inevitably comes out in the future when it's too late.
>> "Wait, that's not what I had in mind…" "Huh? That's not how we
>> described
>> it." "Yes it was and we all agreed on it — you even signed off on
>> it."
>> You
>> know the drill.
>> The full text can be foud at:
>> http://www.37signals.com/svn/archives/001050.php (make sure you read
>> the
>> comments).
>>
>> I do a lot of Mocking Up in my work (usually using Director). I find
>> it very
>> useful in many cases. But I don't think a mockup can be a full
>> replacement
>> since it takes time and money to mock things up. Still looking for the
>> golden tradeeoff.
>>
>> Amnon Dekel
>> ________________________________________________________________
>> Welcome to the Interaction Design Association (IxDA)!
>> To post to this list ....... discuss at ixda.org
>> List Guidelines ............ http://listguide.ixda.org/
>> List Help .................. http://listhelp.ixda.org/
>> (Un)Subscription Options ... http://subscription-options.ixda.org/
>> Announcements List ......... http://subscribe-announce.ixda.org/
>> Questions .................. lists at ixda.org
>> Home ....................... http://ixda.org/
>> Resource Library ........... http://resources.ixda.org
>>
>>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org

18 Mar 2006 - 8:51pm
Dan Saffer
2003

On Mar 18, 2006, at 2:05 PM, Allen Smith wrote:

> It seems to me that he's really saying "Write a functional spec in
> this
> way" and not really "Don't write functional specs."

No, I just saw him speak at SxSW. He was pretty clear about no
functional specs at all. And he said it directly to a guy from Yahoo
whose job it was to write functional specs!

Dan

18 Mar 2006 - 10:03pm
Robert Hoekman, Jr.
2005

>I think we
> would be hard pressed to find an example of a successful software
> product (sales and user satisfaction) that didn't begin life as a
> successful spec as well.

The guy that wrote that post is the founder of 37signals, who has put
out 5 quite successful applications in a row wihout writing a spec:
Basecamp, Backpack, Campfire, Ta-da list, and Writeboard.

That said, 37signals lives in a vacuum. They claim to build
applications for themselves, scratching their own itch. It's working
out very well for them, but there are plenty of applications to be
built that aren't for ourselves, and I'd rather do the work of an IxD
and make many applications better than build only a few.

-r-

18 Mar 2006 - 10:41pm
John Vaughan - ...
2004

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

19 Mar 2006 - 1:51am
Amnon Dekel
2005

I think all points made are relevant- but the main outcome is that there is
no clear and winning way- it depends on many parameters- what the
application is designed to do, the timeline for developing the app, the size
of the dev team, the organizational psychology, the dev team dynamics, the
interaction between the UX team and the Dev team etc. From my end the
following is becoming somewhat clear with time:

1. If the app is very broad and has multiple modules, a top level spec is a
must
2. A spec is usually not enough when designing the actual widget level
interactions- it "can" be done, but will mean a very long and drawn out
writing process followed by the developers looking in shock at the gigantic
doc in front of them. I find that in such cases it can be simpler, easier,
and faster (as well as easier to understand) to do a focused mockup which is
used by the dev team to understand the dynamics.

"Having said that" (I hate that statement), none of the above will cover
every pothole in the road- we will almost always miss something if it is a
new app. The misses might be because we as designer missed something, or
because the developers didn't understand something, or forgot to do
something, or didn't raise a flag in time when they did notice a problem.

The above problems can be limited somewhat by the use of "standard" widgets
and behaviors, but this brings up other problems- like designing your app on
top of 30 years of interaction design, some of it good, some of it not.

Amnon Dekel

On 3/18/06, Robert Hoekman, Jr. <mmbeta at gmail.com> wrote:
>
> >I think we
> > would be hard pressed to find an example of a successful software
> > product (sales and user satisfaction) that didn't begin life as a
> > successful spec as well.
>
> The guy that wrote that post is the founder of 37signals, who has put
> out 5 quite successful applications in a row wihout writing a spec:
> Basecamp, Backpack, Campfire, Ta-da list, and Writeboard.
>
> That said, 37signals lives in a vacuum. They claim to build
> applications for themselves, scratching their own itch. It's working
> out very well for them, but there are plenty of applications to be
> built that aren't for ourselves, and I'd rather do the work of an IxD
> and make many applications better than build only a few.
>
> -r-
>

--
:::........::::...::......:::....::::...::............:::::
Amnon Dekel
Cell: +972 54 813-8160
:::........::::...::......:::....::::...::............:::::

19 Mar 2006 - 2:53am
dszuc
2005

The term "functional specifications" may also be a little 'old'. As it
sounds like it's purely written with IT in mind (and certainly that's one of
its functions)

But ...

Perhaps the "design spec" (for lack of a better name - which is based on
screen shots, call outs and descriptions) also needs to account for: key
personas, key user tasks, project objectives, business objectives/vision,
key business questions etc. at the screen level.

That is ...

If the "design spec" can start with the with the high level objectives and
then at a detailed screen level further document how its meeting the
objectives i.e. business objectives, it provides a more holistic view and
also gives IT an idea of not just functions (what do we need to develop),
but what the IxD's are trying to achieve for business, users and IT. It then
serves as a bridging and consolidation document for all parties in the
organisation.

Rgds,

Daniel Szuc
Principal Usability Consultant
Apogee Usability Asia Ltd
www.apogeehk.com
'Usability in Asia'

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Amnon
Dekel
Sent: Sunday, March 19, 2006 3:52 PM
To: Robert Hoekman, Jr.
Cc: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Functional Specs

[Please voluntarily trim replies to include only relevant quoted material.]

I think all points made are relevant- but the main outcome is that there is
no clear and winning way- it depends on many parameters- what the
application is designed to do, the timeline for developing the app, the size
of the dev team, the organizational psychology, the dev team dynamics, the
interaction between the UX team and the Dev team etc. From my end the
following is becoming somewhat clear with time:

1. If the app is very broad and has multiple modules, a top level spec is a
must 2. A spec is usually not enough when designing the actual widget level
interactions- it "can" be done, but will mean a very long and drawn out
writing process followed by the developers looking in shock at the gigantic
doc in front of them. I find that in such cases it can be simpler, easier,
and faster (as well as easier to understand) to do a focused mockup which is
used by the dev team to understand the dynamics.

"Having said that" (I hate that statement), none of the above will cover
every pothole in the road- we will almost always miss something if it is a
new app. The misses might be because we as designer missed something, or
because the developers didn't understand something, or forgot to do
something, or didn't raise a flag in time when they did notice a problem.

The above problems can be limited somewhat by the use of "standard" widgets
and behaviors, but this brings up other problems- like designing your app on
top of 30 years of interaction design, some of it good, some of it not.

Amnon Dekel

On 3/18/06, Robert Hoekman, Jr. <mmbeta at gmail.com> wrote:
>
> >I think we
> > would be hard pressed to find an example of a successful software
> >product (sales and user satisfaction) that didn't begin life as a
> >successful spec as well.
>
> The guy that wrote that post is the founder of 37signals, who has put
> out 5 quite successful applications in a row wihout writing a spec:
> Basecamp, Backpack, Campfire, Ta-da list, and Writeboard.
>
> That said, 37signals lives in a vacuum. They claim to build
> applications for themselves, scratching their own itch. It's working
> out very well for them, but there are plenty of applications to be
> built that aren't for ourselves, and I'd rather do the work of an IxD
> and make many applications better than build only a few.
>
> -r-
>

--
:::........::::...::......:::....::::...::............:::::
Amnon Dekel
Cell: +972 54 813-8160
:::........::::...::......:::....::::...::............:::::
________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/ (Un)Subscription
Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

19 Mar 2006 - 9:31am
John Vaughan - ...
2004

Daniel Szuc sez:

> The term "functional specifications" may also be a little 'old'. As it
> sounds like it's purely written with IT in mind (and certainly that's one
> of
> its functions)
and
> ... the "design spec" ...
> serves as a bridging and consolidation document for all parties in the
> organisation.

Yup yup yup.

The traditional/olde "Functional Specification" speaks (with some rigor) to
the technical needs of the development audience.

The "Design Specification" (I've also heard it referred to as a Conceptual
Design doc, UI Spec, Interface Design, etc.) is the high-level overview that
provides context and common ground for everyone on the team. Stylistically,
it's the "illustrated novel" or "manga" version of The Vision: It offers
screenshots, lotsa visuals, the essential functional points, and a lean
Cliff-notes summary of the story. Just the sort of thing that
attention-deficient stakeholders might be willing to scan for a couple of
minutes. Combine it with a shallow-working HTML model, and you might
actually convince them.

Re "documentation", Here's a thought:
If your working environment doesn't clearly define those two document roles,
you might want to evangelize. The Design Spec document is strategically
influential. If you own it, you swing some heft in the process. Even those
who huff & puff about RAD (i.e. "We don't need no steenking documentation")
will probably still embrace this "documentation lite."

I very much appreciate Daniel's use of the term "holistic", too. Like
"educational", it's an important attribute of what we do that just doesn't
get enough airplay.

John Vaughan
The Communication Studio LLC
website: http://www.jcvtcs.com
Voice: (973) 265-4684

Disclaimer: I've been a Tech Writer and Documentation Manager. I believe
that documentation is underappreciated within the process, often poorly
executed (esp. in terms of "nobody wants to wade through it"), and
absolutely critical to our success. As the "designated communicators" in
the development environment, it's ultimately our responsibility to advocate
it.

20 Mar 2006 - 1:22am
Dwayne King
2005

On Mar 19, 2006, at 2:06 PM, Andrew Otwell wrote:
>
> Ok, if some rogue programmer subverts something basic about the
> product, or destroys some carefully crafted complex function, *and
> doesn't bother to tell anyone*, that's one thing. Usually, though,
> it's not much worse than something small that slips past you wish
> hadn't. Fix it in the next release and move on.

Ah, but I think you missed the point. The programmer isn't
subverting, nor destroying anything carefully crafted - When there's
not enough direction on what to do, it's not being subversive if it's
3 in the morning, client review is at 8 and guess who the only person
in the building is?

I think you may work in a much more flexible enironment than I (and I
suspect several others) do. The idea of "Just fix it in the next
release" is difficult if not impossible unless it IS a life or death
situation. In most environments I find myself in (especially with the
gain in popularity of Agile), it's me and a business analyst versus a
team of 12-20 programmers and if they think they're losing the battle
of the change, all it takes is the "schedule slip" argument and the
project champion says, "Let's leave it and visit that later." Alan
Cooper once wrote an essay about what was harder to do, change a
prototype or remove a large concrete slab (http://www.cooper.com/
articles/art_perils_of_prototyping.htm) his take is accurate and
worth the read - once a feature makes it into code, you've bought an
uphill battle.

Dwayne King
Pinpoint Logic, LLC
www.pinpointlogic.com

20 Mar 2006 - 10:10am
Robert Hoekman, Jr.
2005

That is a very interesting article - thanks for pointing it out (
http://www.cooper.com/articles/art_perils_of_prototyping.htm).

It surprises me a little bit that I disagree with so many things Cooper has
to say, but that's a different story.

-r-

On 3/20/06, Dwayne King <dwayne at pinpointlogic.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
>
> On Mar 19, 2006, at 2:06 PM, Andrew Otwell wrote:
> >
> > Ok, if some rogue programmer subverts something basic about the
> > product, or destroys some carefully crafted complex function, *and
> > doesn't bother to tell anyone*, that's one thing. Usually, though,
> > it's not much worse than something small that slips past you wish
> > hadn't. Fix it in the next release and move on.
>
>
> Ah, but I think you missed the point. The programmer isn't
> subverting, nor destroying anything carefully crafted - When there's
> not enough direction on what to do, it's not being subversive if it's
> 3 in the morning, client review is at 8 and guess who the only person
> in the building is?
>
> I think you may work in a much more flexible enironment than I (and I
> suspect several others) do. The idea of "Just fix it in the next
> release" is difficult if not impossible unless it IS a life or death
> situation. In most environments I find myself in (especially with the
> gain in popularity of Agile), it's me and a business analyst versus a
> team of 12-20 programmers and if they think they're losing the battle
> of the change, all it takes is the "schedule slip" argument and the
> project champion says, "Let's leave it and visit that later." Alan
> Cooper once wrote an essay about what was harder to do, change a
> prototype or remove a large concrete slab (http://www.cooper.com/
> articles/art_perils_of_prototyping.htm) his take is accurate and
> worth the read - once a feature makes it into code, you've bought an
> uphill battle.
>
>
> Dwayne King
> Pinpoint Logic, LLC
> www.pinpointlogic.com
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

20 Mar 2006 - 11:21am
russwilson
2005

I would add that the success of a particular process
is dependent on the team involved. Processes have to adapt
to the strengths and weaknesses of the teams. That's why
(in my opinion) there is no perfect process that applies to
all teams and all projects.

The goal is to find a process that works for your team. I would bet
that the 37signals process would not have been as successful with
a completely different team. It's as much about the team as the
process itself.

- Russ

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of Dan
Saffer
Sent: Saturday, March 18, 2006 8:51 PM
To: discuss at lists.interactiondesigners.com
Subject: Re: [IxDA Discuss] Functional Specs

[Please voluntarily trim replies to include only relevant quoted
material.]

On Mar 18, 2006, at 2:05 PM, Allen Smith wrote:

> It seems to me that he's really saying "Write a functional spec in
> this way" and not really "Don't write functional specs."

No, I just saw him speak at SxSW. He was pretty clear about no
functional specs at all. And he said it directly to a guy from Yahoo
whose job it was to write functional specs!

Dan

________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org

20 Mar 2006 - 3:42pm
Dwayne King
2005

On Mar 20, 2006, at 9:21 AM, Wilson, Russell wrote:
>
> The goal is to find a process that works for your team. I would bet
> that the 37signals process would not have been as successful with
> a completely different team. It's as much about the team as the
> process itself.
>

I would also put forth that it wouldn't work as well with a different
client. 37 Sig. works for themselves (well, on most projects they are
known for - I realize they are a service industry also). But they
primarily work in a small team building what they want. The key there
is they seem pretty unified in their vision. Most of my clients are
big and have several stake-holders all with a slightly different
vision. If we didn't define the end product via specs and the like,
none of them would ever get done. Even still, too many don't - I
attribute that to that when it's done, it's usually done poorly and
seldom revisited. I think that the 37 sig. issues is that specs tend
to be dead documents, so they're useful day 1, half as useful on day
2, half that on day 3 and so on down the line.

So, shifting gears - has anyone been involved with a good example of
living functional specs? f so, was it the personalities involved, the
tools, what worked?

Dwayne King
Pinpoint Logic, LLC
http://www.pinpointlogic.com

20 Mar 2006 - 3:52pm
Ari
2006

yes, previously, i was the product manager in charge of designing and
building a self-serve ad placement and creation system for streaming radio.

the functional specs i creared were quite detailed since ad creation was a
key component of the system.

due to circumstances beyond my control such as client changes, resource
allocation issues, etc. the specs, though definitive changed (some say
evolved) continously through the project's life-cycle until a few days
before it went Alpha.

i kep tabs on this by keeping a detailed, dated change log each time
something was changed or added.

the specs themselves were created and maintained in Word and relied on
wireframes that were embedded Visio objects, which allowed me to make
changes to different areas while editing a single document.

the only problem i had was that Word has a physical issue with files that
are 60megs in size as it would start to crash even on a system with plenty
of RAM. also, Mac users, could read the master doc but could not make
changes to it due to the lack of Visio on that platform.

the main difficulty were the programmers - they simply didn't want to read
specs that were 130+ pages. however, most eventually did and as a result,
85% of the system was identical to my specs and the system is now in Beta
and works quite well...

On 3/20/06, Dwayne King <dwayne at pinpointlogic.com> wrote:
>
> So, shifting gears - has anyone been involved with a good example of
> living functional specs? f so, was it the personalities involved, the
> tools, what worked?
>
> Dwayne King
> Pinpoint Logic, LLC
> http://www.pinpointlogic.com
>
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

--
------------------------------------------------
Ari Feldman
Executive Producer, Heavy Inc.
www.heavy.com

Syndicate content Get the feed