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 coffeeand 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 userconfusing 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 newuse 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 in Figure 2-1, since they affect and guide all of the other elements within your system's design.

Figure 2-1. Use cases affect every other facet of your system's design; they capture what is required and the other views on your model, then show how those requirements are met

Use cases are an excellent starting point for just about every facet of object-oriented system development, design, testing, and documentation. They describe a system's requirements strictly from the outside looking in; they specify the value that the system delivers to users. Because use cases are your system's functional requirements, they should be the first serious output from your model after a project is started. After all, how can you begin to design a system if you don't know what it will be required to do?

Use cases specify only what your system is supposed to do, i.e., the system's functional requirements. They do not specify what the system shall not do, i.e., the system's nonfunctional requirements. Nonfunctional requirements often include performance targets and programming languages, etc.

When you are working on a system's requirements, questions often arise as to whether the system has a particular requirement. Use cases are a means to bring those gaps in the user's requirements to the forefront at the beginning of a project.

This is a real bonus for the system designer since a gap or lack of understanding identified early on in a project's development will cost far less in both time and money than a problem that is not found until the end of a project. Once a gap has been identified, go back to the system's stakeholdersthe customers and usersso they can provide the missing information.

It's even better when a requirement is presented as a use case and the stakeholder sees that the requirement has little or no value to the system. If a stakeholder can discard unnecessary requirements, both money and time are saved.

Once priority and risk are assigned to a use case, it can help manage a project's workload. Your use cases can be assigned to teams or individuals to be implemented and, since a use case represents tangible user value, you can track the progress of the project by use cases delivered. If and when a project gets into schedule trouble, use cases can be jettisoned or delayed to deliver the highest value soonest.

Last but not least, use cases also help construct tests for your system. Use cases provide an excellent starting point for building your test cases and procedures because they precisely capture a user's requirements and success criteria. What better way to test your system than by using the use cases that originally captured what the user wanted in the first place?