- Introduction
- Understanding the Requirements
- Elaborating the Use Cases
- Understanding the Hidden Complexity of Requirements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Understanding the Hidden Complexity of Requirements
Although the main success scenario in a use case shows some details of what's supposed to happen, it can still hide an amazing amount of complexity. The complexity hides in how the application is supposed to deal with all of the weird and wonderful things that can go wrong at each step.
For example, at step 3 the Club Secretary may need to go back and choose a different set of members because the number selected the first time is wrong. Similarly, how is the application supposed to support resending an event notification to a different, partially overlapping subset of the membership?
Of course, you'll find even more complexity as you elaborate each of the use cases in turn. As you do this, it's normal for users to name other use cases that they hadn't thought of previously, so don't attempt to rush this activity. Once you have a few fully elaborated use cases, you can start getting serious about designing the application. Initially, it's sufficient to try to understand what the users really want and to attempt to grasp the underlying complexity.
Obviously, there is much more to writing a complete use case. My next article, "Becoming a Software Developer, Part 5: Creating Acceptance Tests from Use Cases," will look at the ways that the various steps in a use case scenario can fail, and how to create acceptance test cases to ensure that the implementation is correct. If you're impatient to find out more and can't wait until the next article, check out Alistair Cockburn's book Writing Effective Use Cases (Addison-Wesley, 2000, ISBN 0-201-70225-8).
So now, after reading how to partially elaborate a single use case, how hard do you think it will be to create this little application? Do you want to revise your original estimate yet?