By: Joe Goss
A use case has been described as a formalized story that illustrates how someone procedurally interacts with an existing or proposed system. Alistair Cockburn popularized the concept of use cases in his book, Writing Effective Use Cases. I have found in my practice as a business analyst, use cases provide invaluable guidance to analysis, development, and testing teams in the creation of a new system.
What does a use case look like? The document at the bottom of this article represents a detailed description of a business process called “Customer Gets Cash from an ATM.” I share this document in draft form, as it certainly contains flaws. Nevertheless, it conveys the structure and content of a complete use case.
When to Develop A Use Case
A use case requires more time to develop than a business process model (i.e., a swim lane diagram) and certainly longer than it takes to create a set of user stories. Even so, a use case provides extraordinary value to downstream consumers, whether a development, a process improvement, or a testing team. I therefore encourage a stakeholder team to develop a use case when several of the following conditions are true.
1. The complex steps in an operational process should be documented.
I find it extremely useful to facilitate a small group of subject matter experts when developing a use case. The exchange between these stakeholders promotes holistic discovery about the process. The result is a use case that accurately and completely documents the operational process under study.
2. Team members with different perspectives on a process need to reach agreement about the process steps.
Often a team member has a unique and important perspective on the process. Indeed, I’ve experienced situations in which three or four stakeholders, all performing the same operation, had completely different viewpoints on the process steps. Reaching agreement is critical – whether writing a use case to describe the “current state” or an ideal “future state.” Writing a use case will help the team reach agreement about the procedural and contextual dimensions of the process.
3. The process includes multiple alternative and/or exception paths.
Think of an alternative path as a way to achieve success, but one that requires additional steps beyond the simplest and most direct steps in the “main path.” An exception path is one that ends without achieving the desired process outcome. These alternative and exception paths are often good targets for process improvement. For that reason, they should be documented so the stakeholder team can identify these improvement opportunities.
When Is A Use Case Valuable?
Often members of a software development team understand little about an organization’s operations. Good understanding is a critical success factor when developing usable and useful application software. A use case is valuable to that team when:
1. Current business processes are not well understood by developers.
User stories, which are critical artifacts within agile development methodologies, are excellent cornerstones for conversation between a developer and an end-user. I find however, that user stories are sometimes too fine-grained. The scope of a use case helps developers see how user stories fit together into an effective and efficient process.
2. The terminology used in the functional domain is unclear.
Conversing in a common language is critical in any software development effort. A use case, inevitably written from the perspective of the people who will use the new system, identifies the jargon used by stakeholders and provides valuable context for each of the terms used.
3. The technical solution must support workflow capability.
A use case is a valuable medium for capturing the interplay among multiple operators (or “actors” in the nomenclature of use cases). In such circumstances, it may be helpful to write a use case describing the workflow at a mid-level of summary with references to fine-grained use cases or user stories.
4. Business rules need to be enforced in the new system.
A business rule defines or constrains activity. Business rules complement the process information in a use case. Far too often, business rules are not captured when eliciting functional requirements. I find that enough information emerges while writing a use case to identify and document these business rules. Indeed, as the example indicates, I routinely include space in the use case for recording these business rules.
Use Cases for Testing Teams
A testing team needs source material for the tests it will perform, as well as a standard to compare against new software functionality. Use cases serve these purposes well.
1. Develop test cases to ensure the new software works as it should.
There are many facets of good software testing. A “future state” use case can help a tester confirm that the future user can achieve their process goals, that each process step is supported, that business rules are enforced, and that any necessary alternate and exception paths are handled correctly.
2. Discover gaps between the requirements and the delivered software.
Though the need is rare, use cases are a standard against which the developed software can be compared. Stakeholders can hold programmers accountable for differences between what was expected and what was delivered. On a few occasions, I have had to call to task the development team for failing to meet the requirements defined through use cases.
I will not discuss in depth here what a business analyst, systems analyst, or a development team can derive from a use case. Nevertheless, it is important to know that a set of use cases are the source for developing screen prototypes or wireframes, designing the logical database, and creating a list of the required tables, fields, and field attributes.
Use cases have an important role in process improvements and software development.
About the Instructor: Joe Goss
Joe is a senior business analyst and project manager at the University of Wisconsin–Madison Division of Information Technology (DoIT). Joe’s background includes significant work in providing solutions to public and private organizations in sectors including agriculture, accounting, education, manufacturing, retail, public housing, law enforcement, judicial courts, public health, and natural resources. Over a 35-year career, he served clients while employed at several software development companies, a regional accounting and consulting firm, and an international computer vendor, in addition to his work as an independent consultant.