In this step, you take the Business Use-Case Model and elaborate the black-box flow-of-events text (which is a property of each business use case) into sequences of white-box steps (which speak in terms of subsystem actions and interactions, using the subsystems and outlined collaborations from Business Architectural Analysis). If this task is performed for a subsystem for which the operations have been already specified, then the starting point are the operations and you can proceed directly to the Initial White-Box Step Expansion.

Next, a Business System Operation (black-box step) is expanded into one or more white-box steps, each of which is performed by a named subsystem. The Designer is guided by the work done by the Architect (during Architectural Analysis) in the selection of subsystems and interactions which are used to describe the white-box steps. Note that the analysis now proceeds driven by Business System Operation; that is, treat the next realization step as the realization of each Business System Operation (rather than the more abstract notion of business use case black-box step). 

Initial white-box step expansion

The white-box steps for each Business System Operation are captured (initially) in the Business Analysis Model, associated with the corresponding Business System Operation as its realization. The white-box steps are not stored with the Business Use-Case (they are shown that way here simply as an illustration), but can be traced from the Business Use Case through the Business System Operation

The description is then further augmented with locality decisions, process decisions, and worker decisions. The locality decision places, with some latitude (given the level of abstraction of locality) where the subsystem white-box step are performed. The process decision is necessary only when it is decided that (for this step at least), the subsystem is "passive," that is, its operations are invoked by processes external to the subsystem. An "active" subsystem is able to respond autonomously, using processes internal to the subsystem. The business designer is again guided by the work of the business architect (in producing the Locality Model and Process Model). In worker decisions, appropriate when you make allocations to human resources, you start to identify the organizational entities and then system worker resources needed for a Business System Operation.

If the analysis shows that a white-box step requires more than one locality (or process), then decompose it into smaller steps, so that each can be associated with a single locality (and process, where appropriate). This decomposition might have important architectural ramifications (it might need the subsystem to be refactored) and needs to be canvassed with the team or person playing the Business Architect role.

In this step, you collect together all white-box steps for each subsystem (that is, the white-box steps that belong to that subsystem). This is done in preparation for the identification of Subsystem Operations (which are to the subsystem what Business System Operations are to the business system), by examination of the subsystem white-box step descriptions. As with the identification of business system operations, there might not be a unique subsystem operation for each white-box step. Also note that the white-box steps are grouped by business system operation. For example, this might be done in tabular form as well, grouped by subsystem:

Based on the white-box steps, subsystem interactions are created in sequence or collaboration diagrams (in the Business Analysis Model). This refines the work done previously by the Business Architect. At this stage, the collaborations might still be abstract, perhaps only links are identified, or messages at an abstract level. This work, nevertheless, gives an insight into the coupling and cohesion of the subsystems. This refines the white-box step expansion performed previously (see Initial White-Box Step Expansion).