Next, working from the white-box steps and the Operation Realizations, the Subsystem Operations are identified and their behavior specified. As with the identification of system operations, there might not be a unique subsystem operation for each white-box step; that is, as you examine the set of white-box steps and their associated exchange of messages, input-output entities, and so forth, you might find that it is possible to define a smaller set of Subsystem Operations to fulfill their needs.

The process allows you to reason about concurrency issues: if you were to view a Subsystem Operation as a discrete piece of functionality available to actors, then, as a first approximation, operations associated with the same process cannot be performed in parallel. This might lead you to reconsider the process allocation, or consider process replication, or to examine the perceived latency problem at a lower level of detail, for example, through examination of time-slicing options, and process sharing when an operation blocks (to do input-output, for example). These techniques can give acceptable responsiveness, whereas a delaying of the start of an operation (strictly serializing operations) might be intolerable. In this form, the survey sorted by process becomes a property of the System Model.