Use Case Modeling

Ivar Jacobson et al.^[3] popularized the application of use cases for understanding the functional system requirements in the early 1990s. Later, use case notation was incorporated into the Unified Modeling Language (UML). It is seemingly simple in concept but highly useful, especially in understanding the functional requirements for large and complex systems.

^[3] Jacobson, Ivar, et al. Object-Oriented Software Engineering. Addison-Wesley, 1992.

In the context of this book, use cases are very important as the RUP is very much a use case-driven development process. Not only are use cases used to capture the requirements, but they also provide the foundation for activities from analysis through testing.

There are two fundamental concepts in use case modeling:

• Actor: An actor represents something (or someone) outside the system, typically a user of the system. Actors interact with the system, which results in some action by the system. Each distinct role is represented by an actor.

• Use case: A use case encapsulates a sequence of steps performed by the system on behalf of an actor. Use cases provide something of value to the actor. A use case consists of a primary sequence of events and may have one or more alternate sequences of events.

Requirements come in two primary flavors: functional and nonfunctional. Functional requirements, which are focused on what the system must be able to do, lend themselves easily to use case modeling. Nonfunctional requirements are focused on things such as usability and performance, and are harder to model using use cases.

Let's put use case modeling into practice by applying these concepts to the HomeDirect system case study—requirements of which are detailed in Chapter 16.

To get the most out of the remaining discussion, you should review the “HomeDirect Requirements” section in Chapter 16 before continuing on.

We will focus on the functional requirements to derive the use cases.