Requirements are not dead.
Hearing many of my fellow agilists talk, you’d think requirements management, and even requirements themselves, have shuffled off their mortal coil. Unless, of course, they are provided on a 3×5 card and ranked in a one-dimensional, user prioritized stack. Let me apologize for a moment for using narrowly defining the “agile zealot”, but you know them. To them, all things good are agile, and all things bad are non-agile. There are few, if any grey areas, and large, complex software development shops who still have business analysts creating use cases and requirements documents just are too archaic (or stupid) to realize their error. This confidence in the simplicity of requirements has always left me with a feeling of dread — in my experience, requirements can be complicated beasts. This doesn’t mean that there isn’t a LOT to learn from the agile camp. In fact, I believe most companies err on the side of too much complexity in their requirements, and the requirement management process.
Thus I was pleased to see that Scott Ambler, one of the agile luminaries, wrote on article highlighting the difficulties of requirement specification on agile projects. Of specific interest was his absolutely wonderful quote on the first page:
Although “agile in the small” methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater ater putting too much faith in the overly simplistic strategies of those processes.
Jeff Levinson, our ALM Practice Lead has written about this problem and others in several blog posts, most noticably in his post on the problems of Requirements Engineering tools. It’s also a very frequent discussion over the water cooler here at Northwest Cadence. Expect to see more on requirements management discussions coming here over the next few months.