Capturing rules requirements combine art and science. 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 strategy. Change can come from competitive pressures, business regulations, or executive direction and business analysts must adapt quickly.
Rules Requirements are Requirements
As a Product Manager at heart, I value a nicely written PRD (Product Requirement Document). Many articles provide the golden rules on requirements gathering. 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 a nutshell, a good requirement, like a good goal, 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.
Rules Requirements vs. Systems Requirements
Capturing rules requirements or “source rules” requires a lot of detail. While a PRD for a system could be long, each requirement is usually short. For example, think of everything that goes into the “print” function. What does the function do? How do you trigger it? What are its limitations? There’s a lot that you can write on the subject, but typically PRDs focus on a handful of user stories that capture desired functionality. However, business rules typically involve many variations, up to hundreds if not thousands. For example rates for insurance can be broken down by age, gender, state, and risk level. If you put all these variations in your PRD, you’re going to end up with a novel that’s difficult to follow.
Tip #1: Reference Spreadsheets or External Documents
Therefore, when possible, reference spreadsheets or other external documents. Rates, scores, and prices often change over time. By referencing the documents, you can ensure that you’re always working with the most up-to-date version. In addition, when using a decision management platform like SMARTS™, you can also accelerate your rules implementation by importing these documents. This webinar recording shows how you can convert Microsoft Excel spreadsheets into executable rules.
Tip #2: Organize Requirements into Appropriate Groups with DMN
With rules that can’t be referenced, organizing them can be challenging. Business Analysts tends to structure information as they go which can become a trap with business rules. For example, let’s say for a given product, age eligibility varies by state. On top of that, some the product is ineligible in some states. However, if an applicant is not eligible for this product, they could potentially be eligible for a different one. Now if an applicant is eligible for both products, which do you offer? This project is not just a simple eligibility rules exercise but a cross-selling and best offer exercise too.
Therefore, we recommend leveraging the Decision Model and Notation (DMN) standard to organize your decision into appropriate groups and relationships. SMARTS™ Pencil Decision Modeler enables you to create DMN diagrams which can then be automatically converted into business rules. You can learn more on decision modeling with Pencil in this recording.
Key Takeaways
- 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
Continue reading my Rules Authoring Best Practices series:
- Rules Writing Pitfalls
- Making Decisions or Not?
- Decision Design
- Release Management
- QA Testing
- Decisions in Production
- Business Testing
- Object Model First
- Data-Centric Approach to Rules Authoring
- Rules for Data Validation
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager