There is a threshold for determining if a use case is:
- too small (therefore not really needed)
- too small (probably missing something)
- too small (main point should be integrated into another case)
- too large (needs editing)
- too large (needs decomposition)
- or that the size is just right
and often that determination is made strictly based upon step count in the main flow. I've seen some analysts claim that the step count should fall between 10 and 15. Although this isn't a bad place to start, it is not just the amount of steps because other factors might come into play such as ...
- the complexity of the steps
- the number of actor / system interactions
- the audience that will be consuming the information
I'll even take this a bit further because the main flow steps in the use case really shouldn't overshadow the rest of the information in that use case. The steps in the use case often are the "greatest among equals" in regards its components but the entire use case length is the real concern.
I have a golden rule, well it is more of a golden guideline. Overall, the use case should fit on one page in MS Word. In fact, I tend to create a page break for each use case and this isn't by accident. If the use case doesn't mostly fill the page, its value in the package should be challenged. By the same measuring stick, if the use case is more than one page, it should be challenged in regards to decomposition opportunities.
I’ll admit that this guideline was born out of how I hated seeing a use case span two pages. To me, this was a potential thought breaker and I felt that contiguous thought is a paramount concern in use case communication. I admit, this is a bit goofy but it does seem to work for me. As always, I would love to see your thoughts on the topic.
© 2016 Dwayne Wright