The Unified Modeling Language User Guide (UML) defines a use case as follows:
A use case specifies the behavior of a system or a part of the system and is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.
A use case is an outside view of the system as seen by the entities interacting with the use case. It is used for capturing the requirements of a system. A use case is not atomic; a use case representing a complex system behavior can be further decomposed into more use cases. A use case is essential for creating a common understanding of the system behavior between the business domain experts, the application architect, and developers, without specifying how that behavior is implemented. During design, a use case is realized by a set of related objects working together to deliver the behavior prescribed by the use case. Models created during design must be able to map back to the requirements by their ability to satisfy each use case within the problem domain. The use cases therefore help validate the architecture. In an iterative design and development process, use cases enable catching of deviation from requirements early in the life cycle; all models and project artifacts are synchronized for accurately reflecting the purpose of the system all throughout the project life cycle. As such, risks are identified early in the process, therefore preventing major rework later.
Use cases document the system and form the bases of test cases for user acceptance, integration, regression, and system tests. This approach has built-in traceability because all design, development, and testing is performed based on use case scenarios. The use cases become a contract between the business units and the IT organization. By employing incremental and iterative approaches, this contract is enforced throughout the development life cycle by verifying intermediate artifacts against the behavior prescribed by the use cases. The use case model is central to all analysis and design artifacts, and for project planning.
This book consistently strives to live by the word "practical" in its name. Therefore, every concept presented in this book is explained using the fictitious GreaterCause application. The use cases discussed in this chapter will lay the foundation for understanding the problem domain. The use cases will be subsequently realized using architecture and design artifacts explained in the rest of the book.
Subsequent sections in this chapter explain what, why, when, and how to capture system requirements for the sample application. In this chapter, the following sections denote the artifacts created for the sample application:
GreaterCause System Definition
GreaterCause Context Diagrams and Actors
GreaterCause Risk Factors
GreaterCause Use Case Packages
GreaterCause Use Case Summary
Familiarity with the preceding structure will assist you in distinguishing the project artifacts from the commentary that surrounds the artifacts.