|
See Also
A business process is an
organized chain of actions or events in a business area. For
example, in a car rental company, the various actions involved in
renting a car to a customer constitute a business process.
A business process usually
breaks down into a sequence of individual process steps. In the car
rental example, the first step could be customer registration or
(in the case of an existing customer) identification. Next steps
could be down payment, reservation, final payment, contractual
agreement, the physical delivery of the car, actual use of the car,
and finalization of the transaction after use.
In USoft, you define a
business process by defining its individual Business Process Steps
and then organizing these steps in a sequence.
To define a business process
step:
| 1.
|
From the menu bar, choose TeamWork, Definition, Business Rules
or double-click Business Rules in the catalog. |
The Business Rules window
appears.
| 2.
|
Provide the business rule with a unique identifier (Rule ID).
Give an ID that will not need to be updated when you reorganize
your model. |
| 3.
|
Provide a short description of the business rule. This
description can be used to find the business rule again. |
| 4.
|
In the Type field, indicate whether it is a restriction,
deduction, instruction, etc. |
| 5.
|
Indicate to which business object the rule applies, and give a
print sequence number of the rule. |
| 6.
|
Indicate to which set the rule belongs, and give a print
sequence number within the set. |
| 7.
|
In the Description field, enter a full description for the
business rule. Business rules are best described in natural
language. This makes them easier to identify and understand. |
NOTE:
Do not use this field for
remarks (use the Notes instead).
| 8.
|
Click the Status button to view or change the current status of
the business rule. In the status window, USoft Developer will
automatically: |
|
·
|
Assign the new business rule to the current repository
version. |
|
·
|
Stamp your user name and the date/time into the fields for
change logging. |
To facilitate progress
monitoring:
|
·
|
In the Approved By field indicate the initials of who is to
approve the definition of the business rule. |
When the Approved field is
checked this indicates that the rule is described properly (and
therefore can be built).
|
·
|
The Built By field enables the application developer to
indicate who is responsible for building the rule. |
When the Built field is
checked, this indicates that the rule is built.
|
·
|
If the rule has to be changed later on, clear the Approved and
Built fields to indicate that the process has to start all over
again. |
|
·
|
The Tested By field enables another developer to indicate who
is responsible for testing the rule. |
When the Test field is
checked, this indicates that the rule has been tested.
|
·
|
The Created On field is where the date on which the design of
the business rule was created is indicated. |
|
·
|
The Created By field allows the project member(s) who created
the business rule to indicate this. |
|
·
|
The Changed On field is where the date on which the design of
the business rule was created is indicated. |
|
·
|
The Changed By field allows the project member(s) who made the
most recent change to the business rule to indicate this. |
| 9.
|
Use the lookup button to choose the motivation behind the
business rule expressing the business objective or
requirement. |
| 10.
|
Provide a classification to group together different types of
business rules. |
| 11.
|
Use the lookup button to choose the source of the business rule
to be inserted in the field. |
| 12.
|
Click the Add Rule button and the Business Rule wizard appears.
Enter the requested information in each of the wizard's dialogs to
add a constraint to a business rule. |
|
