Modeling Business Scenarios 
The name of a Business Scenario is unique (within its namespace). This name is not language-specific. Special characters and blanks are not permitted.
Note the following conventions for names:
· The Business Scenario must have a meaningful name. The name should be written in English so that it is globally understood.

Separate individual words by switching between uppercase and lowercase characters (see the notes on naming conventions for design objects under Creating New Objects).

Example: BookFlightTrip
The description gives more details about the Business Scenario. It is not language-specific and is displayed in the language you are logged on in.
Follow the usual conventions for short descriptions here.

Example: Book Flight Trip
You must assign a software component version to a Business Scenario when you create it. This assignment defines the software component versions that are delivered to the customer with the Business Scenario (as a design object of the Integration Builder).
Note the following aspects when selecting a software component version:
· Choose the software component version according to your shipment strategy
· Often there is one leading product (for example, SAP APO) within a Business Scenario that defines it and takes organizational responsibility. In this case, the Business Scenario should be assigned a software component version that is appropriate for this product.
· However, it is also possible to assign the Business Scenario to a software component version that corresponds to another product or to none of the products used, if required.
You have the option of varying the scope and level of detail of Business Scenarios. This is foremost a decision to be made during modeling.
Note the following aspects:
· The Business Scenario must represent a completed business process or clearly defined part of a process.
· The Business Scenario is transferred as a whole to configuration. Different sub processes must therefore only be grouped together for a Business Scenario if all parts are always to be configured together.
· The Business Scenario must not become so large that it ceases to be comprehensible for the user.
· Completed sub processes at the start and end of a Business Scenario can possibly lead on to separate Business Scenarios. This is particularly interesting if a sub process of this type occurs in multiple Business Scenarios (enables it to be reused and reduces complexity).
· Take into account any existing modeling results in the Solution Manager or Business Process Repository.
At present, the Integration Builder does not support any explicit variant-management of Business Scenarios.
Therefore, note the following aspects for variants of a Business Scenario:
· You have the following options for representing the variants of a Business Scenario:
· Represent multiple (or all) variants in a Business Scenario
· Define separate Business Scenarios for different variants
· SAP strongly recommends that you represent all variants in a Business Scenario if possible. You must only define separate Business Scenarios for variants in exceptional cases.
· You might, for example, explicitly model the main variants.Document exceptions and sub variants.