For the rules, your Business Analysts (BAs) should firstly produce a Fact Model (FM). This is the data that will be inserted and retrieved from the rules engine.
(Typically this is based on the use-case and user story documents for the various business activities).
This is best done using the same tools used to create your Logical Data Model (LDM). Indeed the FM is usually a subset of the LDM.
Keeping the FM as broad and unified as possible will generally give a quicker development and more flexible rules. Splitting the FM by business area or activity, for example makes extra work, and limits the scope of the rules.
For rules that are focused on providing screen validation, you may alternatively use the wireframes to create the FM: this is because the screens may contain data or structures required by the rules that are not present in the LDM.
(wireframe example: rules engine must manage inter-relation between several checkboxes and jquery sliders on the screen wireframe, requiring enabling/disabling controls, control specific error messages and limits, whereas the LDM only holds one number for each slider, and one boolean for each checkbox).
For most rules engines the FM is directly translated into the java classes that will be used to insert/retrieve objects from the rules engine.
Usually several extra classes are required, in addition to the Fact Model. Typically these are (see specific topics in this site for more detail):
- Metadata: Descriptions and codes that are best maintained outside the rules engine, but are not part of the LDM, e.g. the current business year, today’s date.
– - Error Messages: The outgoing text of the error messages.
– - Artifacts: Technical objects used for processing. Example: tables used for accumulations.
.