How to Define Business Processes

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.