In continuing to cover all 49 BABOK® techniques, this entry is about scenarios/use cases.
Since most people refer to these as use cases, that’s the name I’ll use. They are a great way to elicit, analyze, and model interaction requirements. Plus, they help generate related requirements for interfaces, data, process, and business rules.
I gave a use case training class last week, so it’s fresh in my mind. It also influenced me to put this explanation in question and answer form.
Q. What is a use case?
Use cases and scenarios describe functionality that describes how actors interact with a system. The system could theoretically be anything, but use cases most commonly are used with online or web applications. The term “use case” is often a short version of “use case narrative” or “use case flow of events” and is shown as an oval in a use case diagram as in the example above. They are written as text and divided into primary, alternate, and exception scenarios.
Q. What is an actor?
Actors interact directly with a system, and can be humans, systems, or event/time triggers. In a banking system, an actor might be a teller who enters banking transactions and a Customer Information System that supplies and maintains customer data. They are shown outside the use case diagram as stick figures or using an icon like in the example above.
Q. What are associations?
These show which use cases an actor can initiate and which actors a use case can access. The line between an actor and its associated use cases depict the associations. The BABOK® uses the term association for this concept, and another common term for this is interface.
Q. What is a scenario?
A scenario is one path or flow through a use case. Typically a use case has a primary scenario, one or more alternate scenarios, and possibly exception scenarios. For example, a bank transaction might be completed using a customer’s account number (primary path), using the Customer Information system to look up the account number (alternate), or be cancelled (perhaps due to not locating the account number). One of my favorite ways to summarize use cases to my students is they are a collection of related scenarios in the accomplishment of a goal.
Q. What is a use case model and what are its components?
A use case model contains the use case diagram and the text scenarios and flows.
Q. What does the BABOK view as the specialized relationships in use cases?
There are two specialized use case relationships described in the BABOK. There is a third (and useful) relationship that the BABOK does not describe, but I listed it below for completeness.
- Extend- documents the place in a use case to add future extended functionality, like an alternate path in a separate use case. “Search Name Phonetically” is an example below of an extend relationship.
- Include – provides access to shared functionality in a separate use case. The common functionality is housed in a separate use case and is “included” by one or more use cases that share the same functionality. In the banking example, looking up customers by name is a common function that would likely be in an included use case, such as “Locate Customer” below.
- Generalization –separates the general interaction steps from specific detailed steps for use cases that have a Parent-Child sub-type structure. In the following example, there is a generic Transaction entity with a use case of “Make Transaction” that has sub-use cases of “Make Deposit,” “Make Withdrawal,” and “Make Loan Payment.” Actors can be generalized as well. (This is an accepted and useful relationship that was included in BABOK® version 1.6. I would like to see it added back to BABOK® version 3.)
To sum up, Use Cases are an important and widely used technique for capturing interaction requirements. They provide a structured means to uncover many hidden and detailed requirements, and they can lead to related interface and data requirements. Because of their importance in the industry, expect to be tested on them in the CBAP exam.
LEARN MORE: For more information, read our article on Use Cases called Demystifying Use Case Modeling. It requires a simple one-time registration for you to access it. Once registered, you can read dozens of other interesting article on business analysis and project management. A good, basic book on Use Cases I recommend is called Applying Use Cases, Second Edition, by Geri Schneider and Jason Winters, ISBN 0-201-30891-5. We also teach a practical, concise training course on Use Case Modeling to learn this technique in-depth.