More on focusing on requirements

I have blogged a lot about the problem of requirements. I saw another article on this today, Unraveling the Mystery of Software Development Success. Now while I agree with much Joe Marasco has to say, I was a little disappointed that he continues to believe that one can lock down requirements and validate them and so avoid the problems.

As I have said elsewhere I am not convinced. Sometimes you just have to face the fact that the requirements are too complex (in a business sense) to ever be accurately described to IT, too voluminous to make it worthwhile or are so dynamic that they will automatically be out of date as soon as they are written. When you face these problems the solution is not better requirements management or validation of requirements but business user empowerment. Business rules, with their ability to let IT constrain the technical environment while allowing the business to actually turn the requirements they understand directly into executable rules may well work better.

There is a great graph here that shows that requirements failures continue to grow even while other kinds of requirements drop. Business rules management systems offer a way to solve this problem too.

Comments

[Brad Appleton]

I'm with you James! Although I can certainly see the value of a tool that can help give immediate feedback on the clarity or ambiguity or structure of what one has just written (be it code, or specs as in the case of RavenFlow's products). It still won't dodge the "requirements uncertainty principle" (cf. http://www.journalhome.com/codecraft/15901/ and http://weblogs.asp.net/ryanw/archive/2004/09/15/229991.aspx)

See the recent article "The Unchangeable Rules of Software Change" at http://www.cmcrossroads.com/article/60431