Use Case Exceptions Are Ways
Benefits Are Not Delivered
In the Building Requirements Consensus™ Methodology, use case exceptions are ways use cases fail to complete. The perceivable benefit of value of the use case is not delivered to the user. By definition, an execution of a use case must complete and deliver its benefit or it is not a use case. A use case is a set of interactions with a system
that provides a perceivable benefit of value
to someone or something (the user)
playing the use case's role (or part)
from the perspective of the user.Note that use cases must deliver their perceivable benefit of value. Let’s test this out with the Make Toy Car use case.
Example Use Case: Make Toy Car – Case One
Consider the Make Toy Car use case that delivers a toy car that eventually can be sold. Its steps include injecting liquid plastic into a mold. The use case is executed repeatedly in production to make many plastic toy cars. By varying the body design mold and the color of plastic, different car models can be produced.
However, occasionally something goes wrong when this use case is executed and a car is not produced. For example, this blob of plastic is the result of one execution of the Make Toy Car use case.
Would you say that this particular execution of the Make Toy Car use case delivered its perceivable benefit of value? Would you call this blob of plastic a toy car that could eventually be sold? No! This blob of plastic is junk. The benefit, a toy car, was not delivered. This is a mis-use case. It is a use case exception.
Kinds of Use Case Exceptions
We have defined use case exceptions as ways use cases fail to deliver their perceivable benefit of value. There are several kinds of exceptions.
1) System initiated: e g., a required component is unavailable somewhere in the system of systems being used that is not recoverable within this execution of the use case
2) User initiated: e.g., the user cancels out of the use case
3) Benefit not deliveredNote that in the Building Requirements Consensus™ Methodology an exception is defined as a failure to deliver the benefit of the use case. It is not defined by the mechanism that prevents the benefit from being delivered. Some people get confused on this point. They think that because the user cancels the execution of the use case that this is not a use case exception. “After all,” they say, “it is a user action!” However, once the execution of a use case has started, the question is “Was the benefit delivered?” If the answer is “No”, there are only two possibilities.
• Either the use case is still executing and the benefit might still be delivered
• Or there was an exception that prevented the delivery of the benefit
Example Use Case: Make Toy Car – Case Two
Now let’s consider a completely different execution of the Make Toy Car use case. The injection machine operator noticed that on the last execution of this use case, Case One above, a blob was produced. The operator decides to cancel the current execution of the Make Toy use case to inspect the equipment. When the operator presses the Cancel button the use case stops midstream before plastic was injected into the mold.Let’s ask the same question as we did in Case One: Would you say that this, the Make Toy Car - Case Two execution of use case, delivered its perceivable benefit of value? No, it did not. The use case started and then it was stopped by the operator. This is a user initiated exception. The user acted to prevent the use case from delivering its benefit, a toy car.
Benefit Not Delivered and User Initiated Exceptions
We have seen two examples of use case exceptions. In Case One, the benefit not delivered and in Case Two the user initiated an exception. Both kinds of exceptions lead to the same result. The use case benefit is not delivered. It does not matter how the benefit fails to deliver it perceivable benefit of value. If the benefit is not delivered, it is a use case exception.
System Initiated Exceptions
System initiated exceptions are usually straightforward. For example, if during an execution of the Pay by Credit Card use case a connection to the credit card processing system cannot be made, the use case ends. You can try it again, i.e., start a new execution of the Pay by Credit Card use case. However, you cannot continue in the original execution of the Pay by Credit Card use case. The original execution has ended because an unrecoverable condition, an exception, has occurred.
Exception Pet Peeve
All too often throughout our careers, we have found that an execution of an interaction that produces no values is called an exception. Then “requirements” are written on how to handle this “exception.” Usually confusion and unnecessary meetings result.Consider this example. You did a search in Google and there were no matches. The interaction "find every Web page that contains all the word(s) you entered" did in fact complete successfully and did return the set of all matches. In this case, the return set is empty. An empty set is a valid result of successfully completing a search. Goggle properly handles the empty set result. It presents a message to the user stating that no web pages match the user’s criteria. This is one right way to handle an empty set.
A Correct Use Case Must Handle All Possible Results
It is a use case’s responsibility to handle all the results that its actions may generate. Using the Google example, we could document it this way:
1. The user enters the search criteria.
2. The user submits a search request.
3. The system presents the search result set.
4. Optionally, if the search result set is empty, the system presents the message “No matches found.”Now the user knows that the search did complete and that nothing matched the user’s criteria. Since the use case did deliver its benefit, an empty result set, no exception could possibly have happened.
From Exceptions to Use Case Concepts 201
From Use Case Exceptions Explained to Building Requirements Consensus™ Home
|
