This chapter is from the book
This chapter is from the book
This chapter is from the book
Use Case Driven
A use case is a sequence of actions, performed by one or more actors (people or non-human entities outside of the system) and by the system itself, that produces one or more results of value to one or more of the actors. One of the key aspects of the Unified Process is its use of use cases as a driving force for development. The phrase use case driven refers to the fact that the project team uses the use cases to drive all development work, from initial gathering and negotiation of requirements through code. (See "Requirements" later in this chapter for more on this subject.)
Use cases are highly suitable for capturing requirements and for driving analysis, design, and implementation for several reasons.
Use cases are expressed from the perspective of the system's users, which translates into a higher comfort level for customers, as they can see themselves reflected in the use case text. It's relatively difficult for a customer to see himself or herself in the context of requirements text.
Use cases are expressed in natural language (English or the native language of the customers). Well-written use cases are also intuitively obvious to the reader.
Use cases offer a considerably greater ability for everyone to understand the real requirements on the system than typical requirements documents, which tend to contain a lot of ambiguous, redundant, and contradictory text. Ideally, the stakeholders should regard use cases as binding contracts between customers and developers, with all parties agreeing on the system that will be built.
Use cases offer the ability to achieve a high degree of traceability of requirements into the models that result from ongoing development. By keeping the use cases close by at all times, the development team is always in touch with the customers' requirements.
Use cases offer a simple way to decompose the requirements into chunks that allow for allocation of work to subteams and also facilitate project management. (See "Use Case Model" in Chapter 2 for information about breaking use cases up into UML packages.) This is not the same as functional decomposition, though; see Use Case Driven Object Modeling with UML (Rosenberg and Scott, 1999) for an explanation of the difference.