Use-case flowdown is the technique for deriving functional requirements for the analysis (and then design) elements.
The results of the activity are:
survey of subsystem operations
survey of hosted subsystem operations for localities
survey of executed subsystem operations for processes
use-case survey for subsystems (optional)
The technique uses the standard RUP activity of choosing an architecturally significant set of use cases. For each
chosen use case, the flow of events is developed. This is the description of the interactions between the system actors
and the system. The system responses are black box; the descriptions make no reference to the architectural elements.
Next, a black-box step (which will be performed by a system operation) is expanded into one or more white-box
steps, each of which is performed by a named subsystem. The white-box steps are also associated with the
localities which host them, and the processes that execute them. Each white-box step that spans
localities or processes (that is, requires more than one to complete) is split until it can be completed at a single
locality, by a single process. A white-box step can be replicated at several localities, but these are independent
instances. These white-box steps are candidates to become subsystem operations, which are the equivalent of
system operations at this lower level of logical decomposition.
The compositions of unique sequences of subsystem operations for an individual subsystem, participating in the
realization of system operations, yields the subsystem use cases (optional step).
At the outset of use-case flowdown, you are dealing with a system which typically spans (and might even encapsulate)
several localities; the depth to which decomposition into subsystems (and sub-subsystems) is performed, is a matter for
architectural judgment, and depends on the domain and the complexity of the system, among other things. However, for
the purposes of performance analysis it is important that you understand the computational load to be imposed at a
locality, and this is done in terms of the subsystem operations hosted there. Therefore, consider the following
prescription for decomposition: the decomposition must yield a set of subsystem operations that cleanly partitions
between localities; that is, a subsystem operation does not span localities, and if a subsystem operation (of,
say subsystem A) requires, for its performance, the use of resources at a different locality, then those resources must
themselves be made available through a subsystem operation, which might be provided by subsystem A itself at that
locality, or another subsystem.
This condition will obviously hold if a subsystem does not span localities, but a subsystem can span localities if its
operations can be partitioned as described—otherwise, the subsystem must be decomposed further. The discussion here
concerns single instances of a subsystem spanning localities; a subsystem can always be replicated at several
localities, but these are separate instances.