Usable Use Case

"Maybe we should buy a book?"

Never lose sight of why Use Cases are written. Their purpose is simple, they communicate requirements. Specifically they are the requirements of how a system should function from the users point of view.

The best Use Cases are those that are the most simple while not losing clarity on requirements. As such, over time a common format has appeared. Usable Use Cases specify the System, the Actors using the System and the Goal of the Use Case.

For an individual Use Case when specifying the System, what is of interest is the state that the system is in at the start of the Use Case. Then what will be the state of the system at the end of the Use Case. What should not be a concern of the individual Use Case is the complete description of the System. Also the Use Case should be completely silent on how the System should be implemented.


Since the Use Case describes from a user point of view there will be one or more Actors on the System. If possible subdivide the Use Case to lower the number of Actors involved, if this can be done without losing clarity. The other thing to address is how Actors of differing permissions or roles will be allowed to use the System. Four typical Actors are Administrator, Power User, User/Guest and Non User.

The Goal of the Use Case will dictate the clarity of requirements. The Goal is what the User is trying to accomplish with the System.

This all seems simple enough and if you stop here your Use Cases will serve their purpose well. But no one can leave it alone. One common antipattern is to make the Use Cases compile. There is a lot of repetitiveness in the Use Cases and if the Architecture matches up well it seems like we could almost take the Use Cases and generate code from them. If you are intent on doing this go ahead get it out of your system, discover the issues with it that everyone else has discovered. Wisdom comes from experience and experience comes from mistakes.

Another Use Case antipattern is exception processing. You will have exceptions but they should show up in your use case as terminal statements. The overwhelming majority of the use case should be dedicated to the normal flow of the system. If this is not the case consider breaking the Use Case into more multiple Use Cases. Perhaps more Actors or System States need to be enumerated.

permalink