Define the boundary of the system:

• Define the boundary of the organization as defined by the "system";
• Define the list of products and services involved in the system;
• Define the Domain and authority;
• Bound (only if necessary) the business functions within the delivery of products / services. This is not ideal.  It is always best if the scope can address the complete end-to-end delivery of a service or product. An architecture that targets only a specific business function is more analogous to a renovation, particularly if that renovation is designed in the absence of an overall architecture. There is always something left out or that doesn’t fit together well when this occurs.
  

Ensure that the described business elements are clearly defined and understood including required relationships.

Review the results:

• Look at each Artifact: Business Actor: What are his/her interactions with the system? 
• Look at each Artifact: Business Activity:  Do you understand the business value the activities? 
• Look at each Artifact: Business Activity:  Is it complete? Or is this just a small part of something bigger?
• Look at the Actors and Activities: Is there a Artifact: Business Location implied (e.g.  ATM, branch, store, warehouse, etc.) List the business locations.

Questions to ask:

• Every Actor should interact with at least one business activity. If not, it may be because there is a duplicate (of another Actor) or because the Actor is really not a direct user of the system. In these cases, if a discussion of the merits of keeping the Actor yields no strong reasons to keep it, it may be removed.
• Every Business Activity is 'deployed'  to a location where the business operations, list these and agree definitions
• Every Business Activity typically consumes and produces Artifact: Business Entity, the information used by the business. Name these and agree definitions.

Ensure that the follow-on actions, if any, are clearly defined and assigned.