|
| Recent
Articles |
CIOs Don't Feel The Love
When it comes to expectations, CIO's and IT Managers are not feeling the "love" from their managers. "Nearly six-in-ten CEOs say they are satisfied or very atisfied with the performance of their companies' IT, yet most...
When The Paranoia Meter Pops
Bad security days happen, when the paranoia meter pegs and there is no substantiating facts behind it, some days it's bad to be a paid paranoiac. The day might start...
Thoughts On ITIL
Interesting, skeptical take on ITIL, by a person (Noel Bruton) with some apparent long term presence in the industry. He claims that there are four schools of thought with respect to configuration management: Those...
Information Security - A People Problem
Interesting article out on outlaw about how information security is a people problem, which is something that we all probably really do know, even if we won't really...
What Are Our Co-workers Doing On The Net?
8e6 has a report here that should provide all of us in security an amusing insight into what our co-workers are doing on the internet. Apparently, they ran a contest to see who had the most egregious uses of the...
Vista To Be More Generous Than Santa
Once Microsoft Vista gets into the marketplace, it will benefit the economy and drive job creation in the tech industry; no word on whether it will whiten teeth...
Rules For Great IT Project Success
Project delivery makes IT organizations credible. When IT "gets it right" at the project level, its ability to impact the financial results of a company increases and its leadership in providing strategic direction improves.
|
|
|
03.19.07
Another Thing CIOs Should Know About Requirements
 By James Taylor
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.
Comments
About
the Author:
VP of Product Marketing with a passion for the technologies of decision automation. 15 years designing, developing, releasing and marketing advanced enterprise software platforms and development tools. Across the board experience in software development, engineering and product management and product marketing.
http://www.edmblog.com
|
|
