A first table illustrates for each rule set its goal, in/out parameters, and the main object from the domain model used
in scope of the rule set. It may be completed by a deployment strategy (using staging platform, or with a specific
validation process...) and the errors / exceptions it may generates:
|
Rule set
name
|
Goal
|
Parameters
|
Domain Object
|
Errors / Exceptions
|
Deployment strategy
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
From the rule set table we can define the department owner of the rule set, the policy manager(s), the reviewer(s) and
finally the author(s).
|
Rule set
name
|
Department Owner
|
Policy Manager
|
Rule Reviewer
|
Rule Author
|
|
Customer Loyalty
|
Marketing
|
Bob Reynold
|
John Smith
|
Ralph
|
|
|
|
|
|
The following table details for each candidate rule set the access controls granted to each department:
-
A “CRUD” means access is granted for one of the following action:
-
-
C-create a rule element.
-
R-read only
-
U-Update an existing element
-
D-Delete an existing element.
-
A “×” means no access is granted.
|
Departments
|
|
Rule Set
|
Marketing
|
Risk
|
Sale
|
|
Customer loyalty
|
CRUD
|
x
|
R
|
|
Customer eligibility
|
x
|
CRUD
|
x
|
|
Pricing
|
R
|
x
|
CRUD
|
|
|
|
|
|
|
|
|
|
