Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘business rules vs requirements’

One-Size Traceability Does Not Fit All!

traceabilityCompliance in a broad sense means satisfying obligations and delivering on promises. Even high-quality customer service involves compliance of this kind – your products and services are always what you say they are, and your delivery of them meets customers’ expectations.

Some critical observations:

 

  1. Laws, regulations, contracts, deals, agreements, guarantees, warranties, etc. all represent obligations, the very essence of business rules.
  2. These obligations are constantly amended, extended and (sometimes) terminated, so you need direct traceability for them.
  3. The typical IT view of traceability is far removed from what the business actually needs to manage obligations.

Many professionals are so immersed in system development they cannot easily separate the notion of obligations (business rules) and requirements – e.g., specifications for modifying some system feature or procedure. Say ‘traceability’ and they immediately think traceability for requirements.

How system development needs to trace requirements into system designs is a very different proposition than the traceability needed for business obligations. The two kinds of traceability can and should be separated.

  • Requirements are about building systems, whereas business rules are about running the business.
  • Requirements generally fade into the background when a system is delivered, whereas deployment sparks a whole new phase of life for business rules.

~~~~~~~~~~~

Read more about the Big-5 business challenges: http://www.brcommunity.com/articles.php?id=b904

Continue Reading

Business Rules vs. Choices Made in Designing Systems … Not the Same Thing!

A colleague and I were recently discussing business rules. In the course of conversation he used this example: A customer may have only one address. Hold on! That’s not a business rule. Rather, it’s a design decision (probably a poor one) some IT person made in creating a system model. The business wouldn’t (and couldn’t!) make a real-world business rule about customers having only one address. But a design decision might be made to record only one (in a system). Eventually we agreed the desired business rule probably was: A customer may have only one preferred address.  ~~~~~~~~~~~~~~~~~~~~~~~~~~  This post excerpted from Building Business Solutions: Business Analysis with Business Rules (2011). See:  http://www.brsolutions.com/b_building_business_solutions.php

Continue Reading 1 Comment