Scot Witt, Thursday, August 2, 2007 @ 1:01 pm
The Fourth Commandment was best summarized by Scott W. Ambler in Agile Modeling. He hit every nail quite nicely.
Business Rules are:
- Written and explicit.
- Written in plain language
- Are built on facts, and facts should build on concepts as represented by terms
- Guide and influence behavior in desired ways.
- Are accessible to authorized parties (e.g. collective ownershipust be single sourced (no links, no dependencies, no references, etc) .
- Are specified directly by those people who have relevant knowledge (e.g. active stakeholder participation<
- Have to be managed.
I've added Business Rules to separate sections of Use Cases, functional specifications, decomposition documents and functional requirements. Format depends on the project but writing remains the same in all the cases I've dealt with:
- Eliminate the 'Musts', 'Shalls', 'initiates' and other garbage words that add no value.
- Keep yourself to one clause per sentence and put it at the beginning or the end.
- Nine times out of 10, the word 'that' does no good and adds nothing.
- Keep your rules to three sentences or less- any more and you can split it into two or more rules.
- Keep your sentences to 15 words or less.
- The idea is to illustrate, not legislate or impose control.
- Make sure everyone can get to and read your rules.
- If you're the rules manager- make sure you review them on a regular basis and clean 'em up when necessary.
- Gather the business rule content from the people who know.
Powered by ScribeFire.
Related posts:
- The Ten Commandments for Technical Requirements: VI. Santa is Not The Only Clause
- JBoss Rules Wiki – A Business Rules Community of Practice
- News from Business Rules Forum 2004
- Catch Me Live at the 9th International Business Rules Forum, Nov. 7th, 2006
- Writing Technical Requirements: The Fifth Commandment