Home » Software Development » 3 Simple Guidelines to Rule Development, Design and Traceability

About Eric Schabell

Avatar photo
Eric is Chronosphere's Director Technical Marketing & Evangelism. He's renowned in the development community as a speaker, lecturer, author and baseball expert. His current role allows him to coach the next generation of technical marketers & evangelists helping the world to understand the challenges with cloud native observability. He brings a unique perspective to the stage with a professional life dedicated to sharing his deep expertise of open source technologies and organizations. Follow on https://www.schabell.org.

3 Simple Guidelines to Rule Development, Design and Traceability

tips-and-tricks

(Article guest authored together with John Hurlocker, Senior Middleware Consultant at Red Hat in North America)

In this tips and tricks article we present some background and guidelines for the design cycle encountered when one is working with rules projects.

This article is not the only standard or all encompassing source of how each and every rules and events project will evolve over time.

What it is going to do is provide you with the basics as we have encountered them in many projects in real life organizations. They are meant to give you some confidence as you embark on your very own rules and events adventure within the world of JBoss BRMS.

We will discuss some of the requirements phase around rules development, touch on a few of the design choices that will be encountered and elaborate on the options available for including requirements traceability within the projects.

1. Requirements

A rule author will analyze project requirements to determine the number of rules that will need to be created and also works with the requirements team so they can provide answers to any questions that might arise.

Analyzing rules requirements is the phase where a look at the following questions takes place:

  • Are there any WHEN or THEN conditions that are unclear when reviewing the requirements?
  • Are some of these rules data validations?
  • Can multiple requirements be combined into one rule?

By spending some pre-development time examining and validating the project requirements you will be able to narrow the scope of the work to be done in your development cycles.

These questions have been dealt with in previous articles in the tips and tricks.

2. Design

In the design phases an enterprise rule administrator will need to work with the organization and ask some of the following questions:

  •  Will the organization need to host a central rules repository or would that not be beneficial?
  •  Who owns these rules and is responsible for updating and releasing new versions?
  • Are there common rules that can be reused between groups?
Centralized JBoss BRMS repository.

Centralized JBoss BRMS repository.

A central repository is one JBoss BRMS server available for the entire organization to author, store, and build rules.

It promotes rule reuse, is easier to manage and maintain instead of deploying multiple repositories in an organization.

If a set of rules is going to be shared with other groups then one of the groups will need to take ownership and will be responsible for updating and releasing new versions.

The rule author will need to work with the application team(s) to determine what rule format or formats will be used and which tool will be used to author rules. Some of the questions to be dealt with are:

  •  Should rules be developed in the BRMS Dashboard or through JBoss Developer Studio (JBDS)?
  • What are your rule authors more comfortable with?
  • Who will maintain the rules in the future?
    • Java developers, business analysts
  • Do the requirements work better in one format vs. another?
    •  e.g.  web based data table, business guided rule, DSL
  • What type of testing is required?
  •  JUnit and BRMS test scenarios?

These topics have been laid out in previous articles, please refer to them for a deeper discussion.

3. Traceability

Options in meta data for requirements traceability.

Options in meta data for requirements traceability.

 
Once the rules and events are being implemented it is vital to have some sort of requirements traceability attached to the rules that links them to the originating requirements.

With JBoss BRMS rule authors can set meta data on the rules for traceability to requirement(s), for instance:

  • Associated requirements can be set on rules in the description section.
  • Associated requirements can also be set as an external link on the rule meta data.
  •  Reports can be generated by pulling meta data information from the repository.

In a future article we will dig deeper into how you can use meta data fields within your rules implementation to trace your requirements and extract this information to generate documentation around these requirements.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you our best selling eBooks for FREE!

 

1. JPA Mini Book

2. JVM Troubleshooting Guide

3. JUnit Tutorial for Unit Testing

4. Java Annotations Tutorial

5. Java Interview Questions

6. Spring Interview Questions

7. Android UI Design

 

and many more ....

 

Receive Java & Developer job alerts in your Area

I have read and agree to the terms & conditions

 

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments