Business rules provide the flexibility and agility that systems need. By definition, they enable business analysts to adjust the system’s decision logic to ever-evolving business direction. Due to competitive pressure, business regulations, or executive direction, business rules keep adapting. The art of capturing rules requirements dictates the success of the rules implementation to follow.
Rules Requirements are Requirements
As a Product Manager at heart, I value a nicely written PRD (Product Requirement Document). Many articles provide guidance on requirements gathering, and the golden rules to adopt for success. In particular, I like Duncan Haughey’s concise take on the subject (https://www.projectsmart.co.uk/requirements-management/requirements-gathering-101.php). Above all, I cannot stress enough the value of focusing on the problem rather than the solution. Engaging stake-holders or subject matter expert from the start is paramount. Kudos to him for putting it into writing.
In addition, this simple golden rule will keep you safe in such efforts: “a good requirement is SMART”
- Specific
- Measurable
- Agreed-upon
- Realistic
- Time-based
Overall, requirements gathering for rules and for systems do not differ that much. Yet, subtleties make those two exercises different enough. Let me emphasize some key aspects.
Best Practices in Source Rules Gathering
Rules requirements are also called “source rules” in our industry.
Typically, source rules contain lots of details
A PRD for a system could be long, yet each requirement is typically relatively small. For example, think about all aspects of a function such as “print”. You need to describe what it does, how it is engaged, what limitations there are… While you could write a full page on the subject, it is likely that you will not write much more than that. Keep in mind that requirements are meant to be specific. One requirement will not cover the full “underwriting” component of a policy admin system. With that in mind, we should see decently short descriptions of all those aspects for one functionality.
In contrast, business rules tend to contain lost of details. While not all decision steps in your reasoning contain that level of variations, we often see steps that include hundreds if not thousands of variations. For instance, rates could be broken down by age, gender, state, risk level. At some point in time, source rules will overflow your PRD. Reference spreadsheets or external documents at this point.
Most noteworthy, these tables are bound to evolve over time. By keeping them separate, you make it easier for the experts to provide iterations as needed. You might also accelerate your rules implementation by importing them as is. This webinar recording shows how spreadsheets can import natively.
Structure is your Friend
Because decisioning is complex, source rules are not always straight-forward to organize as you capture them. Business Analysts excel at structuring information as they go. Yet, source rules might challenge their abilities if they are not careful. Due to the mere volume of source rules, any human being could get trapped.
Most likely, this is the one pitfall I encounter the most often. Starting with one source rule, one thing leading to another, the source rule turns into this uber-requirement. For example, you might start documenting an eligibility rule. The age limit varies per state. Then again, some states are not eligible at all. But, if the applicant is not eligible for this product, we could suggest a cross-sale offer. If eligible for multiple cross-sale offers, how do you decide which offer is the best?
One simple age requirement turned into a mesh of eligibility and cross-sale logic. It is important for the business analyst to structure these requirements into the proper buckets as they are encountered.
Thanks to its underlying methodology, the DMN standard (Decision Model and Notation) guides you through this decomposition. You can learn more on how create decision models using Pencil in this recording.
Not using DMN tooling, business analysts must remain aware of the danger. In the end, it only takes attention to avoid spaghetti source rules.
Key Take-Away
- Consider adopting a different approach to requirements gathering for source rules
- Keep the sources rules that are maintained in a spreadsheet separate
- Structure, structure, structure… Organize your sources rules as you go
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
