I haven’t been doing a lot of posting in recent days, but I have been doing quite a bit of reading. A while back, I was able to get hold of a copy of Use Cases: Requirements in Context by Daryl Kulak and Eamonn Guiney. As you might guess, it describes matters relating to expressing requirements in the form of use cases.
The excerpt below describes the key differences between alternate and exception paths in use cases. I cite this example because, first of all, it made me feel a just a bit dumb.
I’ll explain. A while back I was involved in a discussion during which someone commented that because exceptions are really just alternatives to the main success path, then there’s really no need to bother distinguishing them from other alternatives to the main success path.
While I knew that idea didn’t feel quite right, and there must be a good (and probably simple) response, I didn’t have one at the tip of my tongue at the time. And I admit, it wasn’t a burning issue that kept me awake at night, so I never thought much about it afterward until I came across the following from Kulak and Guiney on how and why we differentiate the two:
Exception path and alternative path sound as if they’re describing the same thing. However, they are worth differentiating. An exception path contains steps that execute if something goes wrong, such as an input from the actor that the system cannot handle or a condition or series of conditions that occurs that are not part of the functionality. An example of an exception path is an actor keying in a record for a search and the record not being found.
An alternative path is actually much closer to the basic course of events because everything happens correctly (in other words, there are no errors); an alternative path simply is less likely to happen than the basic course of events. An example of an alternative path is the use of an unusual form of payment, such as the use of a credit card when a PO is more common.
So basically, we can think of alternative paths as short for alternative “success” paths. Exception paths are not success paths. Nothing ground-breaking, here. Just wanted to share that little tid bit in case there are others that might benefit.
Interesting. I'd stopped making this distinction a long time ago and just grouped both exception and alternative paths together. When I read your post, my first reaction was: Why would I do this? What's the value?
Since then, someone pointed out that you could probably ship a system *without* all of the alternate paths in place. But, it's probably *not* a good idea to ship a system that doesn't handle the exception paths.
Is this the primary reason for making the distinction? Are there others?