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
- 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.
- 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. - 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.
- 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.
- 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
