Tuesday, May 22, 2012

   Quick Links:   Articles     MA Blog     Community Blog     Templates     Books     BA Humor     Events     Jobs     Interview Questions         RSS Feeds

The Community Blog for Business Analysts

Community Highlights



Templates & Aides
Find templates and other useful aides for the business analyst.
ModernAnalyst.com LinkedIn Group
Requirements Template

Use Case Template

BPMN Cheat Sheet
Community Blog

How do you determine if you have a business rule?

On a recent client’s project, we were asked to help in the effort of creating a system to automate much of the current manual processes.  In order to capture the requirements this also meant that we were documenting the business rules that were currently being used.  When I started the project, I did not have a complete understanding of how a business rule was different than a requirement statement.  I found that I was constantly getting mired in my confusion between the two. 

From my research I did find one Wikipedia article to be particularly helpful, but I simplified that advice even further.  From my reading  and experiences, I created the following four guidelines to help me determine if a statement was a business rule that would need to be represented within the new system and should described within my functional requirement statements. 

 1:  A business rule is about the how to run the business and not about a system, or set of systems.  If you removed all the systems and system platforms, the rule would still important to the business operations.  Business rules are about people doing business activities, to achieve business goals not interacting with systems.  A very simple rule that is used every day is “No shoes, no shirt, no service” a person can read this rule, and know what actions they are to perform.  A functional requirement would be to support the “No shoes, no shirt, no service” rule within the system.

2: Does the rule provide enough information for a business person to make a decision, or a series of decisions?  If a business person uses the rule to make a decision, then it’s a business rule.  The rule exists in order to operate the business.  A business person could easily read the rule and understand how they are to conduct business.

3:  Business rules are owned by the business.  A business person must be able to change, or modify rules as they identify changes.  For example, a rule may be that “Only people between the ages of 25-35 may open a customer account”.  A system requirement could be written to support that age constraint.  The rule however, is owned by the business and could be changed at any time based on business objectives. 

4:  A business rule must place some type of constraint or requirement on the way that business is conducted.  For example, “Only customers with an approved line of credit of $1,000 or more may place orders within the corporate product catalog”.  This rule shows how customers are constrained and prevented from certain operation, or activities.  A system requirement might be necessary to support multiple rules which constrain customer activities.  The business rules define the constraints.

by LAnderson

Do you have feedback on how to determine a business rule?

posted @ Friday, July 23, 2010 10:13 AM by Seilevel

Previous Page | Next Page

RATING

COMMENTS

Concise and very useful. Particularly the part about take away the systems and the business rule is still there.

Rule #3 is a reminder that there are no business constants and hard-coding numbers is a recipe for rework. Of course, that's also called "job security."

I'll be using this. Thanks.

posted @ Tuesday, July 27, 2010 2:53 PM by Marc Thibault


This article explains what rules are and how they affect business operation. However, it is not clear if they are manually applied by business actors outside the system or from some mechanism within the system.

Some rules can be propagated into the system and activated to control the system responses according to the rules. Some rules or decisions may have to be applied by business managers. There should be methods to facilitate both.

I have felt a need to create an actor “Business Manager” to present the policies and rules to the system which contains an “internal rules repository & supplier”. Whenever a use case is activated, the “internal rules repository & supplier” supplies the rules, parameters, conditions, limits, applicable decisions etc to all the internal objects of the system through messages / return values etc. This may turn out to be complicated for large systems.

putchavn@yahoo.com

posted @ Monday, May 16, 2011 10:20 AM by Putcha


Only registered users may post comments.
  
Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



MODERN ANALYST BLOG - LATEST POSTS
BA ABCs: “C” is for Class Diagram BA ABCs: “C” is for Class Diagram
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article ... Read More...

Thoughts on the Agile Extension of the BABOK
Today was the last day people could provide feedback to the IIBA’s Agile Extension of the BABOK. The most recent draft of the document was published i... Read More...

10 Things I Wish Someone Had Told Me When I Was Starting Out As A BA
I am no longer a Webinar virgin. Thanks to the good folks at the IIBA, this week I had my first Webinar experience as an interviewee as part of the II... Read More...


ModernAnalyst.com LinkedIn Group ModernAnalyst.com on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Browse ALL Books in the Store

 

Privacy Statement  |  Terms Of Use
Copyright 2006-2011 by Modern Analyst Media LLC