As in prior three posts in this series, a note beforehand: for the simplicity and readability purposes I omitted the “<” and “>” brackets at the element names.
Before we go any further, let’s recall the structure of the brPara (business rules paragraph) construct, which we need to markup a business rule decision point (BRDP) and all the information related to it, including the decisions made.
brPara consists of the following children elements:
The first three we addressed, with their various aspects, in the following articles:
- brDoc Schema: What is a Business Rules Paragraph (brPara)? (http://aerospace-defence.com/news/bitesize-business-rules/brdoc-schema-business-rules-paragraph-brpara/)
- brDoc Schema: Why is there a brDecision Occurence outside of the brPara? (http://aerospace-defence.com/news/bitesize-business-rules/brdoc-schema-brdecision-occurence-outside-brpara/)
- brDoc Schema: What does brRelatedTo stand for? (http://aerospace-defence.com/news/bitesize-business-rules/brdoc-schema-brrelatedto-stand/)
Let’s discuss business rule audit (brAudit) today.
According to Oxford dictionaries, the word audit is “an official inspection of an organization’s accounts, typically by an independent body.” (https://en.oxforddictionaries.com/definition/audit)
Following this definition, business rule audit is an official inspection of a business rule.
Business rules are often defined at formal and sometimes less formal meetings between partners in a project. At these meetings, the participants read each business rule decision point, analyze it, and make an attempt to make a decision.
If a decision is not possible right away then partners make notes on the current status, agree on actions, record the responsible for those actions, decide on a deadline, and move on to the next BRDP.
Let’s take a look at the structure of the element brAudit to see how it satisfies the process described above:
First of all, the element brAudit is optional. So you only record it if there is a need. You can all record several business rule audit entries for the same business rules paragraph (brPara). They can refer either to the same of various business rule decisions inside the brPara in focus. You use the element brDecisionRef (Business rule decision reference) for that purpose.
A quick reminder: there can be more than one decision per business rule decision point.
Apart from that, one decision might be evident right away and another not. For example, one partner in the project might be working for many years with S1000D and know what their CAGE code is. However, another company in the project is new and only started rolling S1000D out. That means that they have to acquire a CAGE code with the corresponding authorities. Thus, the decision on BRDP-S1-00002 “List of permitted CAGE codes and/or names to be used for the technical publications” would only be partially made and brAudit for the new partner will have to be captured.
The concept and structure of the elements brAction and brCurrentStatus — including the specific attributes, some of them being configurable attributes with predefined values — are very much self-explanatory even in their element names.
In brAction, you record the text of the action, possibly connecting it to a particular business rule decision. For example, the text “Double check whether the CAGE code ABC12 is correct.” could use such a reference.
In brCurrentStatus, you can again (but don’t have to) bind your recordings to a specific brDecision. Further, you can record the responsible partner company and the originator related to the topic handled by the given business rule decision point. And finally, you record the dates: brRequiredDate = the deadline for the decision to be made (which could be the date when the corresponding open action should be completed), and the date when all these metadata in the brAudit are captured = brStatusDate.
If you have ever filled in a Microsoft Excel spreadsheet with project business rules or filled in in another type of a table, you would recognize from the business rules paragraph (brPara) and its children elements that it reflects all the kind of data you usually record in those tables. This time in XML format.
I hope that this post and the three referred to above gave you an easy-to-understand introduction to the new brDoc Schema. I also hope that I could show you the value of this Schema, how it can simplify and accelerate the process of business rules definitions, as well as give you some behind-the-scenes insights of why the Schema is structured the way it is.
Looking to learn more about Business Rules in the world of S1000D?
Book your place on our S1000D Business Rules training course delivered by Victoria Ichizli-Bartels.
This course is for anyone who needs an understanding of the principles of S1000D prior to implementing the standard. It covers the technical and business aspects of Business Rules and how to implement it and its implications for technical publications. Find out more.
About Victoria Ichizli-Bartels
Victoria has been working with S1000D since 2004, first for German Defence, then for a major S1000D software vendor and today as part of her own business. In the S1000D community, Victoria serves as the Business Rules Working Group (BRWG) chair since 2005.
To book your place call +44 (0)20 8722 8400 or email firstname.lastname@example.org