Tech Dev

Commandment IV: Keep Business Rules Simple Unto All The Rules of Your Life

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:

  1. Eliminate the 'Musts', 'Shalls', 'initiates' and other garbage words that add no value.
  2. Keep yourself to one clause per sentence and put it at the beginning or the end.
  3. Nine times out of 10, the word 'that' does no good and adds nothing.
  4. Keep your rules to three sentences or less- any more and you can split it into two or more rules.
  5. Keep your sentences to 15 words or less.
  6. The idea is to illustrate, not legislate or impose control.
  7. Make sure everyone can get to and read your rules.
  8. If you're the rules manager- make sure you review them on a regular basis and clean 'em up when necessary.
  9. Gather the business rule content from the people who know.

Powered by ScribeFire.

Leave a comment

Powered by WP Hashcash

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

WordPress

Comments about this site: info@pathf.com