Use cases: Who writes them, what data do you include?

Who designs use cases is only part of the issue. What, when, why, and how also need to be considered. Use cases should be designed, but frankly I usually hear about use cases being written rather than designed. Use cases are defined as how an actor interacts with the system, where an actor is usually the user but could be another piece of software or a piece of hardware.

Because the main part of a use case is a fairly concrete step-by-step description of that interaction — the actor does this, and then the system does that in response — use cases have been found good for aiding communication. That is, use cases can help a developer implement code that actually works the way a user expects, instead of the developer's guessing and ending up developing code that functions differently from the user's expectations or needs.

Typically, use cases are considered a format for documenting requirements, which means you'll get the most value when the use cases are written early so they can be a basis for developing both the software and tests of the software.

In many organizations, business analysts have the responsibility for defining requirements and thus would seem a simple answer to the question of who should design use cases. However, many other organizations don't have business analysts, and therefore use cases could be written by the project manager, a programmer, a user, or practically anyone for that matter.

Testers typically not use case authors

Testers might be unlikely use case authors at this point because they often do not become involved until later. That in itself is an issue because testers' effectiveness is diminished considerably when they are brought into a project too late, such as after the code has been written, which alas is very common. While indeed it is desirable for testers to become involved early, it is not the tester's job to define requirements. However, use cases are a helpful format for guiding testing. In fact, a valuable by-product of use cases is their natural linkage to test cases. At a minimum, a use case is tested by executing the use case.

Consequently, if use cases have not already been written to document requirements, testers frequently will write use cases themselves to use as tests. Such use cases often have the benefit of being the closest the organization has to documented requirements, but their value is diminished because they usually are written too late to also guide the developers' coding. Moreover, there's always the question of how accurate the tester's use cases are, since the fact the tester is writing them late in the process suggests there's inadequate information about the requirements upon which to base the use cases.

What the use cases document is more important than who writes them. For instance, there's a good chance that the tester's only information is the program itself that they are supposed to test. Use cases that simply reflect how the program has been written have illusory value, since they're only demonstrating the developer coded what they coded. By the way, I recently reviewed a client's testing process where developers wrote many of the use cases — after they'd already written the code. What they called use cases actually were program specs simply describing the logic they'd coded, often without even the pretense of an actor interacting.

To be an effective basis for testing, the use case must describe what should be happening, not what is happening in the program. Moreover, use cases should describe not only the main (or "happy") path, which is how the use case is normally executed, but also alternative and exception paths. Conventional testing wisdom is that separate test cases are needed to execute each path (or scenario) through the use case. In fact, many more test cases usually are needed to exercise all the various ways that the respective paths can be invoked.

Common mistakes when writing use cases

Although business analysts are the most likely use case authors and often are presumed to be trained specialists in writing use cases, they are not immune from making two other common mistakes whereby use cases describe design rather than requirements. The first is when a supposed use case actually is merely user instructions for the program's graphical user interface (GUI—click here, pull down this list, etc.), which is recognized as a mistake by many, but not all, use case authorities.

On the other hand, relatively few use case authorities, let alone use case authors, recognize a second more insidious shortcoming that afflicts practically all use cases. It's widely accepted that use cases are the user's requirements; and the user's requirements are use cases. While a use case indeed can describe the user's REAL business requirements, which is called a business domain use case, use cases almost always describe not the user's requirements but the usage requirements of an expected product/system design.

A use case is a format. Simply using a particular format does not provide any assurance that the content is correct. The more one focuses on the system use case usage how design solution, the less one tends to identify in business terms the requirements whats the use case must accomplish to provide value. Merely testing that the system use case functions as described is only part of what needs to be demonstrated. More important is also testing that the system use case in fact meets the REAL business requirements, which means that they too must be defined whether in use case or some other format.