The development team need to define each rule’s meta properties to be used during
rule management and rule execution (filtering of rules or reporting on rule execution.
The common properties are:
-
Rule ID, author, owner: to trace the rule changes
-
Expiration date, Effective date: to filter the rule according to time
-
The status to manage the rule life cycle to avoid deploying rule in development
stages
-
Business motivation, Policy reference, requirement reference: to reference rule
back to the requirements
-
Product reference, states, geographies: to manage rule per type of deployment
or other dimension of application
The following tables lists some example of properties an analyst can design
to manage a rule:
|
Property name
|
Type
|
Possible Value
|
Description
|
Null able
|
Changeable
|
Extractable
|
Required
|
|
Rule ID
|
Int or string
|
|
Unique identifier for the
rules
|
No
|
No
|
Yes
|
Yes
|
|
BusinessMotivation
|
String
|
“”
|
Link the rule to the business
motivation
|
Yes
|
Yes
|
No
|
No
|
|
PolicyReference
|
String
|
“”
|
Link the rule to a business
policy
|
Yes
|
Yes
|
No
|
No
|
|
Status
|
String
|
New, Defined, Deployable, Deployed
|
Support the life cycle of the rule
|
No
|
Yes
|
Yes
|
Yes
|
|
Rule Owner
|
String
|
|
Department team – no named
person
|
Yes
|
Yes
|
No
|
Yes
|
|
Expiration Date
|
Date
|
|
Date when the rule will not be
extracted
|
Yes
|
Yes
|
No
|
No
|
|
Effective Date
|
Date
|
|
Date from when the rule will be
extracted
|
Yes
|
Yes
|
No
|
No
|
|