individual-entry-BA-Blog

« What Does James Have in Common with the Catholic Church | Main | What you need to know about Decision Services »

1 MORE thing CIOs should know about requirements

I saw this article on CIO magazine today - Five Things CIOs Should Know About Software Requirements. It seems to me that there is one more thing (at least) that they need to know about requirements:

Business rules are NOT requirements

After all, business rules are about how your business takes decisions, not about how a system works. Trying to capture business rules the way you capture any other kind of requirement is not going to work - simply trying to write better requirements will not get it done, I think system requirements, use cases and business rules are great complements to each other (as noted in Use Cases: Requirements in context) and, fortunately, you can find rules the same way as you find requirements

Here are the five things CIO magazine listed, with comments

  1. The Inconvenient Checkbox: Understand the Role of Requirements
    As this section says "Many development projects are handicapped from the start. The requirements are vague and subject to interpretation, require intimate knowledge of the business to interpret correctly, and aren't prioritized" and that's certainly true. It is also true, however, that part of the problem is mixing of business rules with requirements.
  2. Don't Throw It Over The Wall: The Right People Should Define the Requirements
    Indeed business users should maintain rules but there are some secrets about getting them to do so. IT departments and business people have fundamentally different perspectives and separating out business rules can really help resolve this.
  3. Superficially Complete: Define Requirements With "Enough" Detail
    While I agree with the comment "They should have information that states more of what the requirement is to do (the What) and the way it is to do it (the How)", I think this means making sure testers can see the rules as well as the requirements as otherwise you run the risk that the how of the business will get mixed in with the how of the system.
  4. Working from Ignorance: Recognize that Requirements Change
    Much of the change in "requirements" really come from changing business rules and separating them out can dramatically reduce the change in the requirements themselves. However, most systems spend most of their life changing not being specified, so you do need to build systems where the rules can keep changing over time.
  5. Carpet Yanking: Pay Attention to the People on the Front Line
    One example of this is the necessity of making sure that the policies and regulations you think you are implementing are really being used.

One last thing, rules can and should be used with agile methods. If you are interested in more on rules, Barb von Halle and others (including me) published a book recently on the Business Rules Revolution.

Technorati Tags: , , , ,

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/6a00d83451629b69e200d83540ac1553ef

Listed below are links to weblogs that reference 1 MORE thing CIOs should know about requirements:

» Business rules, requirements and use cases from James Taylor's Decision Management
Scott Sehlhorst had a nice post today on Business Rules Hidden in Use Casesand, as I have not really talked much about rules and requirements on this blog I thought I would point my ebizQ readers to the post and,... [Read More]

Comments

Post a comment

Comments are moderated, and will not appear on this weblog until the author has approved them.

If you have a TypeKey or TypePad account, please Sign In.

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.