Some use case practitioners may take issue with the steps I’m recommending here. “Too detailed!” they’ll say. There are business analysts who employ use cases who will argue that the largest of organizations might be modeled with maybe 15 use cases. They will argue— strongly—that more than that is a sign that you’re thinking in too much detail. They will further tell you that you can’t “decompose” a use case into smaller pieces.

But then there are system designers who say, “I was working on a small system last month. It was only around 80 use cases.” (I’ve even heard both perspectives— a few large use cases versus many small use cases—coming from two different people within the same organization.)

So who’s right? Remember: if you ask me “ A or B?” my answer is usually “Yes” or “ C.” This is another “Yes” answer. I think business analysts are right: when trying to think of how to organize a business’s operations, you have to look at very high-level operations. If you have a large number of operations, you can lose track of everything. Their use cases are often along the lines of Accounting and Facilities and Human Resources.

But I think system designers who have more and more detailed use cases are right in that these use cases are more concrete and more implementable. If I ask ten programmers to implement a use case like Facilities, I’ll probably get 20 different implementations—or I’ll get ten programmers throwing things at me for giving them such a lousy spec. But if I ask ten programmers to implement Display Available Facilities, I’ll get a lot closer to consensus.

So it’s important that, at various stages of software development, you have use cases of varying size and scope, ranging from large and broad to small and detailed. I think that the same basic strategy embodied in Five-Step UML— define your system requirements in terms of the use cases needed by something outside your system; refine each use case into a set of activities; assign those activities to parts of your system; design the relationships among those parts; and repeat at the scope of a more detailed part of your system, in an iterative fashion—is a useful strategy across all the scopes of use cases. (It’s also neither new nor earth-shattering; but I think that when merged with UML, it becomes very clear and easy to apply.)

The scopes to which I believe this Five-Step strategy may be applied can be summarized in Table 2-1.

Table 2-1. Five-Step UML at Varying Scopes of Analysis and Design

Scope	Usage
Business	At this scope, you’re analyzing the organization and functions of an entire business or organization, with a focus on its interactions with other businesses, governments, etc.  Actors reflect broad categories of external entities: governments, vendors, suppliers, customers, etc. Use cases reflect the basic operations of the organization. Structural elements reflect the business units or departments that carry out the operations.
Service	At this scope, you’re analyzing the organization and functions related to particular services of the organization. For instance, if the service is Purchasing, then operations might include ordering, tracking, receiving, and returns. (This scope, falling somewhere in between Business and Domain, won’t be necessary except for larger organizations.) Actors reflect the individuals and systems that require and carry out these operations. Use cases reflect the services performed by the business units or departments. Structural elements reflect broad categories of domain objects that must be maintained, subunits of departments that carry out particular operations, and facilities where operations take place.
Domain	At this scope, you’re analyzing particular domain objects that must be represented or maintained in the system.Actors reflect the individuals who require the domain objects, along with the individuals who maintain them. Use cases reflect the maintenance and transfer of domain objects (documents, schedules, etc.) that support the services of the business units. Structural elements reflect the specific domain objects maintained, particular teams that carry out operations, and particular machines or devices used in maintaining or producing domain objects.
System	At this scope, you’re analyzing the workflows involved in maintaining particular domain objects, along with the user interfaces and components that support those workflows. Actors reflect the individuals who implement the workflow. Use cases reflect the steps in the workflow. Use cases may also reflect detailed user interface interactions, when this helps to explain the user interface. Structural elements reflect the user interfaces, interfaces to other systems, the components that provide the interfaces and user interfaces, other components, and interfaces between the components.
Implementation	At this scope, you’re designing particular components of the system. Actors reflect persons and other systems and other components that interact with the component. Use cases reflect the requests made through interfaces and user interfaces. Structural elements represent classes and interfaces within each component.
Class	At this scope, you're designing particular classes. No actors. No use cases, simply class operations; but these may be analyzed in a fashion similar to use cases. Structural elements represent attributes, associations, dependencies, and interfaces of each class.

The strategy is important; it’s not just rigid rules about counting use cases. It’s a way of thinking about problems and communicating your thoughts and solutions.