Crowell Solutions Blog

Creating a Standardized Means of Capturing S1000D Business Rules

  

  

 delicious  

  

We at Crowell have been knee-deep in S1000D Business Rules for the past couple of months. And that has resulted in our thinking of ways to improve the process of creating and managing business rules. In my previous blog, I mentioned how storing business rules in a spreadsheet application is a bad idea. In this post, I’d like to propose an additional idea for creating business rules: Standardization!

This should be a no-brainer for all of the people in the S1000D world, as we are all about standardization. Alas, we have failed to standardize the means of creating business rules. Programs, groups, and individuals are free to create business rules in any form and by any means they deem appropriate. The problem is that programs are going to want to view, “borrow” and reuse other groups’ business rules. The fact that there isn’t a standard model for creating business rule decisions means that sharing this content is a slight pain in the you-know-what.

Here's a practical example: we have a customer who is developing a set of business rules for a new program. In developing these rules they are referring to a governing set of rules developed for an entire branch of the military. However, we are using chapters as the foundation of business rule ids and they are using pseudo Data Module Codes. Secondly, these governing business rules have imperatives in the description column of the particular rule. That is, there are “shalls” and “shall nots” in both the description of the business rule and in the business rule decision. These two items, coupled with the fact that the guiding business rules are in a spreadsheet (my previous angst on this expressed above) and thus not easily reusable, makes the job of mapping the governing business rules to our customer’s business rules somewhat of a Sisyphean task.

I propose a simple solution: A standard means of capturing business rules.

I think this could be fairly easily accomplished, as most business rule documents have a similar structure, even if the content is in a spreadsheet. That structure is:

1. A business rule ID – Every business rule needs an id. I hate the concept of pseudo Data Module Codes, and will “rant” about that in my next blog post, but if I lose that small battle for the sake of the larger victory, I am fine with that. The bottom line is that every business rule needs an id.
2. Heading or Title – This is the informative title of the particular business rule, such as “Use of Graphics within Titles”.
3. Business Rule Description – This component of business rules lays out the problem at hand, such as “Projects must decide whether or not to allow graphics within the title element.” As noted previously, this descriptive content should not have any imperatives. There should be no directives here, only a description of the content.
4. Program Decision – This is the group’s decision with respect to a particular business rule. Continuing the example, a good business rule decision would be “Program X will not allow graphics to be located within titles”, or, “Authors shall not place graphic elements inside of title elements”.

These business rule components, and any others deemed necessary, can be captured in a very simple and easy to use XML syntax. It could look something like this:

I suppose someone could argue that we simply use the syntax located in the BREX for this, but the BREX isn’t designed for human exchange of business rules. Rather, it is designed to be machine processable. I suppose that’s what I am getting at: A standardized syntax for the human consumption of business rules.

--Rick