Typically this is done by detailing business scenarios. Within UAM "use-cases" are not recommended nor used since they are greatly misunderstood and often abused. Just define scenarios, with the help of business experts, refine them and combine them as required. Start with a wide general view of the system and added detail as the models are developed.

Not that only external actors are defined at this point. The analysis (and architectural decisions) required to specify "roles" are left until the Logical level of analysis.

Optionally, during the definition of business processes various business entities, business rules and business events may be identified. This should not be onerous ... simply identify the main elements that are important to the business. Greater definition of these elements is again left until the Logical level analysis.

Sometimes simple process definitions are not enough to capture the activities with the system. In this case a number of interacting process may be defined. Within BPMN these are defines as "conversations" ... but UAM simplifies this type of complex interaction to be a set of interactive processes. We are defining IT architectures, therefore the level of detail (and therefore the number of design-level decisions) is reduced to a manageable level.

Ensure that the interactions with the "system" are complete and that they are organized in such a way as to make the understandable and manageable.

The Business Process Model is complete only when it describes everything the business performs (within the given scope). Ensure that the Business Process Model exhibits the characteristic properties of a good model diagram, see: Guideline: Business Process Model.

Evaluate each workflow by doing a walkthrough. This is where the person responsible for the business process (business expert) leads one or two members of the team through the business workflow. It is recommended to use a specific scenario ... or a few, to ensure coverage.