individual-entry-BA-Blog

« Your strategy can be confidential, proprietary and driving every employee's actions too | Main | A banking story »

Dig yourself out of the requirements tarpit

I saw this piece by Carey Schwaber of Forrester today - The Root Of The Problem: Poor Requirements. My regular readers will know that I have strong opinions about requirements, so much so that I have a whole section on them. Anyway, here's the Forrester summary of the paper (my emphasis):

The quality of software requirements is a limiting factor on the success of software development projects. And it's the rare IT organization that couldn't improve its requirements practices. When it comes to getting requirements right, companies struggle on two primary fronts: requirements definition and requirements management. But the market places a disproportionate emphasis on tools for requirements management. The real opportunity for improvement lies in requirements definition and in how different development methodologies treat changing requirements.

Now in general I am of the opinion that fixing requirements problems is a false hope and that attempts to fix the problems of agility and fit-to-purpose that are epidemic in our systems will need to do more than just make another attempt to solve the problem of managing requirements. In particular I think that the key requirement for agility is the effective management of business rules - the policies and procedures that guide how the system should work - and that these are not the same as other kinds of requirements and that IT and business people have very different perspectives on this kind of thing. To the extent that this means considering business rules management as a different approach to define requirements this would align with Carey's premise (I don't know if she agrees with this or not). It is particularly essential to handle rules differently to cope with the reality that the time most systems spend changing dramatically exceeds the time spent being developed. Indeed I have heard it argued that successful systems will be forced to change more, not less, as successful systems will be used and the reality of the world means that systems being used will have to change as the world changes. Thus how to handle changing requirements is key as Carey notes. I believe that the "requirements" that are really business rules will change all the time. As such the system should be isolated from them as much as possible, by externalizing them in a business rules management system, and managing them should be handed over to the business users if at all possible. This will allow the business users to focus on "requirements" that are not about design but about the business and IT to focus on requirements about performance, integration and other elements of design and implementation.

Lastly for those interested in agile or iterative approaches I have written about how to use rules and agile methods together and had a virtual conversation with Scott Ambler on the same topic.

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83451629b69e200d8342fbe8b53ef

Listed below are links to weblogs that reference Dig yourself out of the requirements tarpit:

» An SOA Information Model from James Taylor's Decision Management
I was recently sent this paper on Information Model - SOA in a Business Perspective (the main site is www.TDAN.com) by some folks at IRM. This was an interesting model and I was pleased to see someone include business rules... [Read More]

Comments

The comments to this entry are closed.

Search Site


  • dmblog.fico.com

Subscribe

  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.