Quantcast

Another Thing CIOs Should Know About Requirements

Get the WebProNews Newsletter:


[ Business]

I saw this article on CIO magazine  – 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.

Comments

Technorati

Another Thing CIOs Should Know About Requirements
Comments Off
Top Rated White Papers and Resources

Comments are closed.

  • Join for Access to Our Exclusive Web Tools
  • Sidebar Top
  • Sidebar Middle
  • Sign Up For The Free Newsletter
  • Sidebar Bottom