I'm gonna throw in some dissent here. What this lays out is a "Big Design Up Front" approach to the project, which assumes that you can (a) know it all up front, (b) design it all up front, and (c) deliver it to a customer who hasn't changed their mind in the meantime. The problem with this is that the customer in this case may have a pretty good idea of what they want at the moment, but they're also liable to change their idea once they start seeing a working system fall together. Requirements are going to change. Allow for this in your approach.
I recommend borrowing some ideas from the eXtreme Programming and Agile Methodology camps. Build the system in discrete iterations (AKA "sprints"). At the beginning of each iterations, get your customer to prioritize a set of features that they would like to see appear in 30 days. Estimate each one, and draw a line through the list show what's "in scope" for the iteration. That's what you'll build. Any changes in requirements that show up while you're building go under the line on the list, to be revisited when you reprioritize before the next iteration.
This approach gets some functionality into customers' hands early, and gives them the chance to either clarify what they really want, or to change their minds without throwing away a huge amount of work. It also avoids generating a set of documents that have, at best, historical interest once the project is complete.
Your first iteration might be to install Bugzilla or RT, and do some minimal look-and-feel customizations. That'll give your boss something to play with, and it can engage real users. It also gets you a quick win, which is great for project momentum.
In reply to Re: (Ovid - catch 22) Re: Insubordination or Exploitation?
by dws
in thread Insubordination or Exploitation?
by Silicon Cactus
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |