9.1. What Are Use Cases?
When determining what the desired functionality of a system is to be, we must seek answers to the following questions:
Who will want to use the system?
What capabilities will the system need to provide to be of value to them?
When users interact with the system for a particular purpose, what is their expectation as to the desired outcome?
Use cases are a natural way to express the answers to these questions. Each use case is a simple statement, narrative or graphical in fashion, that describes a particular goal or outcome of the system, and by whom that outcome is expected. For example, a goal of the Student Registration System (SRS) could be to "enable a student user to register for a course" or to "allow a professor to agree to teach a course." Thus we've just expressed our first use cases! Yes, use cases really are that straightforward initially. In fact, we need for them to be that straightforward, so that they are understandable by the users/sponsors of the system, as we'll discuss further in a moment.
9.1.1. Functional versus Technical Requirements
The purpose of thinking through all the use cases for a system is to explore the system's functional requirements thoroughly to make sure that a particular category of user, or potential purpose for the system, isn't overlooked. We differentiate between functional requirements and technical requirements in the following sections.
Functional requirements are those behaviors of a system that have to do with how it is to operate or function from the perspective of someone using the system. Functional requirements might in turn be subdivided into the following:
Goal-oriented functional requirements: These requirements provide a statement of a system's purpose without regard to how the requirement will "play out" from the user's vantage point—for example, "The system must be able to produce customized reports." Avoid discussing implementation details when specifying goal-oriented requirements—for example, "The system must be able to produce customized reports using CrystalReports." We emphasize goal-oriented functional requirements when preparing use cases.
Look and feel requirements: These requirements get a bit more specific in terms of what users expect the system to look like externally (for example, how the graphical user interface [GUI] will be presented) and how they expect it to behave, again from their perspective. For example, we might have as a requirement "The user will click a button on the main GUI, and a confirmation message will appear. . ." A good practice is to write a concept of operations document to serve as a "paper prototype" that describes how you envision the future system will look and behave, to stimulate discussion with intended users of the as-yet-to-be-built system before you even begin modeling.
Technical requirements, on the other hand, have more to do with how a system is to be built internally in order to meet the functional requirements; for instance: "The system must be compatible with the TCP/IP protocol . . . " You can think of these requirements as fixed constraints on technology, in contrast with functional requirements, which are a statement of what the problem to be tackled actually is. Technical requirements such as these don't play a role in use case analysis.
Although it's certainly conceivable that the users of our system might be technically sophisticated, it's best to express functional requirements so that even a user who knows nothing about the inner workings of a computer will understand them. This helps to ensure that technical requirements don't creep into the functional requirements statement, a common mistake made by many inexperienced software developers. When we allow technical requirements to color the functional requirements, they artificially constrain the solution to a problem too early in the development life cycle.
9.1.2. Involving the Users
Users are the ultimate experts in what they need the system to do, so it's absolutely essential that they be involved in the use case definition process. If the intended users haven't (as individuals) been specifically defined or recruited, as with a software product that is to be sold commercially, their anticipated needs nonetheless need to be taken into account by identifying people with comparable experience to serve as "user surrogates." Ideally, the users or user surrogates (the human ones, anyway) will write some or all of the use cases themselves; at a minimum, you'll interview such people, write the use cases on their behalf, and then get their confirmation that what you've written is indeed accurate.
Use cases are some of the first deliverables/artifacts to emerge in a software development project's life cycle. They turn out to be quite useful as a basis for writing testing scripts, to ensure that all functional threads are exercised during system and user acceptance testing. They also lend themselves to the preparation of a requirements traceability matrix (that is, a final checklist against which the users can verify that all of their initial requirements have indeed been met when the system is delivered). Of course, a requirements traceability matrix must take into account all of the requirements for a system—functional as well as technical—of which use cases represent only a subset. An example of a requirements traceability matrix created inside an Excel workbook is shown in Figure 9-1.
Figure 9.1. A sample requirements traceability matrix
Returning to the questions that we posed at the outset of this section, let's answer the first question ("Who will want to use our system?"), which is known as identifying actors in use case nomenclature.