Use cases define the functionality of the problem domain by establishing the goals that the system must help the users achieve. In a finished application, use cases translate into menu options, transactions, and other discrete units of work. When the use cases are refined,
you may find some that define pieces of a larger task. In this case, you may find that multiple use cases might need to be combined to provide the complete unit of work.
Dividing the functionality of the system based on use cases is probably the most subjective part of the partitioning process.
When you move on to the classes and interaction diagrams the partitions will become more clearly visible and may be tested for effectiveness.
Units of work
In some cases, one use case defines one unit of work that can stand entirely on its own. Other times, a group of use cases may define a unit of work.
Keep the following questions in mind when partitioning: Would this use case stand on its own?
Would it be reasonable for a user to complete this task and walk away, or switch to something else? If so, then try isolating the use case in its own partition. Would the users typically use a group of functions together? If so, then try putting the use cases together in the same partition. Does the result of one function influence the choices in another function?
Is there a reconciliation, balancing, or assembly type of relationship between the functions?
Beware of just copying the way users currently do their work. Ask probing questions about why the tasks may or may not be performed as a unit. Quite often, people simply do things the way they learned them, whether or not there is substantial benefit or any
fundamental dependency between the tasks.