 |
| Prototyping rules is an important step of the rule analysis, as it is when we are really coding that issues arrived. Paper work is fine, but working rules is far better. |
|
Relationships
| Roles | Main:
| Additional:
| Assisting:
|
| Inputs | Mandatory:
| Optional:
| External:
|
| Outputs |
|
Main Description
|
The goal of this activity is to evaluate the complexity of the object model, and
what are the rule it can support. It helps also to consider some utility classes or methods to add the object model to
simplify the rule writing. At the end it also help to build some different type of business rules to get feedback from
the Subject Matter Expert on the rule, its usability, and maintainability.
|
Steps
|
Create a simple rule flow
Prepare a simple unit test code
The unit test should prepare the input parameter(s) and other related data to trigger the rule execution under
development. Rule writer should work with the business user to define test data and scenario. Using the IDE to author
and test rules the rule testing framework can be created, executed, tuned in the same environment to quickly write and
test rules. As Agile method we recommend to use a Test Driven Development approach.
|
Code the rule under test
Validate the execution
Report any issue, questions, concerns for the next discovery meeting
|
Properties
| Multiple Occurrences |  |
| Event-Driven | |
| Ongoing | |
| Optional | |
| Planned | |
| Repeatable | |
Illustrations
|
