[FoRK] why requirements docs suck

Luis Villa luis at tieguy.org
Wed Aug 20 20:10:36 PDT 2008

They never reflect actual requirements. They reflect what an end-user
told a manager who told a sales guy who told a marketing guy who told
a project manager the requirements are. And that is always a recipe
for failure.

As far as doing it right, I highly recommend
http://gettingreal.37signals.com/toc.php especially chapter 5. It
won't really work if you've already got the wrong customers (
http://gettingreal.37signals.com/ch04_Hire_the_Right_Customers.php )
but some of the ideas might stick.


On Wed, Aug 20, 2008 at 10:54 PM, kelley <kelley at inkworkswell.com> wrote:
> i'm working on a side project with a colleague, to help improve processes at
> work. basically, it's supposed to improve the development process --
> especially requirements docs.
> i thought i'd tap the fork braintrust and ask:
> in your experience, why have requirements documents sucked? if they haven't,
> then why do you think they were helpful/useful -- basically, not impediment
> to getting the work done. (and i don't want the stock answer about how they
> should be written in neutral, objective language, or that they can be
> verified, etc. )
> also, why it might actually be helpful, i'm pretty sure no one in our
> department is going to go the Agile development route, so Agile requirements
> probably won't fly.
> thanks.
> kelley
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork

More information about the FoRK mailing list