This two-part tutorial looks at use cases' strengths and weaknesses and includes examples and critiques of various use case formats.
Table of contents:
Part one: Use cases versus test cases and alternative and two-column formats
Part two: Inside requirements use cases: Advanced formats, test case comparisons
While my experience was that originally developers didn't especially warm up to use cases, today developers highly regard use cases, often bordering on a religious-like zealotry. Beyond the technique's virtues, I think this wide-spread acceptance is due much more than is recognized to the extensive public relations efforts which since the early 1990s have been branding and "selling" use cases as the de facto requirements format, originally as part of Ivar Jacobson's Objectory object-oriented methodology and subsequently in its successors, Rational Unified Process (RUP) and Unified Modeling Language (UML).
In this second part of my use cases tutorial, I'm exploring alternative and exception paths and two-column uses cases. Then, I get into the more thoughtful issues of the relationship between use cases and test cases and sticky problems with use cases. In part one of this tutorial, I looked at the issue of
using use cases only and narrative and single-column use case formats.
Alternative and exception paths
In addition to the happy path, a use case also usually includes several alternative success paths and some exception failure paths, such as:
Each path is often called a "scenario." There are many possible forma...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
t variations for depicting such alternative and exception path scenarios. For example, rather than just showing only the additional steps and where they branch from and to the happy path, some use case writers show all the steps in each scenario. Thus, the second alternative success scenario would include the 1, 1.1, 1.2, 1.3, and two through nine steps; and the third exception failure scenario would include the 1, 1.1, 1.2, 1.2.1, 1.2.2, and 1.2.3 steps.
Since a use case can have many scenarios, the seemingly simple and clear format quickly can become cumbersome, complex, and confusing. In part through mere oversight, and no doubt also in part to avoid what could become considerable added work, use case writers commonly fail to describe many potential alternative and exception scenarios.
Some techniques that can help simplify use case complexity are based on recognizing that use cases can be hierarchical. That is, each step in the above happy path in turn could represent individual subsidiary use cases. For example, Step 1 above could be defined in more detail as a separate subsidiary use case for "Identify Customer." The above alternative and exception paths would be included in the "Identify Customer" child subsidiary use case rather than in the main parent "Place an Order" use case.
Related use case formatting conventions also provide for explicitly identifying use case inclusions and extensions. For instance, perhaps the "Identify Customer" use case actually pertains not only to the "Place an Order" use case but also to "Request an Account Statement" and "Inquire about an Order" use cases. Rather than repeating all the "Identify Customer" steps within each of the other use cases, "Identify Customer" could be defined as a separate use case and then be included by a simple non-repetitive reference in each of the other use cases.
Let's say also that whenever a customer is identified, they could be invited to apply for a credit card. "Apply for a Credit Card" could be described as a separate use case which is referenced simply as an extension to the "Identify Customer" use case.
It's important to recognize that each supposed simplification technique also can create its own confusing complexities. Many use case writers find use case diagrams helpful to show the existence of and relationship between multiple use cases. In a use case diagram, each actor is represented by a stick figure and each use case by an oval. Arrows and inclusion/extension labels show relationships among the actors and use cases.
Two-column use cases
I generally prefer a two-column use case format, which I find offers a number of advantages. The left column shows the actor's/user's actions, and the right column shows the system's responses. While I'm sure some people show each two-column scenario separately as is described above with regard to one-column use cases, I find it preferable to include alternate and exception paths within the single two-column use case. For example, a two-column "Place an Order" use case could be:
U1. Identify the customer in the database by Customer ID. R1.1 System displays customer's identification information. (U4)
.R1.2 System displays message indicating customer is not in the database. U2. Enter customer identification information
R2.1System adds customer to database information. (U4)
R2.2 System indicates customer identification information is invalid.
U3. Quit placing the order.R3. System exits the use case. (R7)
U4. For each item to be ordered, select the item from a menu of items for sale.R4. System displays the item's ID, description and unit price.
U5. For each item to be ordered, indicate extended price equals the quantity of the item ordered. R5. System calculates the extended price equals quantity times unit price.
U6. Indicate order is complete. R6. System calculates the total amount due equals sum of extended prices for all items ordered.
U7. Pay the total amount due.R7. Exit.
I've indicated navigation in system response steps where it's not just to the next user action step or repeating the user action step that causes an exception, or error, response. For instance, the user could go from the R1.2 "customer is not found" error message either to U1 again to re-enter the Customer ID or to U2 to enter the customer's information so the customer can be added to the database.
In general, two-column use cases are less redundant and therefore more economical; and they actually seem clearer to me because they indicate the various paths more explicitly. Regardless of the format, though, I find that use cases have difficulty understandably representing that steps are repeated. Thus, the one-column steps 3-6 and the two-column steps U4-R5 are repeated for as many items as there are to be ordered.
Use cases' relation to test cases
A big side benefit of use cases is their intrinsic relation to test cases. At a minimum, one tests that a use case has been implemented correctly by executing it. The two-column format enhances the linkage to test cases because the left and right columns respectively emulate a test case's inputs/conditions and expected results.
Using structural testing flowgraphing to map the paths through a use case is a concept recently put forth by Ross Collard in an article on test design, test cases and use cases. Several recent automated requirements definition tools create use cases and flowgraph them to check internal integrity and to indicate the paths to test. The widely-accepted conventional wisdom is that one test case is needed to exercise each such path in order to fully test the use case.
Identifying use case issues
While use cases indeed are a valuable format for both requirements and testing, unfortunately many people over-rely on use cases because they are not aware of use cases' significant limitations and issues.
Several prominent requirements authors state quite explicitly that use cases are the user's requirements and that the user's requirements are use cases. In fact, use cases are merely a format and don't determine content. While a use case can be the user's requirement, often referred to as a business domain use case, almost always a use case instead in describing the usage requirements of a product/system/software design one expects to implement; though seldom distinguished as such, technically they properly are referred to as system use cases. Merely demonstrating that a use case works as designed in no way assures it is designed right or even is what should have been designed.
Most knowledgeable use case proponents acknowledge that use cases are not a format which is well-suited for capturing business rules and quality factors; which often are called, inappropriately in my opinion, "non-functional requirements. Both are key forms of REAL business requirements. Often such requirements are captured in a supplementary document, which inherently interferes with understandable linkage to the use case action steps to which they pertain. In addition, despite most use case authorities' admonitions against use cases which are nothing more than user instructions for executing a Graphical User Interface (GUI), that's what many supposed use cases are.
Simply using a use case format does not assure that all necessary use cases are identified or that a given use case accurately and completely identifies its key action and response steps. I'm sure that without a lot of effort, critically re-examining the "Place an Order" use case examples above may reveal some overlooked steps in the happy path as well as numerous additional alternative success and exception failure scenarios.
Further critical analysis should quickly show the fallacies of presuming one test case per use case scenario will suffice to fully test the use case. First, of all, the use case can be executed in many ways that are unlikely to have been identified as scenarios. Consider all the different points one could exit. Then consider all the points one could start and sequences in which one could proceed from each starting point, even without counting loop iterations beyond once and more-than-once.
If that's not enough variations to bring home the point, identify all the different individual and combination data field conditions that could cause each path to be invoked. This brief examination should make obvious the folly of over-relying on the one-test-case-per-use-case-scenario flawed conventional wisdom.
About the author: Robin F. Goldsmith, JD, has been president of consultancy Go Pro Management Inc. since 1982. He works directly with and trains business and systems professionals in requirements analysis, quality and testing, software acquisition, project management and leadership, metrics, process improvement and ROI. Robin is the author of the Proactive Testing and REAL ROI methodologies and also the recent book Discovering REAL Business Requirements for Software Project Success.
