• Interchange of Business Rules between Business People in Different Organizations (Units) When Making Agreements

This is one of the possible Use Cases.

1. Abstract

One of the most common patterns for activities in organizations is the making of, and delivering under, agreements. The ‘terms’ and ‘conditions’ of an agreement specify the services and products to be delivered, as well as how they are to be delivered and paid for. The ability of the parties to an agreement to interchange its business rules, i.e. the ‘conditions’ as well as the ‘terms’ in which the ‘conditions’ are defined, in a way that all the parties have the same understanding of the agreement is key to successful agreements.

Typical types of agreements that fall under this use case include:

• Trading Agreements (buy/sell products & physical items)

• Service Provision Agreements
  • Managed Service Agreements (In-house and/or Outsourced)
    • IT Service Agreements
    • Facilities Management Agreements
    • Call Center Agreements
  • Employment Contracts
  • Professional Service Contracts
• Rental Agreements
  • Property Rental (e.g. apartment rental, storefront rental
  • Property Leases (e.g. 999 year flat leases in UK)
  • Equipment Rental (e.g. car rentals)
• Regulations (agreements among law makers and interpreters)
• Construction/Manufacturing Contracts (e.g. make a dam, an airplane)
• Partnership and Merger Agreements

The interchange of rules (‘conditions’) in this use case, and the vocabulary (‘terms and facts’) in terms of which the rules are formulated, takes place between instances of the same or different kinds of Rules Systems Supporting Interchange of Human-oriented Business Rules Rules Systems Supporting Business Communication of Rules i.e. rule editing systems that support specification, analysis and quality assurance of rules in business terms using controlled natural language underpinned by formal logic.

This rule interchange is between rule editing (agreement documentation support) systems of different organization units within an organization or between organizations. It occurs at the micro level between rules-enabled agreement documentation support systems of different work groups, and at the macro level between rules-enabled agreement documentation support systems of national governments.

2. Status

Describe the status of the use case, e.g. proposed, revised, reviewed, approved etc (and by whom, using a WikiName if possible). Note that the wiki will automatically keep a revision history, so version numbers aren't necessary.

3. Benefits of Interchange

List below some benefits of interchange in this use case, i.e. why interchange matters.

• Benefit 1

• ...

• Benefit n

4. Requirements on the RIF

List requirements of this use case on the RIF.

• Requirement 1

• ...

• Requirement n

5. Breakdown

5.1. Actors and their Goals

List the different parties who interact in this use case, along with their goals. They should be named with abstract role names, like "Buyer", "Seller", "Buyer's Agent", and "Government Agency".

• Actor 1 - wants ...

• ...

• Actor n - wants ...

5.2. Main Sequence

Provide the typical course of events, ordered as below in a sequence of steps.

1. First step of sequence

2. ...

3. Last step of sequence

5.3. Alternate Sequences

Describe possible variations of the main sequence in separate subsections, assigning a title to each.

5.3.1. (Title of Alternate Sequence)

Describe the alternate sequence, referring to the steps in the main sequence above if convenient (to avoid repetition).

6. Narratives

Describe possible scenarios illustrating the use case in separate subsections, assigning a title to each.

6.1. (Title of Narrative)

Describe an individual scenario. Samples rules and other test data may be optionally included.

7. Commentary

Comments, issues, etc. Again, note that the wiki automatically keeps a revision history.