3 Simple Guidelines to Rule Development, Design and Traceability
Join the DZone community and get the full member experience.Join For Free
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. RequirementsA 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?
These questions have been dealt with in previous articles in the tips and tricks.
2. DesignIn 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.|
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?
|Options in meta data for requirements traceability.|
3. TraceabilityOnce 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.
Published at DZone with permission of Eric D. Schabell, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.