Learning UML 2.0

Chapter 2. Modeling Requirements: Use Cases

Imagine that it’s Monday morning and your first day on a new project. The requirements folks have just popped in for a coffee—and to leave you the 200-page requirements document they’ve been working on for the past six months. Your boss’s instructions are simple: “Get your team up to speed on these requirements so that you can all start designing the system.” Happy Monday, huh?

To make things just a bit more difficult, the requirements are still a little fuzzy, and they are all written in the language of the user—confusing and ambiguous natural language rather than in a language that your system stakeholders can easily understand. See the "Verbosity, Ambiguity, Confusion: Modeling with Informal Languages" section in Chapter 1 for more on the problems of modeling with natural and informal languages.

What is the next step, apart from perhaps a moment or two of sheer panic? How do you take this huge set of loosely defined requirements and distill it into a format for your designers without losing important detail? UML, as you know from Chapter 1, is the answer to both of these questions. Specifically, you need to work with your system’s stakeholders to generate a full set of requirements and something new—use cases .

A use case is a case (or situation) where your system is used to fulfill one or more of your user’s requirements; a use case captures a piece of functionality that the system provides. Use cases are at the heart of your model, shown ...