What Project Areas Are Improved with Use Cases?

Many. Here is a non-exhaustive list.

Business Model

Alistair Cockburn says, “When you read a well-written use case, you don’t see a use case, you see your business.”  Use cases ― specifically Cockburn sea-level, or user, use cases ― describe your business model, i.e., how your business interacts with your customers and internal members of your company. This perspective of interaction is exactly what a use case captures, whether it is an isolated interaction with a specific computer application, or how your business performs a long-lived business workflow such as taking, filling and shipping an order to a customer. It is true that you could attempt to represent these interactions using flowcharts, UML activity diagrams, or Business Process Modeling Notation (BPMN), but use cases are textual, always indicate who is requesting or responding, and require no special training in obscure notation.

High-level architectural scope

Actors denote entities external to a System Under Discussion (SUD) who interact with that system. Primary, or initiating, actors are users who request a service as a named use case, and receive value from the use case. Secondary, or collaborating, actors are entities that are outside the SUD who provide services to enable the SUD to provide the use case value to a primary actor. When we denote a primary actor on a use case diagram we know that actor is looking for specific value from the use cases the actor invokes. When we specify a secondary actor we are indicating that our SUD must interact with that actor, and an interface to the actor must be defined, implemented, tested and deployed. Secondary actors represent an explicit decision to place, or obtain, functionality outside the boundary, i.e., scope, of our SUD. By expanding or diminishing our SUD’s system boundary, we can expose secondary actors, or merge them inside our boundary.

User interactions

The very purpose of a use case is to describe what our system does to interact with its primary and secondary actors. What is unique about the use case relative to traditional functional requirements specifications is: the use case provides an explicit context within which the system’s functions are performed. Functional specifications are a list of functions (e.g., The system shall do this. The system shall do that.) without the process context offered by a use case.

Consider an insurance system with a functional requirement of: The system shall find policies based on user-supplied criteria. This is a perfectly good requirement, but it does not tell us why or when a user would want to Find a Policy. It does not give us a context in the user’s mind motivating them to Find a Policy. An Underwriter would want to Find a Policy in the context of Perform Rating on Policy, or Apply Coverage to Policy, or Cancel Policy, or Make a Claim on a Policy. Ah, now we see four separate business contexts (use cases) within which I would want to invoke a function called Find a Policy. Now I have a much richer understanding of my system’s purpose and business goals, of which Find a Policy is only a small part.

User Interface design

Too many use cases contain specification of user navigation from screen to screen or page to page, or user interfaces including graphical icon,s and behavior. Neither of these should be part of a use case. Rather the use case description enables the determination of user interface and navigation. The use case description presents the “what”, and is used by the UI Designer to define and implement the “how”.  I am often challenged on this point, and the consistent argument is, “We already know what the screens are, so why not put these into the use case so our customers can see exactly what they are going to receive?” To which I respond, “Well, that’s fine, but I think you should put your architecture specification and the actual code into your use cases as well.”  My point in this parody is that everyone agrees you should not put the code into a use case, which is an acknowledgment that there has to be a cut-off: not everything goes into a use case. And UI design is another set of content that do not go into a use case: the UI design consumes the use case so the UI matches and enables the user goals described in the use case.

Testing

A use case describes the behavior that a user should see in proper, “happy path” flows, as well as in the exception or error flows. This makes the use case singularly appropriate for developing test cases. A good tester can take a use case, identify its happy paths, and the exception flows, develop one or more test cases to exercise each scenario in the use case (a scenario is a distinguishable path from the beginning of the use case to any termination of the use case), and identify the test data necessary to execute that scenario. Aggressive testing can evaluate the state of the system at each action step in the use case, and develop test data to force a failure at each of these steps. I am always bewildered when I meet Quality Assurance people who see no value in use cases, thinking they are only for the front-end of the project. Once I explain that a use case is not a requirement: a use case contains requirements, they get much more interested in the power of use cases for their testing.

End-user documentation & training

Because the use case describes the system’s behavior that a user will see, use cases enable end-user documentation in a totally straightforward manner. As with testing, the use case enables the development of this documentation because the use case is the high-level outline, or roadmap, describing this behavior independent of specific technical or UI content. Since the use case documents the “what”, the documentation or training specialist simply needs to add the “how”, leveraging benefit from the use case.

Marketing information

When you aggregate all of the use cases for a system, you have a (mostly) complete specification of the value the system provides to its users. The use cases are the major services that you deliver to your users. Product Marketing people can convert the list of use cases into the marketing collateral for the project.

Coding

Managers often complain that their technical people do not understand enough about the company’s business. As above, use cases define and reveal the business model being implemented by a system. Giving use cases to developers opens this business model to these technical people.  Offering developers only the functional specification view of the system does not allow them to see the behavioral contexts within which these functions will be invoked (see User Interactions above). The system’s use cases let the developers understand the “big picture”, and better understanding means better code.

Project Management

Project Managers can enlist use cases as “sentinels” for the project. The system is not complete until, at the very least, all of the use cases have been coded and tested. A Project Manager can setup the project schedule based on the most important use cases first, less important use cases later in the project. Project status can incorporate which use cases and scenarios have been coded and tested, or which use cases remain to be delivered. You cannot successfully manage a project just by looking at the status of its use cases, but use cases give the Project Manager a new and important perspective on how the project is faring.

Finding and validating functional requirements

I am often asked, “Should we do a functional requirements document, or should we do use cases?” My reply is always, “It’s not either/or, it’s both/and”. Use cases describe the behavioral requirements for a software system, which are a subset of a system’s functional requirements. Use cases describe that portion of a system’s functionality that a user interacts with. Some projects start with use cases to describe the business processes the system supports, and then identify many functional requirements from the steps in the use cases. Some projects write traditional functional specifications, and then write the use cases to describe the process-context within which these functions are invoked. Either way is productive. Use cases offer a user-centered perspective illustrating how, when and why the system’s functionality is invoked. We need both perspectives to have a comprehensive understanding of what a system does.