Post to the XP Discussion List

I just posted this to the ExtremeProgramming List; I thought it was worth sharing ...

>Fortunately I think this is changing rapidly, and there is a growing
>body of experience on how to apply UCDish methods agilly to help with
>the "Buiding the Right Thing" part.


Heh. I know what you mean. It seems to be that most requirements descriptions are either:

A) Definitional. You leave having memorized a bunch of words, and this decreases some communication friction, but you may not know how to apply them. For example, the students learn the difference between implicit and explicit requirements, but do they really know how to help pull ides out of some one's head and get them on paper? Probably not.

B) Process-Focused. Do X, Y, and Z - "First interview the customer, then write the requirements, then have a review step" doesn't tell anyone how to do those things *WELL*. In my experience, a lot of the process literature focuses on change control, like the planning game, and not the requirements "gathering" part.

C) Template-Driven. "Just fill out this template, and you'll be fine." This is all kinds of bad for all kinds of reasons. Joel Spolsky does a pretty good job of describing this in this article: http://www.joelonsoftware.com/articles/fog0000000033.html (Scroll to the bottom)

In my honest opinion, there is a real lack of real good requirements advice in the software literature. Jerry Weinberg has a good book on requirements, and he used to even do workshops, but he is now semi-retired and focused on writing, not software requirements.

So, me? I am doing something about it.

I will be presenting a workshop on how to figure out what needs to be built and communicate it in Indianapolis next month:

http://www.xndev.com/downloads/Requirements%20Workshop%20Flyer.pdf

If you are interested, I am now booking for 2008 as well ...

Regards,


Matthew Heusser