Hey Taco
I agree with you about 90%. I don't think I was really clear about
Wire-frames/Function specs.
What I mean is that these documents, including the Business Requirements
document, should not be considered as a 1 -> 2 -> 3 process. You can't
pretend to get the whole business requirements thing down pat before you
start your wireframes, as there are bound to be things you only learn about
the business requirements once you've taken your wireframes to the client
and talked about them. After working with some clients for a number of years
I'm still amazed at how little I know about their business - I don't think
this is because we failed to get it right at the outset, its because we are
constantly learning more. Clients often don't tell you things that seem
really obvious to them.
A quote from that Joel article:
'Specs Need To Stay Alive. Some programming teams adopt a "waterfall"
mentality: we will design the program all at once, write a spec, print it,
and throw it over the wall at the programmers and go home. All I have to say
is: "Ha ha ha ha ha ha ha ha!"
This approach is why specs have such a bad reputation. A lot of people have
said to me, "specs are useless, because nobody follows them, they're always
out of date, and they never reflect the product."'
Closing off the business requirements analysis & design mind-set too early
is a big mistake.
I think early drafts of each of the three documents, even if they are just
skeletons or outlines should be created and then revised together as more
details come to light, even while the project is in development!
Sure you have to get signatures on them at some point, but they can still
grow afterwards.
Another thing is I think wireframes should be *part* of a functional spec.
Another little quote from Joel:
"1. A functional specification describes how a product will work entirely
from the user's perspective. It doesn't care how the thing is implemented.
It talks about features. It specifies screens, menus, dialogs, and so on.
2. A technical specification describes the internal implementation of the
program. It talks about data structures, relational database models, choice
of programming languages and tools, algorithms, etc."
Note - "from a users perspective" there are a bunch of ways to communicate
what the user's perspective is and I think wireframes are one important part
of this. User case scenarios are another really good trick as long as they
aren't boring.
Anyway I'm really just repeating what's in that article, but its a really
good one (like most of Joel's stuff). Here's the link again:
http://www.joelonsoftware.com/articles/fog0000000036.html
I'm not claiming I've got the discipline to always follow this to the
letter, but.....
Cheers
Mark
______________
Mark Stanton
Web Production
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
http://www.gruden.com
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
