A large consulting company recently conducted an assessment of the IT development approach followed by one of our clients that uses our approach for business analysis with business rules. The consulting company judged the approach highly effective because the approach is ‘componentized’ (their description). 

The consulting company meant that business rules are viewed as a component; business processes are viewed as a component; business vocabulary is viewed as a component; etc. ‘Componentized’ may or may not be the right description, but the consulting company hit upon an important point.

Most IT methodologies for requirements development today make no attempt to examine the fundamental questions what, how, where, who, when, and why individually and selectively.  That omission is odd to say the least.  Those six questions are ones all of us ask and answer every day in real life.  The six question words are very basic to our language.

Instead, most methodologies today are centric.  They are process-centric or data-centric or user-story-centric or sometimes even rule-centric or decision-centric.  A centric approach requires force-fitting some or all elements of a solution into a single mold that distorts and submerges other elements.  Worse, a centric approach does little to avoid elements being neglected or omitted altogether.

Business problems are inherently complex and multi-faceted, as are their solutions. So we make every effort to ensure our approach to business analysis is well-factored and balanced – that is, non-centric – right from the start.

A non-centric approach doesn’t make developing winning business solutions harder, just the opposite. By addressing business complexity head on – as naturally factored in the real world – top-quality business solutions are far easier to attain.  Experience proves it time and time again.

~~~~~~~~~~~~

Excerpted from: Building Business Solutions: Business Analysis with Business Rules, 2nd edition, by Ronald G. Ross & Gladys S.W. Lam, 2015

Get the book: http://www.brsolutions.com/b_building_business_solutions.php

Get the training: Instructor-led, online, interactive training: April 4-6, 2017 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.attainingedge.com/online-training-business-analysis-with-business-rules.php

©Business Rule Solutions, LLC 2016. www.BRSolutions.com

Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php Get it on Amazon: http://goo.gl/HXxN1f What It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide. Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3. ~~~~~~~~~~~~~~~~~ www.BRSolutions.com

---

We’re teaching our online training course next week: Business Analysis with Business Rules: From Strategy to Requirements. http://goo.gl/Vnko3 Hope to see you there! Naturally, we’ll be talking a lot about business requirements. Are business requirements the same as functional requirements? No! Functional Requirement vs. Business Requirement Wikipedia describes a functional requirement as … “a requirement that defines a function of a software system … what a system is supposed to accomplish” [emphasis added] We define a business requirement as … “something called for or demanded by a business model that a system model must support” That’s a big difference! Appreciating the importance of the difference, however, requires clear understanding of the distinction between business model and system model. Business Model  We define a business model as follows[1] … a blueprint for a business capability based directly on real-world things and ideas strictly named and represented using words natural to business people We stress that business people talk about real-world things! And why should we ask them to do any differently?! A business model enables business people and Business Analysts to engage in discussion about what needs to be created, managed, operated, changed, and discontinued in the business in business terms.  Developing a business solution using a to-be business model does not necessarily imply software development, but if software development does ensue (as it usually does) the business model provides a solid grounding. Examples of business models include strategies for business solutions (Policy Charters), business process models, structured business vocabulary (concept models), business milestone models, and Q-Charts (for decision analysis). Any business model is always subject both individually and collectively to the business rules specified for it(!) We believe business rules are key to creating effective business requirements. System Model We define a system model as follows … a model that provides a design for an automatable system that is computationally competent For many years John Zachman, creator of the Zachman Architecture Framework, has explained that a business model is always about real-world things.  These real-world things are as the business leads see or define them.  That idea is actually his, not ours. Zachman describes a system model, in contrast to a business model, as comprising “… surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world.”  Surrogates include …

• data entities or business objects in place of real-world things.
• GUIs and use cases in place of face-to-face, real-world communication.
• network nodes in place of real-world locations.
• system events rather than operational business events.
• etc.

If you are developing ‘requirements’ using use cases, you are actually designing a system (creating a system model), not defining business requirements(!). We believe a focus on use cases with no prior business model puts your project at grave risk.

---

In running facilitated sessions, we like to create each kind of business model on a different wall.  We find that the physical act of walking or shifting focus from one wall to another helps participants rapidly grasp and remember what each wall represents.  It also helps business leads and Business Analysts identify disconnects and gaps in the business solution more readily. We call this walking the walls. Our definition:  managing complexity in developing a business model by figuratively, and as much as possible literally, addressing each primitive as a separate concern (i.e., on a different wall)  In physically walking the walks, we usually put business process model(s) on the left wall and the structured business vocabulary (concept model) on the right wall.  On the front wall we put reminders about the strategy for the business solution (Policy Charter) and on the back wall we capture business rules.   Aside: Business rules go on the back wall to help resist the temptation of wordsmithing, which is better done offline.  In an ideal world, there would be one surface for each of the six primitives of the Zachman Architecture Framework.  (Alas the ceiling and floor are hard to use.)  Business rules, serving as integration relationships, would occupy the 3D space between the six surfaces (even harder to use!).  Our approach approximates the notions well enough in practice.

Let me share something we’ve learned from our work on business rules. The world’s leading cause of ambiguity in expressing business rules is missing verbs. Stay with me now. Consider this sample business rule: An order must not be shipped if the outstanding balance exceeds credit authorization. As a first-cut statement, that’s perhaps not bad. The more you read it, however, the more ambiguity you’ll find. Clearly, important ideas are hidden or missing. For example: The outstanding balance of what? …order? …customer? …account? …shipment? The credit authorization of what? …order? …customer? …account? …shipment? The hidden or missing ideas are all verb-related. To eliminate the ambiguity, the relevant verb concepts (called fact types in fact modeling) – must be discerned; then the original business rule restated. Suppose the relevant verb concepts can be worded: customer places order customer has credit authorization customer holds account account has outstanding balance Using RuleSpeak (www.RuleSpeak.com – free) the business rule can now be restated: An order must not be shipped if the outstanding balance of the account held by the customer that placed the order exceeds the credit authorization of the customer. Although the resulting statement is a bit wordier, it is far less likely to be misunderstood, misapplied, or mis-implemented. It is now enterprise-robust. The key insight: Wordings for relevant verb concepts should always appear explicitly in expression of business rules. For that matter, wordings should appear explicitly in any form of business communication you want to be understood correctly – including IT requirements. Note: You probably noticed use of the preposition of in the revised business rule. Stand-in prepositions for verb concepts are considered lazyman’s verbs. (Literally, you can’t make complete sentences with only prepositions!) Yes, you can use a preposition to stand in for a full wording, but do so with caution. As a rule of thumb, prepositions are safe only for two cases: (1) properties – e.g., credit authorization and outstanding balance as above. (2) role names – e.g., owner as in the earlier example, owner of a vehicle. ~~~~~~~~~~~~~~  This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php    

This is an excerpt from our new book: Building Business Solutions: Business Analysis with Business Rules coming out in October. Watch for it! “Requirements are rules.” Perhaps you’ve heard the argument. Maybe you’ve even made it yourself. Are they? No! Basic reasons why requirements are not rules:  Business people don’t naturally think of a ‘requirement’ as a ‘rule’. To ensure the best possible communication with business people, use of ‘rule’ should remain consistent with the real-world understanding of ‘rule’. Say ‘rule’ to business people and they will naturally think “guide for conduct or action” or “criteria for making judgments or business decisions.” If a business person says ‘rule’ he/she almost certainly means a rule for the business (e.g., no shirt, no service), not ‘requirement for a software system’. Many ‘requirements’ never become rules. The “no shirt, no service” rule doesn’t happen to be automatable (at least easily). Many other rules of the business are – e.g., no credit card, no sale. When interpreted into an implementation form, the business rules ideally should still be recognizable as a form of rule. The same cannot be said, however, for other aspects of a business model, say processes. In designing a business process for implementation, why would you ever say, “Now it represents rules.”?! Rules are rules, processes are processes, locations are locations, people are people. Each can be cast into some design-level counterpart (e.g., GUIs can substitute for face-to-face communication between people.) Nonetheless, each retains some sense or reflection of what it was originally (or should anyway). Looking at operational business design any other way inevitably leads to a break-down in communication and needless complexity.  Avoid confusing business people or IT professionals – or yourself – by calling requirements ‘rules’. Requirements are not rules! But Are Business Rules ‘Requirements’?? Clearly, requirements are not rules. What about the reverse question? Can it be helpful to think of business rules as requirements? To answer it’s essential to keep in mind what business rules are about. In plain English, business rules are about guiding and shaping day-to-day operations of the business. Business people would need business rules to operate the business even if there were no systems. The business rules just are what they are. And if well-specified, they essentially speak for themselves. All the following, though, are certainly true about business rules:

• They should arise from, or at least be approved by, business people.  
• They should be considered very carefully in designing a system.  
• They should be automated whenever possible.

All said and done, whether business rules are a form of requirement is really a judgment call. The best answer is whichever is likely to prove most productive for your work.