Status attributes for Business Rules

See Also

Business Rules have the following optional status attributes:

For each of these four attributes there is also a user attribute (Defined By, Approved By, Built By, Tested By).

The consistent use of at least the four Y/N flags is highly recommended because these flags are very helpful for querying the rule repository once a system has grown to certain proportions. On principle, the flags are intended to be set in the order stated (first Defined, and so on) but this order is not enforced.

Set a rule to Defined when the development team wants the customer to approve it.

Set a rule to Approved when the customer has validated the rule as being a correct description of the actual state of affairs in the business, or a correct description of the desired target situation. USoft TeamWork sets Approved to No whenever a Rule's Definition is changed.

Set a rule to Built when the development team has implemented the rule in the information system. At this time, it is recommended to specify what is (are) the Implementation(s) of the Business Rule.

Business Rules cannot have Requires Implementation set to No, and Built set to Yes.

In combination with the Repository Version attribute and the Must Have flag for Priority, the Built flag can be used to determine whether all the work associated with an upcoming version release has been completed, or what are the tasks that must minimally be performed before that version release is possible.

Set a rule to Tested when the rule has been tested successfully. You can use this flag in a development environment and then again in a test environment. To do this, make sure that you set all the Tested flags for rules with the current Repository Version to No as soon as you have transferred the development repository to the test environment.

USoft TeamWork sets Tested to No whenever a Rule's Implementation(s) is (are) changed.

You can optionally specify Test Needs for the Business Rule.